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

[Michael McIntosh <mikemci@xxxxxxxxxx>]

"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?

> 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.

> 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
>