OpenID/OAuth hybrid - discovery

2008-11-24 Thread Manger, James H
Section 5 Discovery of the OpenID/OAuth hybrid draft spec says
  xrd:Typehttp://specs.openid.net/extensions/oauth/1.0/xrd:Type
should appear in the XRDS discovery document to indicate support for the 
protocol.


This doesn't seem to be the right way around.

Discovery is performed on a user's OpenID identifier. It does not make sense 
for a user to indicate if an OP supports the hybrid protocol.
Additionally, support cannot be indicated by users who use an HTML page for 
their OpenID identifier (with an link rel=openid2.provider href=.../ 
element).

An OP could indicate that it supports the hybrid protocol in its own XRDS file, 
assuming all users use directed identity and they all use the same OP XRDS 
file. I hope we don't have to hardwire these assumptions into the hybrid spec.
Even in this case, however, indicating hybrid support at the OP is not of much 
use if the RP/consumer cannot tell which protected resources are covered.

For example, adding the hybrid indicator to the Yahoo OP XRDS file 
http://open.login.yahooapis.com/openid20/www.yahoo.com/xrds does not tell an 
app if it can use the hybrid protocol to access:
* Yahoo email address book (probably);
* Flickr photos (maybe?, it is owned by Yahoo);
* Microsoft hotmail (perhaps not currently, but a Yahoo/Microsoft merger was 
discussed earlier this year);
* Picassa photos (presumably not, as it is owned by Google).


Discovery could work if the metadata for the OAuth Service Provider indicated 
it supports the hybrid protocol with a specific OP.

[My preferred way to indicate this would be: a request to a protected resource 
receiving a 401 Unauthenticated response with a WWW-Authenticate HTTP 
header that included the URL of the OP. If that OP URL matches the OP found 
from OpenID discovery on the user's OpenID identifier then the app can use the 
hybrid protocol.]




James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID/OAuth hybrid - discovery

2008-11-24 Thread Manger, James H
Breno,

 The fact that the OP indicates support for hybrid has nothing to do
 with directed identity, of whether or not they use the same XRDS file.

What is section 5 Discovery for?
Is it supposed to allow an app (after finding a user's OP) to make additional 
requests to get the OP's metadata to see if it supports the hybrid protocol?

Learning just that an OP supports the hybrid protocol (without any indication 
of the associated protected resources) seems to be of minimal value.


James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra



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


OpenID/Oauth hybrid

2008-11-19 Thread Manger, James H
How much special knowledge about the OP/SP is an app expected to have to use 
the OpenID/OAuth hybrid protocol?  [and some performance issues at the end]

A common case might be an app built to enhance one specific service. It is 
probably realistic to assume such an app is registered with the SP, and has 
hardwired knowledge about its OAuth URIs, scopes, signing modes etc.

Another case is an app that dynamically learns who a user's OP is (eg from 
OpenID discovery) and which SP the user uses for the service of interest 
(perhaps from the same OpenID discovery). The app notices that the OP and SP 
are the same (how?) and that they support the hybrid protocol (how?). This app 
understands OpenID, OAuth, hybrid, and the type of service of interest -- but 
has no special knowledge about this user's specific OP/SP.

The first case may cover many immediate pain points, particularly as OpenID and 
OAuth are in their infancy. However, a standard would be much more useful for 
the whole community and in the medium term if it supported the second case as 
well.

Even if the discovery aspects are not solved immediately, the hybrid protocol 
should not *preclude* apps without SP-specific knowledge once discovery 
mechanisms emerge.


The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope 
fields to an OpenID request. The former forces the app to be pre-registered. 
The latter requires the app to know about the SP's specific scopes.

It seems possible that more parameters might be required in future: perhaps 
permissions (eg read/write), or lifetime (once-off, for 24 hours, forever).

All these parameters seem to tightly couple the app to the SP.

An alternative is to add one opaque handle to the OpenID request: a request 
token. To add a new scope, offer a new permission, support a new lifetime, etc 
an SP can offer a new URI for getting the new request tokens. As far as the app 
code is concerned it is just a URI, like any other URI. It doesn't necessarily 
need code that understands permissions, or scopes, or lifetimes etc.



