Re: [higgins-dev] cardId syntax

[Michael McIntosh <mikemci@xxxxxxxxxx>]

higgins-dev-bounces@xxxxxxxxxxx wrote on 03/08/2007 11:22:57 AM:

> I have some questions about your a,b,c, assertions, and then some 
comments:
> 
> (a) every cardId must be unique to a provider/TS
>
> What assumptions are the basis for this assertion? and what does it 
mean?

>From CardSpace-TechRef: "/ic:InformationCard/ic:InformationCardReference
This required element provides a specific reference for the information 
card by which it
can be uniquely identified within the scope of an issuer. This reference 
is included in all
token requests sent to the identity provider based on that information 
card. The detailed
schema of this element is defined in Section 4.1.1.1."

> (b) a person might want to use 1<N<5 different auth methods for the 
> same data set (i.e. the same subject within the same context)
> (c) MSFT doesn't support N>1 auth methods for a single card.
> I agree with both if these statements, but I don't agree that this 
> necessitates putting auth type in the card ID.  Auth type is already
> part of the card definition, so putting it in the card Id is merely 
> redundant.  Furthermore, the auth type is passed to the STS 
> elsewhere in the RST - so there is really no need for it to be in 
> the card ID.  -- Am I missing some of your assumptions about how the
> STS should/will/ought to make use of a card Id?

Actually don't think anything other than a unique ID has to be there - but 
since we've been using the fact that the CardId (aka 
InformationCardReference) is passed in the RST to the STS as way to tell 
the STS which context/subject to open - and we need to make that more 
unique. Paul suggested adding auth method - I suggest some random value 
chosen by STS. 

Actually I'd prefer not to overload the CardId with all this information - 
but we have not found a good alternative.

> 
> 
> Other comments:
> 
> Are you promoting a "best practice" or a "mandatory practice?"  If 
> the latter, I have some concerns.  I think that binding a card to a 
> specific subject (whether in the card ID or some other way) should 
> be optional.  It may be useful in some situations for some card 
> issuers, but should not be required for all card issuers.  I can see
> use cases where a managed card issuer simply wants to give everyone 
> the same kind of card.  For example, a card that specifies a UNPW 
> auth type could actually be used for many different users - because 
> the binding to a specific subject is a late binding - it only 
> happens after the card has been selected and the user has been 
> prompted to enter a username and password.  What should the ICard.
> getSubjectId method return in such a use case?
> 
> Given this, I don't think it should be mandatory that card Id 
> identify a specific subject - I would rather see it promoted as an 
> optional best practice for card issuers who want their card Ids to 
> uniquely identify a subject.
> 
> Daniel
> 
> >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/8/2007 12:02 AM >>>
> Here at EclipseCon I got a few minutes to chat with Mike McIntosh. It
> prompted this email.
> 
> Proposal: For Higgins CardSpace-compatible i-cards we set the "cardId" 
field
> (see 'getCardId()' in [1]) to the string value: 
> 
>   <contextId> / <subjectId> / <auth>
> 
> E.g. 
> 
>   http://example.com/HR-dept/ptrevithick/UNPW
> 
> Where:
>   <auth> is either "UNPW", or "Personal", or "Kerberos" or "X509"
> 
> The four auth values are the four allowed auth methods MSFT defined to
> authenticate to a card. "Personal" means using a Personal i-card.
> 
> Why append the <auth> value? Because: (a) every cardId must be unique to 
a
> provider/TS and (b) a person might want to use 1<N<5 different auth 
methods
> for the same data set (i.e. the same subject within the same context) 
and
> (c) MSFT doesn't support N>1 auth methods for a single card.
> 
> -Paul
> 
> [1] http://wiki.eclipse.org/index.php/I-Card_Interfaces#ICard_Interface 
> 
> _______________________________________________
> 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