concerns about each user having a unique "URL"

[Drummond Reed]

Peter,

I'm surprised the 2.0 spec you cite (draft 10) has no mention of directed
identity (I think that's an editorial oversight), because that's what all of
us have been calling the feature. I'm due to give the proposed Draft 11 (not
yet out) take a complete read-through tomorrow, and not being an editor,
this is one of the "fresh-eyes" things I'll be looking for.

There has been much discussion about how this feature and the related
"identifier delegation" feature (that's been in OpenID since the start) will
be specified in Draft 11, so let me reserve comments until I've read through
the proposed Draft 11. Then once it's posted I'll be happy to (or any of the
actual editors can) provide references to where this is covered in the spec.


=Drummond 

-----Original Message-----
From: Peter Watkins [mailto:peterw at tux.org] 
Sent: Thursday, November 09, 2006 4:07 PM
To: Drummond Reed
Cc: general at openid.net
Subject: Re: concerns about each user having a unique "URL"

Drummond Reed wrote:

>> I don't quite understand this about OpenID -- the materials illustrate
>> some sort of user choice, but since all OpenID assertions use the same
>> constant-per-user claimed identifier, the net effect of giving different
>> pieces of info to different parties is that Service Providers, since
>> they all see the same claimed identifier for a given individual, could
>> collude to reconstruct more complete assertion sets than the user would
>> ever disclose to a single Service Provider.
> 
> Peter,
> 
> The "directed identity" feature in OpenID Authentication 2.0 should give
you

Where can I read about this "directed identity" feature? The phrase
"directed" appears nowhere in the 2.0 spec
(http://openid.net/specs/openid-authentication-2_0-10.html).

> what you want. You as the IdP could instruct your users to simply login to
> any OpenID-enabled site (RP) with your IdP identifier (plumbers.co). Then
> plumbers.co as the IdP can return whatever identifier you and the user
agree
> should be used for that RP -- and it can be different for every RP if you
or
> the user desires this behavior.

I don't see that in the spec. Section 10.1 says that the RP *may* set an
openid.identity request value to a special URL, and that if the RP does
so, "the IdP MAY choose an identifier that belongs to the End User". But
the spec says that the openid.identity request parameter is optional.

It looks like it would be completely legal for a 2.0 RP implementation
to never set an openid.identity request parameter at all, which would
not allow my IdP to return an identifier different than the
user-provided OpenID URL.

> In this case, RPs cannot collude on the identifier itself (they may still
be
> able to collude on any shared data -- that's a separate problem). The only

Right. It would be nice if the specs explicitly stated that the IdP
could return a different openid.identity identifier for different RPs,
realms, or (RP + realm) combinations, to further reduce collusion problems.

> one that can do the mapping between all the identifiers given out is the
> IdP, but in the case of directed identity the user is trusting the IdP.

My apologies if I'm being dense, but I don't see how the spec ensures
our users' ability to enter a simple URL that identifies the IdP only.
I do appreciate your assistance.

Thanks.

Peter