RE: [OpenID] identify RP when it gets OpenID URL

[Manger, James H]

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 
phase.

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.
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#advertising
http://openid.net/specs/openid-authentication-2_0-12.html#extensions
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  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 
supports.


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  
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
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [OpenID] identify RP when it gets OpenID URL

[Manger, James H]

PAPE may be another approach (to support per-user per-RP login policies). It 
certainly will not always be “cleaner”. It is not a reason against enabling a 
discovery-based approach.

This PAPE suggestion requires the RP and OP to implement what the user wants. A 
discovery-based approach only requires the web site hosting the user’s 
identifier to implement what the user wants.

 

> The PAPE-enabled backup service requests that the OP authenticates Alice

> in a manner compliant with certain policies,

> that are satisfactory to Alice's security requirements for a backup service.

 

PAPE must be implemented by the backup service AND the OP. Alice’s policy must 
be expressible in PAPE’s language. The backup service must have a GUI for Alice 
to choose her security requirements. The backup service has to remember 
per-user login requirements – which is rather at odds with a main point of 
OpenID of the RP not having to be involved with how Alice is authenticated. 
Every other RP where Alice wants to tweak her login policy also needs to 
support this… Please don’t make this the only way to implement this style of 
feature.

 

There have always been 4 entities in an OpenID login: the user (with a 
browser); the OP; the RP; and the web site hosting the user’s identifier. The 
last entity can simply be a static HTML page, which is a huge bonus. 
Identifying the RP to this entity enables (but doesn’t require) it to be more 
than a static page – when that is useful (ie for users, circumstances and 
functions where it turns out to be the easiest implementation point).

 

_
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 18 October 2007 4:15 AM
To: Manger, James H
Cc: specs@openid.net

 

I believe there's a cleaner way to address this, that would not 
complicate the things that Alice needs to know about the inner workings of 
OpenID (and without her having to use different identities for different 
purposes):

 

The PAPE-enabled backup service requests that the OP authenticates 
Alice in a manner compliant with certain policies, that are satisfactory to 
Alice's security requirements for a backup service.

 



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

…

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.”

…

 

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

RE: [OpenID] identify RP when it gets OpenID URL

[Manger, James H]

James Henstridge,

> why wouldn't this alternative [doing it all at the OP] be appropriate?

It would be great if OPs offered lots of functionality (such as per-User per-RP 
policies), while remaining simple to use and understand. The great feature of 
OpenID is that is allows each user to choose login policies they are happy with 
without requiring explicit support by the RP. It would be even better if any 
user can choose login policies without requiring explicit support by a single 
OP for all the possibilities.

 

> You are trading complexity at the OP end for complexity at the 
> discovery/delegation end.

Being able to trade complexity at one point against another is a GOOD thing. 
You can pick whichever is less complex to you. Others can pick whichever is 
less complex to them.

The proposed change is not at all complex: an RP simply adds one more HTTP 
header with a fixed (for the RP) value. The discovery end does not have to do 
anything – it is just easier for them if they want to do something a little 
different.

 

> 1. using an OP that is not publicly accessible for certain operations

> 2. using an RP that will only authenticate people using a particular OP.

These are additional use cases that highlight how useful knowing the RP during 
discovery (eg via a From field) could be. Now we have 3 use cases for this 1 
simple feature.

 

_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James 
Henstridge
Sent: Wednesday, 17 October 2007 5:26 PM
To: Manger, James H
Cc: specs@openid.net

 

OPs can offer different authentication mechanisms

If the primary aim is just to let the user set a policy on how 
carefully they should be authenticated when talking to particular RPs, why 
wouldn't this alternative be appropriate?

 

You are trading complexity at the OP end for complexity at the 
discovery/delegation end.

 

Or are you trying to address a slightly different problem?  Maybe one 
of:

 1. using an OP that is not publicly accessible for certain operations  
2. using an RP that will only authenticate people using a particular 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

…

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.”

…

 

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

Re: [OpenID] identify RP when it gets OpenID URL

[Johnny Bufu]

On 16-Oct-07, at 7:58 PM, Manger, James H wrote:

> 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.

I believe there's a cleaner way to address this, that would not  
complicate the things that Alice needs to know about the inner  
workings of OpenID (and without her having to use different  
identities for different purposes):

The PAPE-enabled backup service requests that the OP authenticates  
Alice in a manner compliant with certain policies, that are  
satisfactory to Alice's security requirements for a backup service.


Johnny

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

Re: [OpenID] identify RP when it gets OpenID URL

[James Henstridge]

On 17/10/2007, Manger, James H <[EMAIL PROTECTED]> wrote:
> Other solutions:
>
> 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.

If the primary aim is just to let the user set a policy on how
carefully they should be authenticated when talking to particular RPs,
why wouldn't this alternative be appropriate?

You are trading complexity at the OP end for complexity at the
discovery/delegation end.

Or are you trying to address a slightly different problem?  Maybe one of:
 1. using an OP that is not publicly accessible for certain operations
 2. using an RP that will only authenticate people using a particular OP.

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

RE: [OpenID] identify RP when it gets OpenID URL

[Manger, James H]

The User-Agent field does not have the right semantics. I hope that field could 
be used, for instance, to notice which Relying Parties are using a particular 
version of Janrain’s Java library for OpenID. It is probably reasonable for 
Bloglines, Google etc to identify themselves in the User-Agent field as they 
probably use proprietary purpose-built clients. Most OpenID RPs will not use 
proprietary clients.

The From field feels more appropriate for this OpenID purpose.

 

 



From: John Panzer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 17 October 2007 2:36 PM
To: Manger, James H
Cc: specs@openid.net
Subject: Re: [OpenID] identify RP when it gets OpenID URL

 

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

Manger, James H wrote: 

…

 “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.”

 …

 

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

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