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

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

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,

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

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

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.

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

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

[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

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

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

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

2007-10-17 Thread Manger, James H
: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

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

2007-10-17 Thread Manger, James H
, 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] 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

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

[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

[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

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

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