Breno de Medeiros said the initial OAuth request for a token adds a (probably 
unacceptable) redundant server-to-server call for *every* authentication 
request.

It may be better for performance to omit the request AFTER the redirect, 
instead of the request BEFORE the redirect.

OAuth involves:
1. get request token
2. redirect user to do authorization
3. swap request token for access token
4. do stuff

Step 3 was added to OAuth to support apps that could not launch/redirect-to a 
browser. Such apps need the user to manually type in a token, which needs to be 
short to be human-friendly. Step 3 allows a short token to be exchanged for a 
longer one that can encode lots of state so the service can operate in a 
stateless (scalable) manner.
Step 3 was kept for all OAuth apps (not just those that could not 
launch/redirect a browser) to keep the spec simple.

The hybrid protocol could save a request/response pair by dropping step 3 (or 
make it optional so apps that cannot launch/redirect-to a browser can use it).


The initial request for a request token (step 1) does not have to affect the 
user experience -- as it can be done in advance. An app could get request 
tokens in the background and cache them until one is needed for a hybrid 
auth/authz redirect.


Keeping step 1 but omitting step 3 means the access token needs to be returned 
in the authentication/authorization response. The request token secret can be 
used instead of getting a new access token secret.

The hybrid spec says [in section 3 Purpose]
  For security reasons, the OAuth access token is not returned in the URL.
It is not clear what these security reasons are. I suspect they only apply 
because the hybrid protocol had dropped the token secret from step 1.


[It might not even be necessary to perform step 1 for *every* authentication 
request. If the returned token simply encodes the scope and/or consumer 
identity, then the service could set a Cache-Control header indicating that the 
token can be reused for, say, any authentication requests in the next day (I 
will have to think about any security implications).
Alternatively define a way for an app to get a batch of request tokens in one 
go.]



James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID/Oauth hybrid

2008-11-19 Thread Manger, James H
Breno,

Thanks for your responses.

 The scopes are needed for the approval page to be rendered.
 The whole thing is meaningless otherwise

I absolutely agree that the auth/authz redirect needs to know what actions are 
being authorized, ie the scope. I don't want to eliminate the scope, just use 
a single opaque token to represent it -- regardless of which aspects any 
specific SP needs the scope to encompass [app id, resources, permissions, 
lifetimes...]. The token comes from a URI, which is what really represents the 
scope.

 You mean that the app has to understand all of the above,
 but will use that knowledge during the discovery process,
 rather than authorization

*Something* has to understand all of the above [scope, permissions, 
lifetime...] -- but it does not have to be the app.
It can be the app. It can be the user. It can be another system that provides 
discovery details. Perhaps it can be a hyperlink on a web page.

The app just has a URI and it flows from there.


 If that [discovery] effort is successful,
 I do not think any of these issues are intractable.

It is conceivable that discovery can provide 'scope' strings, and even 
'consumer' values for unregistered apps -- but that does not feel like it fits 
well with the web architecture. It feels unnecessarily complicated and 
OAuth-specific.
I can image discovery providing:
  A URI for my address book;
  A URI for my calendar;
  A URI for my photos;
  A separate URI for my photos of a particular conference;
I am concerned that with the current hybrid draft, discovery will have to 
define 'scope' strings etc in addition to a URI to access a service. I doubt 
generic web discovery mechanisms will offer that.



James Manger
[EMAIL PROTECTED]
Identity and security team — Chief Technology Office — Telstra
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

2008-11-17 Thread Manger, James H
Dirk, Allen, Brian, etc

How about sending an ‘unauthorized request token’ with the OpenID 
authentication request, instead of a scope or a consumer key?

A Service Provider can choose to encode the consumer key or scope into the 
request token when issuing it if they need those details when interacting with 
the user.

From the OAuth perspective there would be minimal change to the protocol. 
Instead of redirecting the user to the authorization URL (after adding the 
token), the user is redirected to the OP URL (after adding the token). That 
makes it easier to be confident that the hybrid model does not introduce new 
security weaknesses.

