[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ..the notorious bearer subject..
Hi Evan,
(I'll respond on Tim's behalf, since he's out of the office this week...)
----------
From: Evan Prodromou[SMTP:eprodromou@securant.com]
Sent: Monday, July 16, 2001 7:04 PM
To: security-services@lists.oasis-open.org
Subject: Re: ..the notorious bearer subject..
>>>>> "TM" == Tim Moses <tim.moses@entrust.com> writes:
TM> Evan - To my mind, anonymity and authentication method are
TM> separate issues.
Absolutely. But I don't see "bearer" as an "authentication method."
I suspect we have different ideas about what "authentication" means.
Are you using "authentication method" to mean, "how the relying party
determines that an assertion really applies to some subject"?
Yes.
TM> It is possible for an anonymous individual to be strongly
TM> authenticated, not merely through possession of a bearer
TM> token.
OK, well, I guess I'm a little confused, then. We're talking about the
"bearer" option that appears in multiple places on the whiteboard from
F2F3, right?
An example of this is the "holder-of-key" option. This option effectively says, "anyone who can prove possession of the private key corresponding to the public key contained in this token (e.g., through a challenge-response protocol) is the subject/holder/owner/etc. of this token." If no name or identifying information is present in the token, then the subject is strongly authenticated even though s/he is anonymous. This has nothing to do with possession of a bearer token.
TM> On the other hand, it is possible for a uniquely-identifiable
TM> individual to be authenticated through a bearer token.
I'm having a hard time seeing how that one works. I guess I thought of
the "bearer" in most of the diagrams as being XOR'd from any other
identity.
An example of this is a token that has a name or other identifier in the subject element, but contains no "authenticator" (or whatever we have decided to call it) element. In this case, an individual is uniquely identified, but anyone who happens to hold/present the token is assumed to be that individual (i.e., presentation of this bearer token is effectively the "authentication" step). This is a generalization of the cookie model, where presentation of the cookie effectively means that this browser showing up at my door now is the one to which I originally gave the cookie.
TM> So, I think bearer tokens are only as applicable in the
TM> anonymous case as they are in all other cases.
OK. I guess I was seeing it as replacing the subject in some
assertions. For de-identified* subjects, I guess there are a few other
ways of specifying the subject besides "bearer" (e.g., holder-of-this-key).
~ESP
Tim's only point was that since you can have anonymity with or without authentication, and authentication with or without anonymity, these concepts must be separate.
Carlisle.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC