openid.delegate explained.

[Martin Atkins]

Josh Hoyt wrote:
> 
> An example to illustrate how delegation can make it hard to understand
> what's going on:
> 
> 1. Set up an IdP that will let me verify, say "bradfitz.com." This
> does not mean that I have any control of bradfitz.com, just that if I
> did, I could use this IdP.
> 
> 2. Set up an identifier, say "j3h.us" to use "bradfitz.com" as a
> delegate, and to use my weirdo IdP.
> 
> 3. Do authentication of "j3h.us" to a RP, and the messages that go
> back and forth will be about "bradfitz.com" and the authentication
> will succeed. The confusing part is that this is the correct
> behaviour.
> 

And all you've achieved here is to hand your identifier over to Brad.


But I agree with you that the delegate identifier might as well just be 
an opaque string per the current spec. This is not inconsistent with my 
post yesterday saying that delegation should be the only case, not a 
special case. There's no disadvantage to this, since the identifier you 
present to your IdP *can* be the same as the one you present to RPs, but 
if delegate is the only mode of operation then it makes the spec simpler 
and thus easier to understand.

(and it no longer needs to be called "delegate", because it doesn't need 
to be called anything other than "the only way to do it".)