Works for me.
On 3/26/09 1:05 PM, "Brian Walker" <[email protected]> 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 >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
