Hello, I updated [3] http://wiki.eclipse.org/CardSync_Authentication. I'm going to update [2] next week.
-- thanks, Alexander Yuhimenko <[email protected]> On Mon, 06 Apr 2009 15:43:54 -0400 Paul Trevithick <[email protected]> wrote: > Thanks Brian, > > I¹ve been reorganizing the CardSync page [1] and I noticed that the auth > part [3] of this section [2] has not yet been updated per your email below. > At the least we should mark [3] as being obsolete. > > --Paul > > [1] http://wiki.eclipse.org/CardSync_API > [2] http://wiki.eclipse.org/CardSync_API#RESTful_API > [3] http://wiki.eclipse.org/CardSync_Authentication > > > On 4/6/09 2:44 PM, "brian walker" <[email protected]> wrote: > > > Hi All - just to follow up on this topic, we had a breakout discussion on > > Wed > > 1-April-09 to discuss the card synch authentication model. > > > > Below are the summary points from this discussion: > > > > * Attendees: John Bradley, Andy Hodgkinson, Valery Kokhan, Paul Trevithick, > > Alexander Yuhimenko, Brian Walker > > * The following were the proposed decision points from this discussion. > > Please > > reply if there are additional thoughts or ideas related to the below: > >> * The authentication model will be based on the model used for Amazon > >> header > >> cononicalization ( > >> http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAuthenticati > >> on.html). We would use "Authorization" header instead of "access_token" for > >> passing session ID (access token id), but with our own schema name. For > >> example we could use HWS (or propose another name) instead of BASE, DIGITAL > >> or AWS. > >> * The initial authentication request can be RST based via default p-card > >> presented to the back-end card servers as part of the synchronization > >> process. To support this we would need to develop the following: > >>> * Add a call for getting CardSynch security policy, for example > >>> GET/cardsynch/SecurityPolicy. > >>> * Define SamlTokenCredentialTO (or another name if a better one is > >>> appropriate) and POST it to /cardsynch/rs/AuthCredential. > >> * We would use session ID instead of SAML token for per transaction > >> authentication. Per > >> http://docs.amazonwebservices.com/AmazonS3/latest/S3_Authentication.html, > >> AWS > >> does not support session key pair. We could continue to use session ID > >> however (aka access token ID) in CardSynch, but would need to add > >> maxLiveTime > >> to AccessToken TO. The main reason to use Session ID instead of SAML token > >> is > >> due to comparative large size of SAML token. Authorization header may look > >> like: "Authorization: HWS session Id". > > * There is a follow up action item for Alexander to ensure that this > > methodology is also adopted in the serialized selector that is currently > > being > > designed. Stay tuned for a separate email on that topic later this week. > > > > Please reply if there are additional comments or suggestions. > > > > regards...Brian > > > > On Mar 27, 2009, at 3:39 PM, Brian Walker wrote: > > > >> Ok - we'll aim for 11am EDT on Monday the 30th. Skype will be preferred > >> channel - but if someone on below list does not have Skype just let me know > >> and I can send out a call in number. > >> > >> > >> Brian Walker > >> =brian.walker > >> VP of Engineering > >> Parity Communications Inc > >> cell: 781-801-0254 > >> [email protected] > >> > >> > >> > >> > >> On Mar 26, 2009, at 4:34 PM, John Bradley wrote: > >> > >>> 11am EDT is fine with me. > >>> > >>> John B. > >>> On 26-Mar-09, at 1:22 PM, Brian Walker wrote: > >>> > >>>> Ok - we could try for 11am ET if that works for the folks referenced > >>>> below? > >>>> > >>>> > >>>> Brian Walker > >>>> =brian.walker > >>>> VP of Engineering > >>>> Parity Communications Inc > >>>> cell: 781-801-0254 > >>>> [email protected] > >>>> > >>>> > >>>> > >>>> > >>>> On Mar 26, 2009, at 2:24 PM, John Bradley wrote: > >>>> > >>>>> That overlaps with the OSIS call I wouldn't be able to make it. I am OK > >>>>> with before the schemas call. > >>>>> > >>>>> John B. > >>>>> On 26-Mar-09, at 10:05 AM, Brian Walker wrote: > >>>>> > >>>>>> To help close on this good and relevent topic as it applies to our > >>>>>> Selector Harmonization design and implementation - I would propose to > >>>>>> host a call (skype call) on Monday 30-March at Noon ET. > >>>>>> > >>>>>> Anyone/everyone is welcome to join, but at a minimum, would like to > >>>>>> have > >>>>>> on this call, Paul, Axel, Alexander, John Bradley, Jeesmon, and Andy > >>>>>> Hodgkins (if available). Are people from this group available Monday > >>>>>> 30-March at Noon ET? > >>>>>> > >>>>>> thanks...Brian > >>>>>> > >>>>>> > >>>>>> Brian Walker > >>>>>> =brian.walker > >>>>>> VP of Engineering > >>>>>> Parity Communications Inc > >>>>>> cell: 781-801-0254 > >>>>>> [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mar 26, 2009, at 12:35 PM, Alexander Yuhimenko wrote: > >>>>>> > >>>>>>> Hello Axel, > >>>>>>> > >>>>>>> CardSync didn't invent something new :) > >>>>>>> It's just going to expose high level API via JAX-RS or JAX-WS web > >>>>>>> services or XDI endpoint, or ... for synchronizing user data (icard, > >>>>>>> history, categories, ...) between few installed user selectors by > >>>>>>> using > >>>>>>> well known design patterns and techologies. I'd like to design it > >>>>>>> for > >>>>>>> supporting data binding to different formats XML, google protobuf, X3, > >>>>>>> .... > >>>>>>> > >>>>>>> Adding authentication by IdP token is tiny fix. > >>>>>>> But I thing we have to support few authentication ways. For example, > >>>>>>> If > >>>>>>> user install new selector how/where this selector get ICard for > >>>>>>> requesting token? > >>>>>>> > >>>>>>> I'd like to use single signon/logout auth work-flow by few reasons, > >>>>>>> one of them is performance. > >>>>>>> Depends on selector synchronization strategy, selector may need update > >>>>>>> CardSync store immediately after every change on client side. For > >>>>>>> example if client login on RP with pcard (selector generate IdP token > >>>>>>> itself), selector must update card history in CardSync store, but for > >>>>>>> authentication on CardSync server it should generate second IdP token. > >>>>>>> Generating pcard token on client side may take 1-2 seconds, but if > >>>>>>> your > >>>>>>> client work on iphone or android, it will be not so fast. > >>>>>>> > >>>>>>> Of course we would re-use saml token instead of CardSync access token > >>>>>>> id, but if client make few calls for updating CardSync store (for > >>>>>>> example updating card categories), it must send saml token every time, > >>>>>>> but size of saml token in hundred times more than accesstoken id > >>>>>>> (just few bytes). > >>>>>>> > >>>>>>> The second reason is security. We may restrict number of active user > >>>>>>> session. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I'm sorry, we had to share not complete draft version of CardSync :( > >>>>>>> But some suggestions were interesting and helpful. if you would > >>>>>>> recommend related specifications and/or solutions it'll be useful. > >>>>>>> > >>>>>>> -- > >>>>>>> thanks, > >>>>>>> Alexander Yuhimenko <[email protected]> > >>>>>>> > >>>>>>> On Thu, 26 Mar 2009 16:28:19 +0100 > >>>>>>> <[email protected]> wrote: > >>>>>>> > I think it is more work to make it right later and it is sending the wrong > message to other developers if Higgins is not eating it's own mousefood. > I have no problem with username/password if this is implemented faster than > X509 and as I said the difference to the current > UsernamePasswordCredentialTO compared to sending a RST and digesting the > saml-token is small > > Another question: Does the current Higgins architecture allow the selector > to access multiple cardstore in parallel? I implemented that openinfocard > can have the cardstore on a nfc-phone but if I want to have several > cardstores in parallel things get more complicate than I want to tackle with > today. > I want to use the "standard" cardstore but if I put the phone on the nfc > reader then I want this card to be selectable in the selector immediately. > Next I want to move cards from one store to the other... > > -Axel > > > ________________________________ > > Von: [email protected] > [mailto:[email protected]] Im Auftrag von John Bradley > Gesendet: Donnerstag, 26. März 2009 16:12 > An: Higgins (Trust Framework) Project developer discussions > Betreff: Re: [higgins-dev] CardSync : Agenda for Higgins developer call > March26 atnoon ET > > > +1 I think I have made this point several time re authn to the remote > card store. > > Last night I was pointing out to Drummond that the selector could > easily have a X.509 cert/keypair that is used to back the authn card for the > store. > > Axel I think the idea is under consideration for a future design but > people want to get something out the door quickly. > > John Bradley > > > On 26-Mar-09, at 5:42 AM, <[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 > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> <smime.p7s><ATT00001.c> > >>>> > >>>> _______________________________________________ > >>>> higgins-dev mailing list > >>>> [email protected] > >>>> https://dev.eclipse.org/mailman/listinfo/higgins-dev > >>> > >>> <smime.p7s><ATT00001.c> > >> > >> <ATT00001.c> > > > > > _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
