Call directed identity "anonymous login"? (was RE: concerns abouteach user having a unique "URL")

Sat Nov 11 21:57:46 UTC 2006

Eve,

Wonderful analysis. I think it fits well with Dick's suggestion of
distinguishing between Public and Private Identifiers, and also with Saeed's
suggestion of calling the overall feature "Privacy-Protected Login".

Thanks also for pointing out how/where this set of use cases fits within the
SAML framework.

I'll incorporate this into my editorial feedback to the editors on pre-Draft
11.

=Drummond 

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Eve L. Maler
Sent: Saturday, November 11, 2006 7:23 AM
To: general at openid.net
Subject: Re: Call directed identity "anonymous login"? (was RE: concerns
abouteach user having a unique "URL")

The terminology question being asked here seems to pick up on the 
point of confusion I described -- confusingly -- in my blog post on 
"pseudonym picking":

http://www.xmlgrrl.com/blog/archives/2006/10/24/pseudonym-picking/

The way Drummond described it to me (reiterated by his mail quoted 
below), there can be two reasons why you might want to tell the 
relying part what IdP to go to but not hand the relying party your 
identifier at that moment.  The first is that you can do what I 
might call "late binding" of your choice of digital identity over at 
the IdP, which lets you pick the specific persona you want to use. 
The persona might or might not be associated openly with a natural 
person, so "anonymous login" as a proposed term doesn't sound 
general enough.  (Sorry, Drummond.)

The second is that you never want the relying party to have a "real" 
identifier of yours, so that you can arrange with the IdP to pick "a 
one-time URL/XRI generated by the IdP just for this relationship". 
This pretty much follows the textbook definition of a pseudonym, 
though "anonymous login" seems like an odd name since you're not 
really anonymous to the guy you actually log in to.  (Sorry again!)

Please forgive the SAML-flavored analysis that follows; it helped me 
understand how to line up the concepts and maybe suggest other 
terminology options.

The typical SAML single sign-on flow doesn't involve the user 
handing the relying party their identifier; only when redirected 
from the relying party to the IdP they authenticate as "someone" -- 
and of course, if they have multiple digital identities managed by 
that IdP they're free to choose whichever they want at that point. 
This matches the first situation above: late binding of 
identity-choosing.  It would be similar to users always supplying 
merely an OpenID Provider URL to relying parties.  SAML doesn't 
prevent your providing additional information to the relying party, 
like the desired identifier to authenticate you against, but it's 
not needed in order to have the relying party ultimately "let you in".

If instead the user agrees to the relying party and IdP setting up a 
special relationship with each other and her, explicitly for her 
benefit (called "federating" in SAML), the identifier that passes 
between those parties is typically a privacy-preserving pseudonym 
(one-session or long-term), and the user never sees or picks it. 
This sounds quite close to the one-time URL/XRI situation above, 
except for the user knowing/not knowing the pseudonym.  (My question 
in my blog post was: Isn't there some risk in the user trying re-use 
that pseudonym elsewhere?  What's the value in their picking and 
knowing a one-time-use identifier?  Drummond's comments below seem 
to suggest that there is indeed some risk.)

Coming back to the terminology issue, there are really two stages here:

1. Choosing to provide information to the RP that:
    a. does
    b. doesn't yet
    expose an identifier of yours

and, if #1b,

2. Choosing an identifier at the IdP that, according to the user:
    a. is
    b. isn't
    intended to be persistent across time and/or more than one RP

To date, my impression (unsupported by the spec text, by the way) is 
that #1b is called "directed identity", and there's a desire now to 
find a term that more specifically captures the combination of #1b 
and #2b but it's causing a few problems when #2a is in the mix. 
(Slightly off-topic, perhaps, but the whole #2 category is a bit 
fuzzy and continuum-like...)

Since these are literally two stages as far as the user and protocol 
are concerned, why smash everything into one name?

#1: Today, this is generically called initiation and user input in 
the spec.  Seems fine.

#1a: Today, this is just "the user providing a (claimed) OpenID 
identifier" of their choosing to the relying party during initiation 
-- still fine.

#1b: Today, the spec calls this "the user providing the 
IdP/OP/authentication authority :-) identifier" of their choosing to 
the relying party -- still fine.

#2: Today, this is "choosing an identifier" in Section 11 -- perhaps 
could use clarification that it's *post-initiation* identifier 
selection or identifier selection *at the IdP*.

#2a vs. #2b: I can't find any existing terminology in the spec 
related to this choice.  If you want to keep the word "login" in 
here, which is simple and evocative, then "login with a (regular or 
public) identifier" for #2a and "login with a secret (or private or 
privacy-preserving) identifier" for #2b.  There might even be 
benefit in managing privacy risks by using these names in 
specs/documentation, since it reinforces that the user will have a 
responsibility around secrecy if they want privacy and they'll know 
to what extent an identifier is still secret.

Alternatively, how about "pseudonymous federation"?  (Joke!)

	Eve

James A. Donald wrote:
> Drummond Reed wrote:
>  > The term Josh uses, "IdP-driven identifier selection",
>  > is technically accurate, but somewhat like "directed
>  > identity", I fear I it will be lost on the general
>  > public.
>  >
>  > The best candidate I can think of so far is "anonymous
>  > login", because that seems to go straight to the heart
>  > of the benefit to the End User.
>  >
>  > Is it strictly anonymous? No, it's pseudononymous.
>  > Furthermore, using IdP-driven identifier selection, an
>  > End User could in fact use this feature and end up
>  > deciding to use one of their public, easily
>  > correlatable Claimed Identifiers. So it's not always
>  > strictly pseudononymous either.
>  >
>  > But "anonymous login" still seems to be the best name
>  > I can think of that lets the general public quickly
>  > grok the essence of this feature.
>  >
>  > Does anyone else have a better suggestion?
> 
> Cypherpunks and the cryptonomicon discuss identity at
> considerable length.  In their terminology, it is nymous
> login.
> 
> The user can have as many nyms as he pleases, thereby
> controlling the extent to which his identity is
> revealed.  "Nym" merely means name, but the association
> with "anonymous" and "pseudonym" implies that it can
> easily be a cheap and disposable name, or a name that is
> one of a rather large number of names that cannot be
> easily linked to each other by outsiders.

-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general