You are right. This is still evolving. The current card looks like this (see below). I think that adresses your issues. I removed the "?" because it conflicts with the variable claims. Please note that the issuer is "special" and the cards are managed. This way I assume that cards are somewhat more legal in respect to ISIP. The issuer could even be some working https endpoint if it is working together with a card sync store. Regarding "Per account" etc: in Firefox I have the following info: login.hostname login.formSubmitURL login.httpRealm login.usernameField login.passwordField Some of them are null in some cases. In the current version I just concatenate all these fields and base64 encode them to give the cardid.
-Axel <RoamingStore xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity";> <RoamingInformationCard> <InformationCardMetaData xml:lang="en"> <InformationCardReference> <CardId>urn:openinfocard:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbCx1c2VybmFtZSxwYXNzd29yZF0=</CardId> <CardVersion>1</CardVersion> </InformationCardReference> <CardName>https://www.kuppingercole.com</CardName> <Issuer>urn:openinfocard:storage:component</Issuer> <TimeIssued>2009-04-02T14:57:14.375Z</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:uuid:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbCx1c2VybmFtZSxwYXNzd29yZF0=";> <DisplayTag>username</DisplayTag> <Description>username</Description> </SupportedClaimType> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password/urn:uuid:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbCx1c2VybmFtZSxwYXNzd29yZF0=";> <DisplayTag>password</DisplayTag> <Description>password</Description> </SupportedClaimType> </SupportedClaimTypeList> <IsSelfIssued>fasle</IsSelfIssued> <HashSalt>ThwN0VMmd1eACq6YwJqdWLdSvuc=</HashSalt> <TimeLastUpdated/> <IssuerId/> <IssuerName>MeMyselfAndI</IssuerName> <BackgroundColor>16777215</BackgroundColor> </InformationCardMetaData> <InformationCardPrivateData> <MasterKey>JhqtikXltNiOSAm3UWoS9owKXJA1VYLmamom1GPD4Fb0nkmyDESAytXcFSI9COXH9A09HXzbf6Cbe8PHKboJxA==</MasterKey> <ClaimValueList> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/password/urn:uuid:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbCx1c2VybmFtZSxwYXNzd29yZF0=";> <Value>sadf</Value> </ClaimValue> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/username/urn:uuid:W2h0dHA6Ly93d3cua3VwcGluZ2VyY29sZS5jb20saHR0cHM6Ly93d3cua3VwcGluZ2VyY29sZS5jb20sbnVsbCx1c2VybmFtZSxwYXNzd29yZF0=";> <Value>sdf</Value> </ClaimValue> </ClaimValueList> </InformationCardPrivateData> </RoamingInformationCard> </RoamingStore> ________________________________ Von: [email protected] [mailto:[email protected]] Im Auftrag von Paul Trevithick Gesendet: Mittwoch, 1. April 2009 16:54 An: higgins-dev Cc: [email protected] Betreff: RoamingStore for Password Cards: [WAS: Re: AW: [higgins-dev] CardSync: Agenda for Higgins developer call March26 atnoon ET] Axel, I think you forgot to append the "username" and "password" strings to the http://schemas.openinfocard.org/ws/2009/03/identity/claims/ "base" URI, but yes, this could work. * What you have here follows the "per account" design option here [1]. * I assume that you are passing the site as the "?" parameter in both "username" and "password" claim requests. This is a twist on what is proposed here [2] --we also pass the site in a "?" parameter, but do so on a separate "webpage" claim. Your approach eliminates the need for this third webpage claim. I think I prefer your approach. * I agree that we could use a special tokentype * This approach could work self issued or not. --Paul [1] http://wiki.eclipse.org/Password_Card_Metaphor_Design_Options [2] http://wiki.eclipse.org/Password_Cards#Required_Claims On 3/30/09 5:37 PM, "[email protected]" <[email protected]> wrote: What do you think of this RoamingStore for UsernamePasswordCards? It was generated by a Firefox extension that I wrote this evening. It has a special tokentype, the supportedClaim contains the URL in the ?h= portion, it is not self-issued The danger that it will be used at a wrong site should be minimal because the site is encoded in the claim's URI. An RP "bad" would have to request exactly this claim to steal this card's values for the kuppingercole site. But then hopefully the "this is your first visit" dialog should stop the user... Although I did not try to import it into CardSpace because I have not javascript code to encrypt the store. -axel <RoamingStore xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity";> <RoamingInformationCard> <InformationCardMetaData xml:lang="en"> <InformationCardReference> <CardId>urn:uuid:f0596820-4a90-41eb-b64b-c368e9549462</CardId> <CardVersion>1</CardVersion> </InformationCardReference> <CardName>https://www.kuppingercole.com</CardName> <Issuer>urn:openinfocard:storage:component</Issuer> <TimeIssued>2007-03-08T17:04:52.09375Z</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/?h=https://www.kuppingercole.com";> <DisplayTag>username</DisplayTag> <Description>username</Description> </SupportedClaimType> <SupportedClaimType Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/?h=https://www.kuppingercole.com";> <DisplayTag>password</DisplayTag> <Description>password</Description> </SupportedClaimType> </SupportedClaimTypeList> <IsSelfIssued>fasle</IsSelfIssued> <HashSalt>AFFKiQEqRyZGbX47JVVDzA==</HashSalt> <TimeLastUpdated/> <IssuerId/> <IssuerName>MeMyselfAndI</IssuerName> <BackgroundColor>16777215</BackgroundColor> </InformationCardMetaData> <InformationCardPrivateData> <MasterKey>uinRcAPgRlSZGd7B4bAHsf7U1vgkhbklcBhpoxA1ZD4=</MasterKey> <ClaimValueList> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/?h=https://www.kuppingercole.com";> <Value>sadfasadf</Value> </ClaimValue> <ClaimValue Uri="http://schemas.openinfocard.org/ws/2009/03/identity/claims/?h=https://www.kuppingercole.com";> <Value>asdfasf</Value> </ClaimValue> </ClaimValueList> </InformationCardPrivateData> </RoamingInformationCard> </RoamingStore> ________________________________ Von: [email protected] [mailto:[email protected]] Im Auftrag von Paul Trevithick Gesendet: Donnerstag, 26. März 2009 14:17 An: higgins-dev Cc: John Bradley Betreff: Re: [higgins-dev] CardSync : Agenda for Higgins developer call March26 atnoon ET Axel, WRT auth, we agree with you. John Bradley has been suggesting the same thing to me for a couple of weeks. Why reinvent auth to the CardSync server, why not use a token. The CardSync that we threw up was just something to get the ball rolling. We want to evolve it. Your input is vital and most helpful. Don't assume what we've done is anything more than a prototype. This CardSync protocol really needs to be well designed (as I'm sure you'd agree) as it could well be very important for lots of uses in the future. Your inputs are always valued, so please consider yourself part of the CardSync design team. This is one reason I like open source so much. You get many more perspectives weighing in. And if we're willing to listen we get a better result. --Paul On 3/26/09 8:42 AM, "[email protected]" <[email protected]> wrote: Regarding 2. and [2] from the latest Agenda email and last weeks email regarding CardSync: "GET Cards" is only one example of the many bad decisions from http://wiki.eclipse.org/CardSync_Protocol Most methods/calls described in CardSync_Protocol reinvent the wheel! Another example: AuthCredential - "/AuthCredential" Signon You are posting a usernamePasswordAuthCredentialTO but this is sö 90ties... The selector accessing the cardstore in the cloud is just a rich-client that needs an access token to access the cardstore. So the way this MUST be achieved to adhere to the overall Higgins goals is: - send a security token request to the cardstore idp and retrieve a security token. Authenticate to the IdP using what ever method it accepts but use the standard RST for this. - use that security token in to access the cardstore (RP) to e.g. retrieve the cards The difference between the data exchanged in the Signon example and the standard RST is minimal. And Higgins already has all the code needed to do it the standard way. -Axel -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Alexander Yuhimenko Gesendet: Donnerstag, 19. März 2009 15:28 An: [email protected] Betreff: RE: CardSync was: [higgins-dev] Agenda for Higgins developer callMarch 19 Hello, GET /cardsync/rs/Cards was implemented just for FC2 demo, it's temporary method due to i didn't finish method which return all changes (ICards, Card history, Card categories, ...) from server between client and server root revisions. if you think "GET Cards" is useful, i may re-implement it by using RoamingStore and card extension for transferring CardSync specific data (Revsion information etc) or without it. I'm sure, CardSync should be compatible with "Identity Selector Interoperability Profile" as much as possible, but it will not be clear/easy always usage extensions for transferring CardSync specific data, so CardSync have to define own schema. it may make sense to support few methods for importing cards from Crd/Crds files and getting them, for example some Card selectors would use CardSync like on-line backup service with minimal changes. -- thanks, Alexander Yuhimenko From: "[email protected]" <[email protected]> Date: March 19, 2009 4:31:56 AM EDT To: "[email protected]" <[email protected]> Subject: CardSync was: [higgins-dev] Agenda for Higgins developer call March 19 Reply-To: "Higgins (Trust Framework) Project developer discussions" <[email protected]> Sorry for chiming in late but why do you define your own cardstore xml in http://wiki.eclipse.org/CardSync_Protocol ? Why isn't the response to GET /cardsync/rs/Cards HTTP/1.1 a RoamingStore as defined in identity.xsd ? http://schemas.xmlsoap.org/ws/2005/05/identity/identity.xsd There are enough extension points in the schema if you need extra data and if you do not want to use some required value then like BackgroundColor then set them to 0. -Axel ------------------------------------------------ Von: [email protected] [mailto:[email protected]] Im Auftrag von Paul Trevithick Gesendet: Donnerstag, 19. März 2009 05:19 An: higgins-dev Betreff: [higgins-dev] Agenda for Higgins developer call March 19 Logistics Time: noon Eastern Dial-in: 1-866-362-7064 / 89-2048# Agenda 1. [Brian] 1.1M6 - was targeted for March 18 See [1] 2. [Brian, Alexander, Andy] Selector Architecture Harmonization See [2] Andy didn't quite get the Synchronizing CardStore done; may need to hand this off to another developer 3. [Mary, Jeesmon, Jochen] Current status of RCP Selector use for EclipseCON demo 4. [Markus] IdAS Authentication Markus is working on a proposal [4] 5. [Paul] Higgins website improvements [3] There are 6 items to discuss 2.1 Flatten Solutions into the 3 solutions areas (nav structure change) 2.2 Reorganizing Solutions 2.3 Eliminate "Higgins Data Model" (nav structure change) 2.4 New solution names 2.5 New component set names 2.6 New Downloads Page Updated home page implementing (2.1, 2.2 and 2.3) is available in the staging area [5] 6. [Paul] FC2 Higgins Workshop Mar 11-13 in Paris We demoed the Selector Linux-GTK reading/writing cards using CardSync FC2 member (Orange) has developed a selector for Nokia J2me phone FC2 has also developed a web selector 7. [Paul] Propose merge web ICM and the Web Selector together into a single solution 8. [Paul] CardSync JohnB's authentication idea (use personal card) Should we use it as the one and only CardStore API for the Higgins selector? This was discussed briefly last week in Paris. Perhaps a simple core protocol and then extensions. 9. [Paul, Markus] All Selectors diagram [6] Discuss if diagram is correct WRT process boundaries (as noted in [6]) [1] http://wiki.eclipse.org/Higgins_1.1M6 [2] http://wiki.eclipse.org/Selector_Architecture_Harmonization [3] http://wiki.eclipse.org/Higgins_1.1_Plan#Website [4] http://wiki.eclipse.org/Authentication_Materials [5] http://www.eclipse.org/higgins/ver2/index.php [6] http://wiki.eclipse.org/Selector_Overview#H1.1_All_Selectors _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
