RE: Representing anonymous Subjects

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

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>
> >
> 
> 
> 
> 
>

Phillip Hallam-Baker (E-mail).vcf