[OpenID] A Case for OpenEmailID

[Martin Atkins]

Dick Hardt wrote:
> 
> On 4-May-09, at 1:15 PM, Martin Atkins wrote:
> 
>> David Recordon wrote:
>>> As for OP portability (aka delegation), I think this is a property 
>>> that must remain for URLs though is less important for email 
>>> addresses.  With URLs you can delegate on the URL basis ignoring the 
>>> domain or path.  With email addresses, I think it's alright to have 
>>> one OpenID Provider for the entire domain instead of optimizing for 
>>> the case of each user at the domain having their own Provider.
>>
>> It would be a shame to lose the ability to delegate if you switch to 
>> email addresses. The main use-case for delegation was folks with 
>> vanity domains, and people have vanity domains for email too. I don't 
>> want to have to run my own OP just to make 
>> mart at degeneration.co.uk work as an OpenID identifier.
>>
>> Is there some reason why the delegation approach doesn't work for 
>> email too? It seems like all that needs to change for email is how you 
>> find the information, not what information is found.
> 
> Would allowing a vanity domain delegate it's OP support to another host 
> work?
> 

In theory, though in that case it probably wouldn't be delegation in the 
traditional sense but rather just a provider giving you OP service on 
your domain.

So, to use HTML discovery terms, you'd point openid2.provider but not 
openid2.local_id, and that provider would need to be pre-configured to 
understand identifiers in your domain.

This achieves many of the goals of delegation. One of the original goals 
was to be able to do it in spite of the provider so that it would become 
a fundamental protocol feature rather than a value-add service provided 
by some providers, which is defeated here. However, OpenID 2.0 already 
defeated it somewhat by adding the openid.claimed_id parameter and thus 
allowing the provider to detect and potentially block delegation.