openid.delegate explained.

[Marius Scurtescu]

I think that the proposal made by Josh makes sense.

First of all, why would you hide the claimed identifier from the IdP?  
If you don't trust your IdP you should not use it. Same thing if the  
IdP tries to charge you more because you are using delegate  
identifiers. If it is unreasonable then move on (and it actually can  
be a reasonable thing to do, not sure).

I can see three problems with the current scheme (adding to the  
problem highlighted by Josh):

1. It is hard to implement a stateless RP.

2. The flow can get confusing for the end user. The RP and the IdP  
are presenting different identifiers to him.

3. Bare responses will not work.

A question about doing discovery on delegated identifiers. Would you  
expect the exactly same XRDS from both the claimed and delegated  
identifiers?

Marius

On 3-Oct-06, at 12:13 PM, Josh Hoyt wrote:

> On 10/3/06, Brad Fitzpatrick <brad at danga.com> wrote:
>> but LiveJournal.com knows jack shit about bradfitz.com ... and
>> perhaps Brad doesn't trust LJ to know about bradfitz.com ...
>> or fears LJ might charge more to use that feature.  etc.
>
> What my protocol change proposal[1] amounts to is making the IdP do
> the work, which does change this aspect of delegation. It doesn't
> change the "portability" of identifiers. In fact, it's a seamless
> transition from the perspective of users, unless their IdP sucks.
> Because OpenID is decentralized, if you're using delegation, you can
> choose an IdP that doesn't suck (for whatever your definition of suck
> is), so I don't think it's a real issue.
>
> Josh
>
> 1. http://openid.net/pipermail/specs/2006-September/000002.html
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>