Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Problem with current scheme for IContext.open(AuthNSelfIssuedMaterials)

I understand your use case ... just not sure I fully buy into it's importance. ... Aside from that, I'm not sure that using the managed card's Card ID will always work - because it is not necessarily guaranteed to be unique.  Yes, the STS that issues the card could append some additional random value to the card ID:
 
 
However, it is a little unclear to me who actually owns the generation of the card ID and hence, whether the requirement to append random data is enforceable.  Although the code that generates a card is STS code, it isn't really the STS that determines the card ID - it is really some application that is calling into the STS, which is "outside" the STS.  It is a particular deployment of the STS, which may have its own rules for what a card ID should look like.
 
If you meant ManagedCardPPID instead of Card ID, I don't think that will work at all.  In order to get the ManagedCardPPID, the card-issuing application can only get it by requesting it as a claim, which means that a user who is being issued the managed card must be prompted to select the managed card after he has imported it into CardSpace.  The user may or may not follow through and complete that step.  If he didn't for some reason, we have imported a managed card that cannot actually be used.  If he followed instructions and did it, it is a very clumsy sequence to put him through, and in any case there is a chicken/egg problem.  Until the card issuing application gets the ManagedCardPPID back, no hash value can be stored in the directory - because the card issuing application only has three of the four needed components to calculate the hash.  When the user selects the managed card, an RST is sent to the STS to request the PPID claim.  However, the STS cannot authenticate, because nothing is in the directory to authenticate against.  Hence, no claim can be returned - unless the STS has special code to skip the authenticate step when the only claim being asked for is PPID. -- Assuming the STS is smart enough to do that and the card issuing application finally gets the four pieces to store a hash value in the directory, there is another problem that occurs for "normal" RSTs (requests that ask for more than PPID) from that managed card.  How does the STS get the managed card's PPID?  It's not part of the RST - unless you assume that the <ClientPseudonymn> element is always included.
 
Given all of this, I am assuming you meant what you said - Managed Card's Card ID, not ManagedCardPPID, in which case I go back to my original concerns about the guaranteed uniqueness of Card ID.
 
Daniel
 
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/15/2007 12:27 AM >>>
I disagree with the premise that a personal card should be only associated
with a single context.
I want to be able to create multiple digital subjects all representing
some unique subset of my identity.
I do not see any reason to force me to create a unique personal card for
each managed card reqpresenting each of these identities at a provider,
especially when the solution is so easy.

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/14/2007 09:55:27 AM:

> When we analyzed this problem, we came to the conclusion that
> associating multiple managed cards with the same personal card was
> not a problem, as long as the personal card is associated with only
> one user in the directory.  When the managed card that is backed by
> a personal card is issued, the application that issues the card
> needs to know what user object to add the personal card's
> cardKeyHash value to.  The assumption is that someone will have to
> identify the user object (by entering username/password perhaps) to
> associate the cardKeyHash value with.  If the cardKeyHash value is
> already on the user object in the directory, no big deal - it is ok
> - no matter that multiple managed cards are using the same personal
> card - the personal card's cardKeyHash is being used to identify
> only a single user in the directory.  If, on the other hand, it is
> discovered that the cardKeyHash has already been associated with a
> different user, the application issuing the managed card should
> refuse to issue the managed card, and indicate that the selected
> personal card is already associated with another user. -- Note that
> the a particular personal card belongs to one particular user on a
> particular client machine anyway, so I don't think it is a valid use
> case to associate a personal card with multiple users in the
> directory.  If you eliminate the use case of having a personal card
> associated with multiple users in the directory, there is no problem.
>
> If the two managed cards are actually intended for different users,
> they ought to be backed by different personal cards.  But in that
> case, I would anticipate that there would be different card stores
> for those users - every user on the Windows box will have a
> different set of cards.
>
> My 2 cents.
>
> Daniel
>
> Daniel Sanders
> Software Engineer
> dsanders@xxxxxxxxxx
> 801-861-4193
> [image removed]
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/14/2007 1:52 AM >>>
> One thing I had not fully realized until yesterday, was that the current

> implementation depends on the (ppid+modulus+exponent) from a specific
self
> issued (SI) credential (token from personal card) being used only once.
If
> one wants to create multiple entries/contexts and associate them with
the
> same self issued credential, the current scheme will not work. It should

> be noted that it is possible to associate multiple self issued
credentials
> with a single entry/context since the cardKeyHash is a multi-valued
> attribute.
>
> The reason for the limitation is that we are using the personal card as
> the key into the entry behind a managed card, and not using any
identifier
> from the managed card itself in the key.
>
> I'd like to discuss the feasibility of changing the scheme to include
> (Managed Card ID+SI PPID+SI Modulus+SI Exponent) in the cardKeyHash
> computation. This would enable one personal card to be associated with
> multiple managed cards.
>
> Thanks,
> Mike
> _______________________________________________
> 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