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
Works for me.


On 3/26/09 1:05 PM, "Brian Walker" <bwalker@xxxxxxxxx> 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


Back to the top