Section 5 Discovery of the OpenID/OAuth hybrid draft spec says
should appear in the XRDS discovery document to indicate support for the
This doesn't seem to be the right way around.
Discovery is performed on a user's
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
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,
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
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
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
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
Section 14.2.1 Relying Parties (discussing compatibility with OpenID 1.1)
the end user's OP-Local Identifier appears in the openid:Delegate tag
However, the namespace URI associated with the openid namespace prefix is
I guess it should be http://openid.net/xmlns/1.0;, which
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
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
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
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
To: Manger, James H
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
, 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
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
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.
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
Change Appendix B Diffie-Hellman Key Exchange Default Value to use the
base64(btwoc(p)) format, as used in the protocol (see
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 §220.127.116.11 has dot-points for “error”, “contact”….
The data format example (§4.1.3) uses “mode” and “error” keys in the
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
Does participating in OpenID mean the RP
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
Mail list logo