OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Representing anonymous Subjects


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

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 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
cc:   security-services@lists.oasis-open.org
Subject:  RE: Representing anonymous Subjects

Actually 'Bearer' does appear in section 4 as one of the Authenticator

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


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
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