What do you think about this format below? If you decode the string W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29s ZS5jb20sbnVsbF0= 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:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM 6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0=</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:tok entype:usernamepassword</TokenType> </SupportedTokenTypeList> <SupportedClaimTypeList> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username /urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3 cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <DisplayTag>username</DisplayTag> <Description>username</Description> </SupportedClaimType> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password /urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3 cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <DisplayTag>password</DisplayTag> <Description>password</Description> </SupportedClaimType> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username field/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6L y93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <DisplayTag>usernameField</DisplayTag> <Description>usernameField</Description> </SupportedClaimType> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password field/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6L y93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <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/jvCrJzMQawXbqswrBdEQP bZDnBlGyOjh7xgVHdv8Gqw5CQ==</MasterKey> <ClaimValueList> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password /urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3 cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <Value>YXNkZg==</Value> </ClaimValue> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username /urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3 cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <Value>c2RmYXM=</Value> </ClaimValue> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password field/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6L y93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <Value>cGFzc3dvcmQ=</Value> </ClaimValue> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username field/urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6L y93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbF0="> <Value>dXNlcm5hbWU=</Value> </ClaimValue> </ClaimValueList> </InformationCardPrivateData> </RoamingInformationCard> ________________________________ Von: [email protected] [mailto:[email protected]] 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" <[email protected]> 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_n ame&url=url&realm=realm http://schemas.informationcard.net/@ics/password/2009-3?host_name=host_n ame&url=url&realm=realm ## 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
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
