openid.delegate explained.

[Dick Hardt]

fwiw: I was -1 on Josh's proposal. I am now a 0.

I think the name "delegate" is the right name though. It made sense  
to me right away. One URI is delegating to another URI to be  
authoritative about it. Drummonds explanation just reinforced my  
view. But perhaps I am missing something there.

-- Dick

On 3-Oct-06, at 1:41 PM, Marius Scurtescu wrote:

> 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
>>
>>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>