[PROPOSAL] Handle "http://user at example.com" Style Identifiers

[Hallam-Baker, Phillip]

Wouldn't it be nice if we could just bypass all the stupid email callback stuff that we usually have to put up with?

Its easy to do, the only constraint being that the IdP has to be able to advertise an SRV record.

IdP advertises 

_openid.example.com  SRV 1 100 80 openid1.example.com


Given an identifier alice at example.com the RP looks for the _openid service, resolves this works out where to resolve the URI. 

This does not have to be the only mode of resolution but it is certainly a very very useful one and something that can be used transparently inline with existing practice. Many sites already use the email address form as an identifier.

Of course there is a spam issue, there is a spam issue with every contact identifier. That's why you use the IdP account and don't muck up your email account.



> -----Original Message-----
> From: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] On Behalf Of Dick Hardt
> Sent: Sunday, October 22, 2006 11:14 PM
> To: George Fletcher
> Cc: specs at openid.net
> Subject: Re: [PROPOSAL] Handle "http://user@example.com" 
> Style Identifiers
> 
> 
> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
> 
> >
> >
> > Dick Hardt wrote:
> >> With OpenID, there is a presumption the user has selected a trust 
> >> worthy IdP that  will only present the user's identifiers when it 
> >> really is the user.
> >>
> > Doesn't this imply that both the user and RP have to know 
> which IdP's 
> > are "trust worthy"?
> 
> It is a choice by the user. Just like the user chooses with 
> ISP to move their data, which browser to run, which OS to 
> run. IN general, those are not dictated by the RP.
> 
> >> Actually, idp.spammers.com cannot do that. The URL has 
> metadata that 
> >> states which IdP(s) are authoritative. What 
> idp.spammers.com can do 
> >> is flood an RP with a bunch of identifiers. But this is no 
> different 
> >> then a script creating new accounts on a system and is 
> defended using 
> >> the same mechanisms such as throttling and captchas.
> >>
> > So why can't idp.spammers.com allow anyone to enter a URI of 
> > http://idp.spammers.com/<name> that resolves to a valid 
> XRDS document.
> > The RP then follows the IdP service link back to 
> > https://idp.spammers.com and does the association exchange. 
>  Now the 
> > RP re-directs the user to https://idp.spammers.com for the 
> login page, 
> > which just re-directs the user back to the RP with the valid 
> > "assertion"
> > fields. idp.spammers.com does not have to ask the user for 
> > authentication credentials (that is out of scope for the 
> spec).  For 
> > commenting on blogs this would be similar to "bugmenot" for web 
> > subscription services.
> >
> > So of course, the RP just needs to "blacklist" 
> idp.spammers.com.  But 
> > now we are back in the same situation we have today where 
> its a race 
> > between spammers setting up "IdPs" and RPs "black-listing" them.
> 
> I don't understand why the RP needs to do that ... is the RP 
> wanting to do something it can't do today?
> 
> >
> > Fundamentally, "trust worthiness" is paramount to making the system
> > work.  For now, this means RPs will likely have some sort of ACL  
> > (black
> > or white) for the IdPs that they deal with.
> 
> The "trust" I am referring to is the user "trusting" the IdP to not  
> let someone else impersonate them.
> 
> George: would you explain what problem you are wanting to solve so  
> that we can deal with a concrete example? There are use cases OpenID  
> solves today, and others require additional features that currently  
> are not in the specification.
> 
> -- Dick
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 
>