[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Representing anonymous Subjects
Phill, I agree sorta. > I have the same concerns about what happens when the assertion is >passed on. Perhaps such assertions should have an >AudienceRestrictionCondition that specifies a single party so that they >can't be passed on I think we should define in bindings and profiles what restrictions should be imposed via AudienceRestrictionCondition on bearer assertions. This should often (perhaps even "by default") be specification of a single party, but if your profile has a good reason to pass bearer assertions in a more profligate way, and if your trust model supports doing so safely, then there should be no limitation on your ability to specify a binding or profile which does this. I do not believe we should impose any restriction on the use of bearer assertions in the core spec. --bob Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) Chief Scientist, Security and Privacy, Tivoli Systems, Inc. "Hallam-Baker, Phillip" <pbaker@verisign.com> on 08/20/2001 03:22:29 PM Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com> To: George Robert Blakley III/Austin/IBM@IBMUS, "Hallam-Baker, Phillip" <pbaker@verisign.com> cc: Marlena Erdos/Austin/Contr/IBM@IBMUS, security-services@lists.oasis-open.org Subject: RE: Representing anonymous Subjects Bob, I agree sorta. IF we get the security considerations well enough understood then I don't mind it having its own element. Otherwise using the authenticator type works fine and does not imply that we are endorsing a specific mode of use which we may not fully understand. I have the same concerns about what happens when the assertion is passed on. Perhaps such assertions should have an AudienceRestrictionCondition that specifies a single party so that they can't be passed on 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 2:19 PM > To: Hallam-Baker, Phillip > Cc: Marlena Erdos; security-services@lists.oasis-open.org > Subject: RE: Representing anonymous Subjects > > > Phill, > > I "sort of agree" -- I think that whether "bearer" is the > default or not > should be up to the specifier of the binding, > which is to say that I think "bearer" ought to be a > first-class subject > option like the other three, and that it ought > not be possible to specify any of these options by simply omitting the > element -- you ought to have to explicity > choose a subject representation and put the element in in order to get > anything. > > As far as implementation of the "bearer" element is > concerned, I guess what > I'm worried about is that if we > want to be able to pass assertions along a chain of calls and > achieve the > same effect as delegation but by > the mechanism of passing bearer assertions, we can't do that > unless the > "bearer" nature of the assertion appears > inside the assertion structure itself. > > Or am I missing something? > > PS I realize this is really dangerous, but there are trust > structures where > it makes sense INSIDE a distributed > application with several components. > > --bob > > Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) > Chief Scientist, Security and Privacy, Tivoli Systems, Inc. > > > "Hallam-Baker, Phillip" <pbaker@verisign.com> on 08/20/2001 > 12:48:45 PM > > Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com> > > To: George Robert Blakley III/Austin/IBM@IBMUS, Marlena > Erdos/Austin/Contr/IBM@IBMUS > cc: security-services@lists.oasis-open.org > 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> > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC