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
