[OpenID] identify RP when it gets OpenID URL

[John Panzer]

Wouldn't User-Agent: be equivalent, and have prior art (feed readers 
such as Bloglines identify themselves via User-Agent)?

Manger, James H wrote:
>
> It can be useful to know who the Relying Party (RP) is during the 
> discovery phase. That is, the RP should state their identify when they 
> are looking up a user’s OpenID URL (Claimed Identifier).
>
>  
>
> *Use case*: Alice wants to use different OPs for different RPs, while 
> keeping the same URL (eg http://alice.example.net/). For instance, 
> when logging into a service hosting her backups she wants to use an OP 
> that requires a one-time password from a hardware token for each 
> access. However, when leaving comments on blogs Alice wants to 
> authenticate using an OP that only requires a password and uses a 
> persistent cookie so she only has to log in once a day.
>
>  
>
> *Problem*: Only one OP can be specified with a <link 
> rel="openid2.provider"…/> element or in a Yadis document.
>
> [A Yadis document may be able to list many OPs, but I don’t think 
> there is any mechanism for the RP to pick the right one.]
>
>  
>
> *Solution*: The RP could include a From HTTP header when performing 
> discovery.
>
> Instead of serving a static HTML page (or Yadis document) at 
> http://alice.example.net/, the page could be dynamically generated 
> based on the value of the From header.
>
>  
>
> Suggested text for the authentication spec (draft 12):
>
> Add the following paragraph at the end of section 7.3 Discovery:
>
> “The Relying Party MUST include a From HTTP header field in each HTTP 
> request made during discovery. The From field holds an email address 
> for the RP (eg From: openid at example.net <mailto:openid at example.net>) 
> [RFC2616]. This enables the discovered information to vary based on 
> the RP. The From field is not authenticated so it is not appropriate 
> to use for access control.”
>
>  
>
> *Other solutions*:
>
> The source IP address of the discovery request will often identify the 
> RP, but this would be an unreliable mechanism due to proxies, 
> clusters, load balancing, and changes at the RP.
>
> Separate user-supplied identifiers could be used, but that 
> unnecessarily complicates the system for users.
>
> OPs can offer different authentication mechanisms based on the 
> openid.return_to or openid.realm parameter in an authentication 
> request. However, the user has less flexibility when they have to 
> relying on OPs.
>
>  
>
> James Manger
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20071016/41f30114/attachment-0002.htm>