Re: [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 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: [EMAIL PROTECTED] ) 
[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@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

[OpenID] identify RP when it gets OpenID URL

[Manger, James H]

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  
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: [EMAIL PROTECTED]) [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@openid.net
http://openid.net/mailman/listinfo/specs