Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] CardSync : Agenda for Higgins developer call March26 atnoon ET

Title: Re: [higgins-dev] CardSync : Agenda for Higgins developer call March26 atnoon ET
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" <bwalker@xxxxxxxxx> 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?RESTAuthentication.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
bwalker@xxxxxxxxx


 

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
bwalker@xxxxxxxxx


 

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
bwalker@xxxxxxxxx



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 <AYuhimenko@xxxxxxxxxxxxxx>

On Thu, 26 Mar 2009 16:28:19 +0100
<Axel.Nennker@xxxxxxxxxx> 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: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] 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, <Axel.Nennker@xxxxxxxxxx> 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: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Alexander Yuhimenko
             Gesendet: Donnerstag, 19. März 2009 15:28
             An: higgins-dev@xxxxxxxxxxx
             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: "Axel.Nennker@xxxxxxxxxx" <Axel.Nennker@xxxxxxxxxx>
             Date: March 19, 2009 4:31:56 AM EDT
             To: "higgins-dev@xxxxxxxxxxx" <higgins-dev@xxxxxxxxxxx>
             Subject: CardSync was: [higgins-dev] Agenda for Higgins developer call March 19
             Reply-To: "Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

             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: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] 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
             higgins-dev@xxxxxxxxxxx
             https://dev.eclipse.org/mailman/listinfo/higgins-dev
             _______________________________________________
             higgins-dev mailing list
             higgins-dev@xxxxxxxxxxx
             https://dev.eclipse.org/mailman/listinfo/higgins-dev



_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

<smime.p7s><ATT00001.c>

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

<smime.p7s><ATT00001.c>

<ATT00001.c>



Back to the top