What is delegation for? (was Re: Wrapping Up Proposals)

[Recordon, David]

Good digging, teaches me my OpenID history. :)

So then I still agree that request nonce can be achieved with the
return_to URL and then my argument for not making the delegation change
goes away.

Brad, thoughts on the delegation proposal?
http://openid.net/pipermail/specs/2006-September/000002.html

--David 

-----Original Message-----
From: joshhoyt at gmail.com [mailto:joshhoyt at gmail.com] On Behalf Of Josh
Hoyt
Sent: Monday, October 02, 2006 6:44 PM
To: Recordon, David
Cc: specs at openid.net
Subject: What is delegation for? (was Re: Wrapping Up Proposals)

On 10/2/06, Recordon, David <drecordon at verisign.com> wrote:
> * IdP-supported Delegation
>         While it reduces complexity, it means that each IdP now has to

> handle delegated identifiers as well.  As the point of delegation is 
> to use an identifier your IdP doesn't assert, for whatever reason, I 
> have a hard time having the IdP know what identifier you're using as 
> it may decide it doesn't like that.

The way that I understand it, the primary benefits of delegation is to
provide a standard way to use an arbitrary indentifier with any OpenID
IdP. I think that using an identifier "your IdP doesn't assert" is
really an accident. I haven't looked back through the whole discussion,
but Brad proposed in June 2005[1] that the delegate be sent in the
request, so I can't buy the argument that keeping the identifier secret
was a motivator in the design of delegation.

My delegation proposal is not very different from the one in Brad's
message. That mechanism I'd also be in favor of, because it is still
explicit about what is going on (easier to understand and debug, less
state for RP to track).

Josh

P.S. we should get a copy of the old list archives on openid.net for
reference purposes, or at least link to them from somewhere

P.P.S Brad also proposed at around the same time[2] adding a (request)
nonce, which was rejected because you could just add it to the return_to
URL

1. http://lists.danga.com/pipermail/yadis/2005-June/000676.html
2. http://lists.danga.com/pipermail/yadis/2005-May/000180.html