[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Representing anonymous Subjects
I think I agree with Tim, but I am not sure, this discussion has made me a little dizzy. Backing up a bit: 1) We agreed a long time ago (F2F #1 or #2) to allow pseudonomous and anonymous subjects. The distinction made was that former has the weaker property of it not being the same as a meatspace name. (BobB commented at the time that there was no way to prevent this.) SO for example, my entry in some registry is listed as "Donald Duck", or "USER123456" Note that there may well be a person with the legal name of Donald Duck, so it may or may not be clear to either the Asserting or Relying Party whether the name is "real". Anonymous is harder. Here it must not only be not be possible to tie the subject to a human being, but also not determine that two sessions that this person conducts were conducted by the same person. I recently proposed meeting this requirement by issuing an Authentication Assertion with a random value as the subject name. The reason for not using a blank subject name would be to make it possible to request, for example, an Attribute Assertion refering to the same subject. (More on this below) 2) BobB: with regards to ISSUE: [F2F#3-35] I declared this to be an action item for you. I hope your recent email is not all you have to say on this subject, as I was expecting more of an "Ah-ha". Please let us know what you were thinking or declare it to be moot. 3) Although I went along with the idea of three flavors of subject at F2F#3 I now think it was a conceptual mistake. It may be that the current schema can do all the right things, but I think it is important to get the concepts straight. I think I am agreeing with Tim when I say there are two very different concepts being conflated here. The first is Subject. "Who is this?" Possible answers include, o a name that can be mapped to a meatspace name. o A name that is consistently used but cannot be mapped to a meatspace name. o A name that is anonymous to the relying party, but known to the AuthN Authority. o A name that is anonymous to eveybody. The second is the mechanism by which we know that a given Assertion refers to the party who has made a given request. This is what I was calling VoB a couple of months ago. This might be done by digital signature, cryptograpically protected session, bearer token, etc. The two are related in the sense that the choice of the first may constrain the choice of the second. Not all combinations are sensible. However, they are not the same conceptually. For example, the purpose of the subject name is not just to associate a request with an assertion, it may be used to associate one assertion with another. For example, we may know that an AuthN assertion refers to a request, because of an Authenticator or Artifact of some sort, while we know from the subject name that an Attribute Assertion refers to the same requestor. Of course we could associate both this the same Authenticator, but if the AuthN Authority and Attribute Authority are distinct it may be more convenient for the Attribute Authority to deal only in subject names. The current schema would allow this by having both an name and an authenticator, but there are cases when both should not be present, for example if they refer to different entities. I concede we could leave these concepts in a single element and clarify the rules about what gets used when, but my preference is to seperate the two concepts in the schema as well as in our minds. Hal > -----Original Message----- > From: Tim Moses [mailto:tim.moses@entrust.com] > Sent: Monday, August 20, 2001 5:15 PM > To: security-services@lists.oasis-open.org > Subject: RE: Representing anonymous Subjects > > > Bob - Well! Let's have a go. > Bob wrote ... > "I think a bearer assertion is an assertion which refers > indexically to an > unnamed subject and does not require an authenticator." > Tim replies ... > By my understanding, SAML separates this thought into two > unrelated topics: anonymity and bearer authentication. When > it comes to anonymity, look at this fragment from "core 14" ... > <xsd:element name="Subject" type="saml:SubjectType"/> > <xsd:complexType name="SubjectType"> > <xsd:choice maxOccurs="unbounded"> > <xsd:element ref="saml:NameIdentifier" minOccurs="0" > maxOccurs="unbounded"/> > <xsd:element ref="saml:Authenticator" minOccurs="0" > maxOccurs="unbounded"/> > <xsd:element ref="saml:AssertionSpecifier" minOccurs="0" > maxOccurs="unbounded"/> > </xsd:choice> > This allows for the name to be absent, both because the > structure is a "choice" and because the NameIdentifier has a > minOccurs of zero. I realize, of course, that strict > anonymity is more complicated than just leaving the name > blank. But, SAML doesn't aspire to solve such tricky issues. > Now let's look at bearer authentication. In my view, the > Authenticator element MUST be present in an authentication > assertion. But, it may have no associated authentication > data. Consider this fragment ... > <xsd:element name="Authenticator" type="saml:AuthenticatorType"/> > <xsd:complexType name="AuthenticatorType"> > <xsd:sequence> > <xsd:element name="Protocol" type="uriReference" > maxOccurs="unbounded"/> > <xsd:element name="Authorizationdata" type="string" > minOccurs="0"/> > <xsd:element ref="ds:KeyInfo" minOccurs="0"/> > </xsd:sequence> > </xsd:complexType> > The "protocol" element would identify the "Assertion bearer" > authentication scheme, and the "AuthorizationData" (which > should say "AuthenticationData") would be absent - allowed by > the minOccurs = zero. > Bob wrote ... > "I think the mechanism by which an artifact refers to an > assertion should not vary depending on which subject > reference type is used within the assertion." > Tim replies ... > The structure of the artifact is not defined in our schema. > It appears in the Bindings document. It is a 64 bit > assertion identifier. The corresponding assertion carries > the same value in its AssertionID element ... > <xsd:attribute name="AssertionID" type="saml:IDType" use="required"/> > So, the artifact references an assertion the same way > regardless of how the subject is referenced in the assertion. > Bob wrote ... > "But surely an artifact should be able to refer to an > assertion with ANY subject reference type" > Tim replies ... > Absolutely. But, as far as I know, the only use case, and > the only "profile" defined in the Bindings document, that > uses an artifact is the Browser profile, and it happens also > to use the "Assertion bearer" Authentication protocol. > Best regards. Tim. > -----Original Message----- > From: George_Robert_Blakley_III@tivoli.com > [mailto:George_Robert_Blakley_III@tivoli.com] > Sent: Monday, August 20, 2001 4:17 PM > To: tim.moses@entrust.com > Cc: security-services@lists.oasis-open.org > Subject: RE: Representing anonymous Subjects > > > > Maybe. Can you give me an example of the specific schema which > accomplishes this? I have a hard time translating English > into XML (or the other direction, for that matter...) Thanks, > > > --bob > Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) > Chief Scientist, Security and Privacy, Tivoli Systems, Inc. > > > Tim Moses <tim.moses@entrust.com> on 08/20/2001 02:47:24 PM > To: security-services@lists.oasis-open.org > cc: > Subject: RE: Representing anonymous Subjects > > > > > > Bob - I agree with you on all fronts, and the schema > accommodates these > ideas. There is one exception, though. Reference your > second paragraph > ... if the "bearer assertion" is an "authentication > assertion", then it > MUST contain an authenticator. Now, the "authenticator" may > have no value; > i.e. its authentication protocol identifier is "assertion > bearer", but it > is an authenticator nonetheless, and it says: "if a subject > presents an > artifact referencing this assertion, then he/she is the owner of the > attributes in (or linked to) this assertion". > There is a browser profile that has no artifact, then the bearer > authentication assertion must still have an authenticator (as > above). In > this case, the authenticator says: "if a subject presents > this assertion, > then he/she is the owner of the attributes in (or linked to) this > assertion". > No? > Best regards. Tim. > -----Original Message----- > From: George Robert Blakley III [mailto:blakley@us.tivoli.com] > Sent: Monday, August 20, 2001 3:04 PM > To: Tim Moses > Cc: security-services@lists.oasis-open.org > Subject: RE: Representing anonymous Subjects > I think we're having two different discussions at the same time. > I think a bearer assertion is an assertion which refers > indexically to an > unnamed subject and does not > require an authenticator. > It should be possible to generate such an assertion without having to > generate an artifact AT ALL. > I think the mechanism by which an artifact refers to an > assertion should > not vary depending on which > subject reference type is used within the assertion. > I DO NOT think that the assertion should refer to the artifact; the > reference should be strictly one-way > (from the artifact to the assertion). But surely an artifact > should be > able to refer to an assertion with > ANY subject reference type... right? > --bob > Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) > Chief Scientist, Security and Privacy, Tivoli Systems, Inc. > Tim Moses <tim.moses@entrust.com> on 08/20/2001 01:38:58 PM > Please respond to Tim Moses <tim.moses@entrust.com> > To: security-services@lists.oasis-open.org > cc: > Subject: RE: Representing anonymous Subjects > > > > > Bob - Are you just arguing that the assertion should > reference the artifact > (in its "Assertion bearer" element), as well as the artifact > referencing > the assertion? All the best. Tim. > -----Original Message----- > From: George Robert Blakley III [mailto:blakley@us.tivoli.com] > Sent: Monday, August 20, 2001 2:32 PM > To: Tim Moses > Cc: security-services@lists.oasis-open.org > Subject: RE: Representing anonymous Subjects > Tim, > Right... regardless of this though it seems to me that an > implementation > which would support this could easily be > achieved and I don't see any downside to doing it in a way > which would > preserve our flexibility in this regard. > I could make a more abstract argument here. If "bearer" is a way of > describing a subject, in the same way > that "name" or "authenticator" is a way of describing a > subject, we should > use the same mechanism to > describe "bearer" subjects which we use to describe other types of > subjects, so that the processing of > subject descriptors can be localized to a single piece of logic. > :-) > --bob > Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) > Chief Scientist, Security and Privacy, Tivoli Systems, Inc. > Tim Moses <tim.moses@entrust.com> on 08/20/2001 01:22:58 PM > Please respond to Tim Moses <tim.moses@entrust.com> > To: security-services@lists.oasis-open.org > cc: > Subject: RE: Representing anonymous Subjects > > > > Bob - I don't believe the bindings group currently considers > your scenario > "in scope". That would change if we had a use case, of course. Best > regards. Tim. > -----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> > > > > > > ---------------------------------------------------------------- > 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