Ideally, an app would attempt to access a protected resource at an SP and get:
* A 401 Unauthenticated response from the SP; with
* A “WWW-Authenticate: OAuth” header; with
* A parameter providing the authorization URL; and
* Another parameter with the OP URL (when OpenID/OAuth hybrid was supported).

If the app supports the hybrid mode, and the SP has indicated it supports the 
hybrid mode by including an OP URL in a 401 response, and the user’s OpenID 
identifier resolves (via discovery) to the same OP, then the app can trigger 
the hybrid auth/authz action.

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


RE: Non-interactive logins

2008-07-15 Thread Manger, James H
Hi Anders,

There has been some work on this important issue, though it seems to have been 
dormant for a while.

There seem to be two proposals (by Martin Atkins) using OpenID as an HTTP 
authentication mechanism. It is suitable for non-browser, non-interactive use 
cases.

http://wiki.openid.net/OpenIDHTTPAuth

http://wiki.openid.net/OpenID_HTTP_Authentication


I really like the idea of this basic flow:
1. RP indicates it supports OpenID with WWW-Authenticate: OpenID header;
2. App interacts with the app's OP;
2. App sends OpenID authentication response to RP in Authorization header;
3. RP performs discovery;
4. RP does direct verification with OP.

App --GET xxx-- RP
  --401  WWW-Authenticate: OpenID realm=...--

App  OP   [if necessary]

App --GET xxx Authorization: OpenID opened-auth-request-stuff-- RP

RP --GET claimed_id--
   --discovery XRDS/HTML--

RP --POST ...openid.mode=check_authentication-- OP
   --is_valid=true--

App --200 content--


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


RE: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Manger, James H
As confusing as HTTP redirect semantics might be, I am confident that
you will not find anyone that deliberately chooses to return a 303 See Other
without explicitly wanting to keep the original URL as the identity and
the new URL as merely a (stable, cachable) location for the current response
(eg current OP details). I am confident this will be true for any web
content, not just OpenID.

[Aside: Browsers displaying the new URL in the address bar after a
303 See Other is not a counter-example. The new URL is the address of the
displayed response. It is NOT the address that will be reused if the
original request (eg an HTML form submission) is retried.]

The ability to serve discovery details from a location that is different
from the claimed_id is desired functionality:
1* You can achieve it using X-XRDS-Location (HTTP header or meta element),
but only if you deliver other content (eg HTML) at the claimed_id;
2* You can achieve it using an i-name (by the abstract nature of those ids
and the various synonyms explicitly defined for those ids);
3* You can achieve it via directed identity if your OP cooperates,
and with a very extra request/response pairs;
4* You CANNOT achieve it using standard HTTP (with 303 See Other).

The question is whether OpenID wants to bother supporting #4.

In adding support for XRI/XRDS/i-names OpenID 2.0 made HTTP URIs
somewhat second-class citizens by offering some functionality only
when XRI/XRDS is used, even when sensible HTTP mechanisms
were also available. Two examples are: supporting X-XRDS-Location but not
303 See Other; and indicating an OP Identifier with a special XRDS Type,
but not with a special openid2.identifier value.

For a true-believer in i-names, not offering an HTTP-way for some
functionality is not important (perhaps even helpful for promoting i-names).
For a true-believer in HTTP (less enthused by i-names), the lack of an
HTTP-way is a problem.

Kevin Turner said:
Amend the specification to say:
A request for an OpenID Identifier SHALL NOT issue a 303 response.

Thankyou Kevin, for a lateral solution.
It is not the fix I want (proper HTTP-style support for 303 See Other),
but at least it explicitly tells people that OpenID 2 does not support
303 semantics. That should allow proper 303 support to be added later
without big backward compatibility issues.

[Aside: In practice, OpenID RP libraries would probably not be changed
to explicitly reject 303s -- particularly as your major argument is that
that sort of change makes the code too complex. Rejecting or interpreting
303s both require explicitly handling redirect codes, as opposed to setting
the follow redirects automatically option of the HTTP client library.]

Objections to proper support for 303s don't say the proposal is wrong.
They just imply it is not worth the effort: code too complex, do not have
to obey HTTP, work arounds available, 2.0 is finished.
Not surprisingly, these judgements are not convincing to some
HTTP true-believers.


