Thanks Alexander. I just deleted the “obsolete” comment at the top of [3] cuz now it isn’t obsolete. --Paul
On 4/7/09 2:56 PM, "Alexander Yuhimenko" <[email protected]> wrote: > 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
