[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Representing anonymous Subjects
[Hal] > 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. [Carlisle] > I disagree with the above paragraph. To me, anonymous means > "anonymous in every sense" (that is, not only do you not know > who is at the other end, but there is no traceability between > sessions either). A vending machine is a server; requesters > insert money and ask for a chocolate bar or pop or whatever, > but the server has no idea who is requesting and has no idea > whether or not they've ever visited before. This is anonymity. > If you want to be able to determine that "two sessions that > this person conducts were conducted by the same person", this > is the purpose of pseudonymity. Whether the pseudonym is of > the form "USER123456", "Donald Duck", or an entirely random > bit string (i.e., whether or not it can potentially be > confused with a legitimate human name) is, I think, > unimportant. The whole point is that it is different from > the actual human name of the person conducting the session > (and can't readily be linked to this name), but allows > traceability between sessions. [Note: pseudonyms that > cannot be confused with legitimate human names are preferable > (so that different sessions are not inappropriately linked > together), but I don't think this is mandatory.] I am not sure we disagree. If we do the difference is the granularity of anonymity. When ever you do anything on the network a bystander can determine "something" about you, namely the fact that you did that act. e.g. Accessed Yahoo.com at 15:23 20-Aug-01. It is the ability to tie this act with other act that defeats anonymity. You started with a vending machine. (Incidentally it is my favorite example for explaining object encapsulation, but I digress.) Here no two requests can be connected. But then you say traceability "between sessions." This is exactly what I was proposing. In my scheme, a new random identifier would be issued for each session. I was assuming that given a session protocol, it would be infeasible to have finer grained anonymity than this. Note that since a user can generate multiple sessions, it would not even be possible to draw negative inferences, e.g. these requests came from different people. So why do I want an identifier that is not blank? Because I am thinking about environments like Shiboleth where users are anonymous, but some of their attributes can be determined. "This anonymous user is a registered student of a participating institution." But you say, that means somebody must know the "real" identity. True, but in practice, the user will have authentiated orginally via U/P or Kerberos or something which includes are real or pseudonomous identity associated with the long term credentials. [Carlisle] > So, in my opinion, anonymity requires a blank subject name. > (Note: this is a "necessary-but-not-sufficient" sense of > "requires". I recognize that there may be other things in > the assertion or in the transaction itself that will allow > traceability. I can pay cash at a store to try to achieve > anonymity, but if I show up the next day to buy something > else and happen to get the same teller, traceability may > certainly be possible.) Pseudonymity, on the other hand, > requires a subject name to be present. Therefore I disagree that a blank subject name is required for anonymity. [Carlisle] > One final comment. The above discussion pertains to the > presence or absence of a subject name, and traceability with > respect to its contents, if present. However, the presence > of an authenticator field (or whatever we decide to call it) > with a value other than "bearer" allows the possibility of > traceability between unnamed session conductors. "I've no > idea who this is, but it's the same entity as this other time > because the same private key was used to authenticate (or the > same password was supplied, or whatever)." This is not > anonymity in the truest sense {no identity; no traceability}, > but is still a form of anonymity {no identity; traceability}. > Pseudonymity {false identity} always allows traceability > through the (false) name, and perhaps also through the > authenticator (if not "bearer"). Again you seem to be assuming that the secret associated with the Authenticator has to be a long term one. There is no reason a symmetric or asymetric key can not be issued for the duration of a session and used to bind Assertions to that session. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC