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