[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
FW: AW: [higgins-dev] Re: Re[2]: Password Cards
|
Title: FW: AW: [higgins-dev] Re: Re[2]: Password Cards
Valery, what do you think of this?
------ Forwarded Message
From: <Axel.Nennker@xxxxxxxxxx>
Reply-To: higgins-dev <higgins-dev@xxxxxxxxxxx>
Date: Thu, 30 Apr 2009 11:55:54 -0700
To: higgins-dev <higgins-dev@xxxxxxxxxxx>
Subject: AW: [higgins-dev] Re: Re[2]: Password Cards
What do you think about this format below?
If you decode the string W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0= it yields:
[http://www.kuppingercole.com,https://www.kuppingercole.com,null]
which was generated by
var text = "["+login.hostname+","+login.formSubmitURL+","+login.httpRealm+"]"
The card is a managed card with a special issuer: urn:openinfocard:storage:component
-Axel
<RoamingInformationCard xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity">
<InformationCardMetaData xml:lang="en">
<InformationCardReference>
<CardId>urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=</CardId>
<CardVersion>1</CardVersion>
</InformationCardReference>
<CardName>https://www.kuppingercole.com</CardName>
<Issuer>urn:openinfocard:storage:component</Issuer>
<TimeIssued>2009-04-30T18:48:46.949Z</TimeIssued>
<SupportedTokenTypeList>
<TokenType xmlns="http://schemas.xmlsoap.org/ws/2005/02/trust">urn:openinfocard:tokentype:usernamepassword</TokenType>
</SupportedTokenTypeList>
<SupportedClaimTypeList>
<SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<DisplayTag>username</DisplayTag>
<Description>username</Description>
</SupportedClaimType>
<SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<DisplayTag>password</DisplayTag>
<Description>password</Description>
</SupportedClaimType>
<SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/usernamefield/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<DisplayTag>usernameField</DisplayTag>
<Description>usernameField</Description>
</SupportedClaimType>
<SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/passwordfield/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<DisplayTag>passwordField</DisplayTag>
<Description>passwordField</Description>
</SupportedClaimType>
</SupportedClaimTypeList>
<IsSelfIssued>false</IsSelfIssued>
<HashSalt>fL59RqJZ5ZgVBPEjGx2N2mjaUqs=</HashSalt>
<TimeLastUpdated>2009-04-30T18:48:46.949Z</TimeLastUpdated>
<IssuerId/>
<IssuerName>MeMyselfAndI</IssuerName>
<BackgroundColor>16777215</BackgroundColor>
</InformationCardMetaData>
<InformationCardPrivateData>
<MasterKey>X9hOswYlTQK5jdM4GJpEg8a43aQF3XVv5XTVCHA/jvCrJzMQawXbqswrBdEQPbZDnBlGyOjh7xgVHdv8Gqw5CQ==</MasterKey>
<ClaimValueList>
<ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<Value>YXNkZg==</Value>
</ClaimValue>
<ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<Value>c2RmYXM=</Value>
</ClaimValue>
<ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/passwordfield/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<Value>cGFzc3dvcmQ=</Value>
</ClaimValue>
<ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/usernamefield/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=">
<Value>dXNlcm5hbWU=</Value>
</ClaimValue>
</ClaimValueList>
</InformationCardPrivateData>
</RoamingInformationCard>
Von: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Paul Trevithick
Gesendet: Dienstag, 28. April 2009 17:44
An: Valery Kokhan
Cc: higgins-dev
Betreff: [higgins-dev] Re: Re[2]: Password Cards
Hi Valery. See ##inline.
On 4/28/09 11:17 AM, "Valery Kokhan" <vkokhan@xxxxxxxxxxxxxx> wrote:
Hi Paul,
As far as I remember the main goals of making password cards fully
compatible with generic p-cards were standardization and
interoperability so we could use standard .crds format to store them
and to pass across different selectors.
## as much as possible, yes.
I've reviewed once again our design options. I agree that "Per role"
option is the best but if we use proposed set of required claim types
I do not see real way for this option to do both store all those
claims in .crds format and make user name and password claims be
indexed by three other claim types. In order to be able index UN & PW
we need to store some kind of hash table in .crds but how could we do
this?
## I’d suggest that in the persistent file format the value of the username claim, for example, would be an XML-structured value that encodes the multiple, rp-site-dependent values of username. This is hinted at here [1] with mentioned of “arrays” etc.
## If host_name + realm_name together can be used to identify the rp site (or app) then we’d need to store as the value of the username claim a set of N {username, host_name, realm_name} triples in the XML. And we’d do the same thing for the password claim value ---a set of N {password, host_name, realm_name) triples.
## If you design an XML syntax, please add it here [1] and we can all review it.
## [1] http://wiki.eclipse.org/Password_Cards#Architecture
If we a going to move forward with "Per role" design option I'd
suggest to use only two claim types for user name and password claim
values while host name, form submit URL and http realm should be
included/encoded in a query part of URL for both user name and
password claim types.
Thus, for any card for some particular role will contain two claim
types for each particular site log-on:
http://schemas.informationcard.net/@ics/username/2009-3?host_name=host_name&url="">
http://schemas.informationcard.net/@ics/password/2009-3?host_name=host_name&url="">
## What you propose above as a way to pass the parameters is not unreasonable, and in fact had been my original thinking based on Axel Nennker’s original suggestion to use “?” parameters from last year. Folks in the IMI TC do NOT think that this “?” is a good way forward as opposed to a much more comprehensive, general purpose solution that (as I understand it) involves passing full WS-SecurityPolicy expressions in the getDigitalIdentity() API call, as opposed to the limited subset that the <object> tag currently supports. However, this is all many moons away from being resolved. Since you need to do SOMETHING immediately, I’d go ahead and use the “?” approach and let’s keep an eye on this as things evolve at the ICF and within the OASIS IMI TC.
Of course if we move forward with this we will need to be able to
manage claim types dynamically but from my point it is the only way.
--
Thanks,
Valery
------ End of Forwarded Message
Attachment:
ATT00001.c
Description: Binary data