Perhaps I will add a note to the OpenID 2.0 errata page stating
HTTP 303 See Other semantics are not currently supported so they should
be avoided when hosting OpenIDs.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


openid:Delegate undefined namespace

2007-12-03 Thread Manger, James H
Section 14.2.1 Relying Parties (discussing compatibility with OpenID 1.1) 
says:
  the end user's OP-Local Identifier appears in the openid:Delegate tag
However, the namespace URI associated with the openid namespace prefix is
not defined.
I guess it should be http://openid.net/xmlns/1.0;, which needs to be
mentioned in the spec.


Change openid:Delegate in the 2nd dot point in 14.2.1 to
Delegate xmlns='http://openid.net/xmlns/1.0'
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


[OpenID] HTML discovery for OP Identifier

2007-11-13 Thread Manger, James H
HTML discovery should support OP Identifiers. It is easy. If an OP-Local 
Identifier with the special value 
http://specs.openid.net/auth/2.0/identifier_select; is discovered, then the 
Claimed Identifier is actually an OP Identifier.

The spec is also confusing since “Claimed Identifier” and “openid.claimed_id” 
are not always the same. The spec says you always get a “Claimed Identifier” 
from the normalization phase [§7.2 point 4], but contradicts that two sections 
later [§7.3.1] saying sometimes there is no “Claimed Identifier” if it turns 
out to be an “OP Identifier”, but the openid.claimed_id field is still sent 
just with a another (predefined) value.

Q. Is there a good reason for sending 
http://specs.openid.net/auth/2.0/identifier_select; in two fields, instead of 
sending the OP Identifier in openid.claimed_id?
That is, why not always send the normalized User-Supplied identifier in 
openid.claimed_id, regardless of the OP-Local Identifier?

I suggest replacing §7.3.1. Discovered Information with the following:

The Relying Party starts the discovery process with a Claimed Identifier and, 
upon successful completion, will have one or more sets of the following 
information (see the Terminology section for definitions). If more than one set 
of the following information has been discovered, the precedence rules defined 
in [XRI_Resolution_2.0] are to be applied.

* OP Endpoint URL
* Protocol Version
* Claimed Identifier
* (optional) OP-Local Identifier

The Claimed Identifier may have changed during discovery if it was an XRI [see 
§7.3.2.3].

The Claimed Identifier will change during authentication if the OP-Local 
Identifier is present and has the special value 
http://specs.openid.net/auth/2.0/identifier_select;. In this case the Claimed 
Identifier in the authentication request is actually an OP Identifier. A 
different Claimed Identifier will be returned in the authentication response. 
Discovery will have to be performed again on the new Claimed Identifier once it 
is received [see §11.2].
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


HMAC-256 vs HMAC-SHA256 for openid.assoc_type

2007-10-30 Thread Manger, James H
Is the correct value for the openid.assoc_type parameter really “HMAC-256”, and 
not “HMAC-SHA256”? That is what the spec (draft 12) says, though it is somewhat 
counter-intuitive given the algorithm is named “HMAC-SHA256” and the other 
algorithm “HMAC-SHA1” uses the same string for the algorithm name and 
assoc_type value.

Googling for assoc_type=HMAC-SHA256 finds 5 results (from 3 code bases?).
Googling for assoc_type=HMAC-256 finds none.

http://openid.net/specs/openid-authentication-2_0-12.html#assoc_types
“8.3.2.  HMAC-SHA256
An association of type HMAC-256 uses the HMAC-SHA256 (Signature Algorithms) 
signature algorithm.”

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


RE: HMAC-256 vs HMAC-SHA256 for openid.assoc_type

2007-10-30 Thread Manger, James H
It was “HMAC-SHA256” in draft 9 (10 Sep 2007), but had changed to “HMAC-256” in 
draft 10 (13 Oct 2007). The change is looking more like a typo.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

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


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

2007-10-17 Thread 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

2007-10-17 Thread 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


[OpenID] identify RP when it gets OpenID URL

2007-10-16 Thread 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 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.

 

James Manger

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


