| Re: [higgins-dev] cardId syntax |
|
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?
(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?
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 |