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

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


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>

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