RE: DRAFT 11 - FINAL? openid2

2007-01-31 Thread Manger, James H
Supporting point 2 (user with a v1 OP and a *separate* v2 OP) seems a bit 
unnecessary. A single OP can support v1 and v2 RPs at the same time. Point 2 is 
the sort of corner-case that can be supported by a yardis file, but needn’t be 
supported by the simple HTML discovery alternative. 
My vote would be to keep openid.server and openid.delegate (instead of 
openid2.provider and openid2.local_id) and add openid.version.

P.S. The spec should talk about link …/, instead of LINK …, elements. It 
does this in the §A.4 “HTML Identifier Markup” example, but not in §7.3.3 
“HTML-based discovery”.  Version 1.1 used link …; HTML is case-insensitive so 
link … is ok; XHTML is case-sensitive so LINK …/ is not acceptable.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
Sent: Wednesday, 31 January 2007 12:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: DRAFT 11 - FINAL?

On 1/30/07, Recordon, David [EMAIL PROTECTED] wrote:
 Yeah, I'm not a big fan of openid2.* though it was the simplest method
 of fixing up HTML discovery to work with multiple protocol versions.  I
 know Josh thought about this more than I did though.

1. Before authentication is initiated, the RP needs to determine what
the protocol is. This could be done via discovery on the OP, but there
has been general rejection of adding yet another discovery step.

2. A user may have one service that provides OpenID 1 and another that
provides OpenID 2. If this is the case, then the version information
needs to be bound to the link tag that contains the information.

Given (1), the information needs to be embedded in the HTML markup.
Given (2), the information needs to be tied to the specific link tag.

For example:

  link rel=openid.server href=http://op.example.com/openid1;
  link rel=openid2.provider href=http://op.example.com/openid2;

vs.
  link rel=openid.server href=http://op.example.com/openid1;
  link rel=openid.provider href=http://op.example.com/openid2;
  link rel=openid.protocol_version href=http://specs.openid.net/auth/2.0;

While it is true that since the link relationship names changed, the
openid2 is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version were to keep changing, I'd
argue for a different solution.

Josh
___
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] btwoc, base64 and the default DH modulus

2006-12-17 Thread Manger, James H
---
The default Diffie-Hellman modulus is shown in decimal in version 1.1 and in 
hex in version 2.0predraft11, but would appear in base64(btwoc(…)) in the 
protocol!
Change Appendix B Diffie-Hellman Key Exchange Default Value to use the 
base64(btwoc(p)) format, as used in the protocol (see §8.1.2 Diffie-Hellman 
Request Parameters). 

“Appendix B. Diffie-Hellman Key Exchange Default Value
This is the prime number p used as the default modulus for Diffie-Hellman Key 
Exchange, in base64(bwtoc(p)) format:
* openid.dh_modulus
  Value: ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91ouJ4mLBX+YkcLiemOc
Pym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/368Ygo79JRnxTkXj
gmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr
”
---
The table in §4.7 Integer Representations is misleading as it unnecessarily 
introduces \x00 notation and quotes.  Base64-encoding is always applied after 
btwoc so show this in the table.
Adjust the last sentence to avoid confusion between bytes and strings.
From: “If it is not, implementations MUST add a zero byte at the front of the 
string.”
To:   “If it is not, add a zero byte at the front.”
Add an extra sentence:
“The base64-encoding of the btwoc bytes is transmitted in the protocol.”
Replace the table with the following:
“Base 10 Number | btwoc bytes | base64(btwoc(…))
---+-+-
0  | 00  | AA==
127| 7F  | fw==
128| 00 80   | AIA=
255| 00 FF   | AP8=
32768  | 00 80 00| AIAA
”
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


[OpenID] inconsistent openid. prefix

2006-12-17 Thread Manger, James H
OpenID Authentication 2.0 predraft 11 uses the openid. prefix inconsistently. 
 For instance, §5.2.3 has dot-points for “openid.mode”, “openid.error”, 
“openid.contact”…, whereas §5.1.2.2 has dot-points for “error”, “contact”….
The data format example (§4.1.3) uses “mode” and “error” keys in the Key-Value 
Form encoding, but “openid.mode” and “openid.error” in the x-www-urlencoded 
example in the very next paragraph.  I assume it should be “openid.mode” and 
“openid.error” everywhere.
Text such as
  Value: associate
