[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Representing anonymous Subjects
Actually 'Bearer' does appear in section 4 as one of the Authenticator protocols. My recollection of the F2F was that bearer was mentioned but not specifically brought up as a topic. Tim wanted bearer to be possible but was not that bothered how it was implemented. I did not want bearer to be the default - for much the same reason that Dave O. is proposing to squelch defaulting to wildcard. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: George Robert Blakley III [mailto:blakley@us.tivoli.com] > Sent: Monday, August 20, 2001 1:06 PM > To: Marlena Erdos > Cc: security-services@lists.oasis-open.org > Subject: Re: Representing anonymous Subjects > > > Hmmmm..... > > At FTF3 we took it as implied that we were going to have a > "bearer" option > in the subject specifier. > > However we were pretty sure that our thinking on the topic > was confused; to > quote from FTF3 minutes: > > >ISSUE:[F2F#3-35]: BobB said in an aside that there is something wrong > >with at least some of the occurrences of our use of the "bearer" in > >Subject specifiers in all of the above constructs. Need to get him to > >elaborate in detail on what his observations are. > > I didn't do this, but it also appears that "bearer" has > disappeared from > the schema , probably because I couldn't > find our whiteboard mentions of it at all in the minutes (!) > > We need to add it back and discuss how to get it right. > > I agree with Marlena that we don't currently capture the concept: > > >Summary: I don't think we currently have a good way of representing > >either "bearer" assertions or anonymous assertions gotten > via an artifact. > > A possible solution is the extension of the Subject field to > >include an "anonymous" type. But I'm no > >XML expert. I'm hoping that if others agree that there is a need, > >we can work out the XML specifics. > > I see three possibilities: > > (1) A distinguished name, to be used within the "name" field > of a subject > definition. > > (2) A distinguished public "key" field to be used with the > "holder of key" > (is it called "authenticator" now?) field > > (3) A type-distinct fourth subject option, called "bearer". > > I don't like either (1) or (2) -- I'd rather have (3). I > don't necessarily > think that bearer = anonymous, however, since in either an > authentication > assertion or an attribute assertion, other asserted data may in fact > identify > the subject. However you could USE a bearer token to > implement anonymity. > > Now I need to think about what the issues are and how to get > it right.... > > > --bob > > Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) > Chief Scientist, Security, Tivoli Systems, Inc. > > > Marlena Erdos <marlena@us.ibm.com> on 08/20/2001 12:59:25 AM > > To: security-services@lists.oasis-open.org > cc: > Subject: Representing anonymous Subjects > > > > Dear SAML'ers, > > Recent discussions of the http binding have brought up > two flows that result in assertions about (potentially) anonymous > subjects. These flows either involve an artifact (or "handle" in > Shibboleth) that is used to retrieve an assertion about the > browser user, or involve the assertion being "redirected" (so > to speak) > through the user's browser (via interesting uses of javascript > and "post"). > Various discussions have flowed about impersonation > countermeasures and other aspects of these http-based flows. > I won't repeat them here. Instead, I'd like to raise up the > question of the "Subject" element in the assertion. > > In both flows (artifact or "bearer" assertion), it is possible for > the assertion to have an anonymous (or pseudonymous) subject. (Note > that the assertion could be either an authN or attribute assertion.) > Currently, the Subject element in the SAML schema (version 14) > doesn't seem to have a graceful way of dealing with the sorts of > anonymous subjects that arise from the http binding. > (I'll continue to say "anonymous subjects" to refer to both > anonymity and > pseudonymity, and to mean the http binding case.) Here's > what it does > allow for (to the extent that I understand the schema correctly). > I'll follow with a brief discussion on why none of the options seem > to have a good fit for the anonymous subject case. > > The Subject element allows for 3 different types of identifiers. It > allows for > -- a string "name" qualified by a security domain > -- an "authenticator" field (mostly related to a subject > authenticating with a key) > -- a reference to another assertion or inclusion > ofthat assertion > > Why these don't really fit: > - The string name could be used to convey the contents of > the handle > or the "assertion id" part of the artifact, but neither of these is in > any way a subject 'name'. I suppose that the RP could use the fake > name as a real name in its continued processing, but that is > conceptually incorrect, and it feels like looking for trouble to me. > (One concrete difficulty is how an RP could meaningfully have > the notion > of "anonymous" in an authZ policy if it can't tell the difference > between a fake name referring to an anonymous user and a real > user name.) > - The authenticator field strikes me as being mostly related to > subjects with keys, but Phill (in a phone call with me) suggested > that it could be used for the anonymous browser user case. I feel > reluctant about this because the association between an anonymous > browser user and an assertion is just that -- an association. > To refer > to it as an authentication just seems like a distortion of > both the term authentication and what is really going on from a > processing standpoint. (That is, the RP validates the association of > user and assertion rather than validating the identity of the user. ) > - The reference to an assertion or inclusion of one doesn't seem > to apply, because anonymous assertions in the http binding are (often) > the initial ones. There is not necessarily any other > assertion to refer > to (and there would still be the question of representing anonymity > in that assertion!). > > > Summary: I don't think we currently have a good way of representing > either "bearer" assertions or anonymous assertions gotten via > an artifact. > A possible solution is the extension of the Subject field to > include an "anonymous" type. But I'm no > XML expert. I'm hoping that if others agree that there is a need, > we can work out the XML specifics. > > > Regards, > Marlena > IBM/Tivoli > > PS My apologies if I've misunderstood the meaning of the fields in > the current schema. I welcome enlightenment. > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC