On 3/26/09 11:28 AM, "[email protected]" <[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. > > ## Don¹t worry, what we did with was quick-and-dirty to support a demo in > Paris a couple weeks ago. Nothing is sacred. > > 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? > > ## This is an interesting question. To date our design center has been a local > ³synchronizing² cardstore that acts as a write-through cache to a remote > cardstore (and also accepts updates from the remote cardstore). But to the > user there¹s logically only one store. We like this for its simplicity to the > user. But architecturally, we may need to consider support in the local > selector (the LICS component specifically) for N>1 logically separate > cardstores. > > 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... > > ## As we work on the correct CardSync auth approach I think we should assume > we need to support N>1 cardstores. I¹ll add that to a newly created > ³requirements² section here [1]. Now the code¹s written it¹s time to gather > requirements :) > > -Axel > > [1] http://wiki.eclipse.org/CardSync_Protocol#Requirements > ________________________________ > > 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
