[higgins-dev] RE: Generating Personal vs. Managed CardSpace i-cards

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Michael McIntosh [mailto:mikemci@xxxxxxxxxx]
> Sent: Friday, March 09, 2007 10:22 AM
> To: Paul Trevithick
> Cc: 'Higgins (Trust Framework) Project developer discussions'; 'Sergey
> Lyakhov'
> Subject: Re: Generating Personal vs. Managed CardSpace i-cards
> 
> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> wrote on 03/09/2007 09:45:17
> AM:
> 
> > Mike,
> >
> > Hope you made it back home safely.
> >
> > We all agree that the Token Service must generate managed
> CS-interoperable
> > i-cards. SergeyL (slyakhov@xxxxxxxxxxxxx) is writing the "CardSpace
> Managed
> > I-Card Provider" (CMIP) plug-in with this understanding.
> 
> By "CS-interoperable" do you mean - can be imported into CS? or do you
> mean will work with a Higgins Identity Selector which talks to a CS
> compatible STS and RP?

Neither/Both. I'm talking about the provider class itself
(http://wiki.eclipse.org/index.php/CardSpace_Managed_I-Card_Provider) 

> 
> > But when it comes to CS personal i-cards...
> >
> > 1) SergeyL is of the view that these can and should be created as
> standalone
> > i-card instances (managed by a second provider, the "CardSpace Personal
> > I-Card Provider" (CPIP). We plan to use the I-Card Manager for the UI to
> > create these i-cards, and we plan to use an IdAS Context to store its
> data.
> > The TS's Token Providers will access and read the card's subject data
> via
> > IdAS.
> 
> Strictly speaking, MSFT CS "Personal Cards" can only be created by MSFT
> CS. I suppose one could create a Backup (CRDS) file and add a personal
> card to it and restore it back into MSFT CS.
> 
> However, I think you are describing an i-Card which uses an STS at a
> specified EPR which generates "self-signed" security tokens.
> While theoretically this is possible and desirable, MSFT CS will not allow
> you to import cards the specify Issuer URI of .../self.
> If they lie (claim to generate tokens from issuer .../foo but actually put
> issuer .../self into tokens), CS will import the card but the matching
> rules won't work correctly (if RP asks for .../self the card won't be
> selectable).
> 
> We could, with our own Identity Selector, do the right thing, but it does
> not make sense to call these "CardSpace Personal I-Card"s, since they are
> not compatible with CS.

I was looking at the CPIP and CMIP from the user's point of view from within
Higgins. These providers manage i-cards that look and act pretty much the
same way that a personal i-card looks and acts within Microsoft CardSpace so
that's why I was calling them this. 

But I see your point about the file format. Its really a Higgins format
CardSpace-like Personal I-Card!
 
> 
> > 2) I believe that you think that the TS should or must generate these
> > CPIP-type i-cards too. Personal cards have a "master key" in them. Is
> this
> > why you think that the TS must generate them? E.g. because the TS is
> > configured to manage this master key?
> 
> Since these cannot work with CS, we can decide rules for how they are
> created (whether they must be signed to be imported). In this co-located
> case as long as card creator writes attributes to a place that the STS can
> read from I think we can make it work. Also seems like there may not need
> to be a separate card generation and card import so signing of the card
> need not happen.
> 
> >
> > I'd like to understand better what's behind your argument.
> >
> >
> > [See
> >
> http://wiki.eclipse.org/index.php/Components#I-Card_Registry_and_I-
> Card_Prov
> > iders for the list of all of the i-card providers]
> >
> > -Paul
> >