or
  Default: HMAC-SHA1
appears throughout the spec.  A assume the quotes do NOT appear in the 
protocol.  A sentence to this effect in §4.1 Protocol Messages would help, as 
would more comprehensive examples.
Add this sentence to §4.1:
“Specific values are shown in double quotes within this specification (eg 
Value: associate) but the quotes do not appear in the protocol messages (eg 
openid.mode=associate).”
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: [OpenID] Assertion Quality Extension = openid.importance

2006-12-12 Thread Manger, James H
The RP is not saying “this is very very important to *me*”.  It is saying “in 
my opinion, this is likely to be very very important to *you*”.  Consequently, 
it is not a contradiction for the RP to also say “I leave it to you as to the 
specifics”.

 Does participating in OpenID mean the RP giving up this policy control?
Yes, fully participating in OpenID means the RP gives up some policy control.  
An RP cannot simultaneously 1) accept its users choices of OPs, and 2) get 
trusted assertions as to the authentication quality.  The first implies 
accepting any OP.  The second implies accepting only the small subset of OPs 
trusted by the RP.

 How many such RPs will be willing to pay this price?
For most RPs there shouldn’t be a high price (if any price).  When the login 
only gives access to the user’s own resources (be they colour preferences, 
reputation, personal details, money…), then any inappropriately weak 
authentication of the user by their OP only affects that user.  The user pays a 
price, but not the RP.  This scenario covers a lot of services: Amazon (user’s 
book preferences, user’s payments); hotmail (user’s inbox); flickr (user’s 
photos)…
An RP may pay an indirect price.  The law may not accept that the user was in 
total control of the authentication mechanism so the user (not the RP) bears 
all responsibility.
A big scenario not covered is corporate access: the RP is a company, the user 
is an employee.  Login gives the user access to resources, but the RP still 
owns the resources.  Some control over the resources is delegated to the user, 
but not all.  Solutions: a) don’t use openid, b) trust your employees, c) use 
openid but only accept selected OPs.

 Fundamentally, I don't see how acknowledging that the RP may have certain 
 expectations of the authentication event is somehow in conflict with 
 user-centrism.
The hassle is that an RP expectation for, say, “hardotp” will prevent my 
spec-compliant OP software from logging me in even if I am using a 
triple-factor iris scan, 20-char password and smartcard to authenticate myself 
to my OP.
A related hassle is that when my OP supports a new authentication method (such 
as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs 
will not recognize this method as strong enough for the RP’s expectations – 
regardless of the method’s actual strength.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: [OpenID] Assertion Quality Extension = openid.importance

2006-12-11 Thread Manger, James H
What happened to all the concern about openid.auth_age (in early October)?

I echo Kevin Turner's worry that “features like this will mislead the RP 
developers into thinking they have more control over the authentication 
protocol than they really do… when OpenID actually leaves all those controls in 
the hands of the user and their chosen IdP”. 
[http://openid.net/pipermail/specs/2006-October/000223.html]

Dick Hardt’s Amazon.com use case makes sense: amazon.com may be quite happy to 
use an arbitrarily old authentication to personalise your browsing, but when 
you go to purchase something they want to make sure it is still you (and prompt 
you for your password).

The user-centric solution is not for the RP to specify a max auth age (or 
captcha or email verification or handbio or hardotp…), but for the RP to 
indicate the importance of the authentication. The user (with a little help 
from their OP) decides how to react (eg whether or not to login again) based on 
the importance/RP/auth-age/….

Spec changes: specify an openid.importance attribute to be included in an 
authentication request and echoed in the response; define some standard values 
(eg “low”, “medium”, “high”, “session”, “transaction”, “money”, “privacy”, 
“corporate”, “reputation”…); encourage OPs to allow users to control how  when 
to reauthenticate based on the importance and RP.

Surely the Assertion Quality Extension (AQE) will just encourage RP to only 
support a small number of OPs that the RP can trust to enforce the RP’s rules.

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