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 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" <AYuhimenko@xxxxxxxxxxxxxx> wrote:

Hello,

I updated [3] http://wiki.eclipse.org/CardSync_Authentication. I'm going to update [2] next week.

--
thanks,
Alexander Yuhimenko <AYuhimenko@xxxxxxxxxxxxxx>

On Mon, 06 Apr 2009 15:43:54 -0400
Paul Trevithick <ptrevithick@xxxxxxxxx> 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" <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?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
> >> 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