I am keen for the RP to identify itself when it performs discovery – and I 
would love this feature to be in 2.0 before it is finalized.

The proposal is very simple (to describe and to implement):
RPs add a “From:” HTTP header field to HTTP requests made during the discovery 

The underlying premise is that a user has many varied user<->RP relationships, 
and it is easiest if the same OpenID URL can be used to access them all.
The issue is how to support the varied relationships. Some OPs will support 
some variations, but no OP can support all possible variations (many are 
user-specific). Identifying the RP during discovery enhances the ability to 
choose the appropriate OP for a specific user<->RP relationship.

The need for this feature can be seen in the PAPE draft (§3 Advertising 
Supported Policies) and OpenID 2.0 draft (§12 Extensions). They support 
different OPs when authenticating to different RPs - but with very limited 
options, and with the RP in control of the choice. The user (via the server 
hosting their OpenID URL) should also be in control.
Both specify how a Yadis document can list multiple OPs, each associated with 
different OpenID protocol versions, understanding different OpenID extensions, 
and supporting different authentication policies. These details “aide in the 
process of a RP selecting which OP they wish to interact with”.

The appropriate OP can only be chosen **by the RP** based on a very limited set 
of pre-defined <xrd:Type> URIs. When that works… great. When it doesn’t, the 
site hosting the OpenID URL should be able to choose the appropriate OP based 
on the RP’s identity. For that it needs the RP identity during discovery, hence 
the “From:” HTTP request header.

Previously mentioned use cases:
Alice wants to use a single OpenID URL and --
1. She wants to use different OPs when logging in to different RPs.
2. An OP is not accessible to particular RPs (eg an internal company OP is not 
accessible by RPs on the Internet).
3. Different RPs whitelist different (non-overlapping) sets of OPs.
4. A particular RP requires PAPE support, which only Alice’s non-preferred OP 

From: Manger, James H 
Sent: Wednesday, 17 October 2007 12:59 PM
To: 'specs@openid.net'
Subject: [OpenID] identify RP when it gets OpenID URL

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: [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.
specs mailing list

Reply via email to