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: phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.
"Hallam-Baker, Phillip" <> on 08/20/2001 03:22:29 PM
Please respond to "Hallam-Baker, Phillip" <>
To: George Robert Blakley III/Austin/IBM@IBMUS, "Hallam-Baker, Phillip"
<>
cc: Marlena Erdos/Austin/Contr/IBM@IBMUS,
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.
781 245 6996 x227
> -----Original Message-----
> From: George Robert Blakley III [mailto:]
> Sent: Monday, August 20, 2001 2:19 PM
> To: Hallam-Baker, Phillip
> Cc: Marlena Erdos;
> 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: phone: +1 512 436 1564)
> Chief Scientist, Security and Privacy, Tivoli Systems, Inc.
>
>
> "Hallam-Baker, Phillip" <> on 08/20/2001
> 12:48:45 PM
>
> Please respond to "Hallam-Baker, Phillip" <>
>
> To: George Robert Blakley III/Austin/IBM@IBMUS, Marlena
> Erdos/Austin/Contr/IBM@IBMUS
> cc:
> 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.
>
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: George Robert Blakley III [mailto:]
> > Sent: Monday, August 20, 2001 1:06 PM
> > To: Marlena Erdos
> > Cc:
> > 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: phone: +1 512 436 1564)
> > Chief Scientist, Security, Tivoli Systems, Inc.
> >
> >
> > Marlena Erdos <> on 08/20/2001 12:59:25 AM
> >
> > To:
> > 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>
> >
>
>
>
>
>
