> here is a non-security reason [for openid.oauth.consumer in the response]:
> Imagine the Consumer controlling more than
> one consumer key, and also imagine that the consumer is implemented as a
> server farms of thousands of machines. The machine receiving the response
> is not necessarily the
The latest OpenID/OAuth hybrid draft REQUIRES the openid.oauth.consumer
parameter, which means an app must be pre-registered with a service before
it can use the protocol.
Requiring per-service pre-registration is not suitable for a web-scale
authentication & delegation solution. [Web sites don't r
>> Learning just that an OP supports the hybrid protocol
>> (without any indication of the associated protected resources)
>> seems to be of minimal value.
> Yes. However, when OAuth discovery happens (and the standardization
> effort is under way) it will much more than minimal value.
> Standardi
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
Section 5 Discovery of the OpenID/OAuth hybrid draft spec says
http://specs.openid.net/extensions/oauth/1.0
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
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 u
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,
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 intera
Anders,
> This looks like an interesting proposal…
> What remains to be done to elevate this proposal this to standard?
Some time and effort by someone to:
* Start writing it up as a fully-specified protocol (perhaps starting with some
use cases so people can agree to the need and scope);
* Cr
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/
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
(
Errata for OpenID Authentication 2.0 - Final
http://openid.net/specs/openid-authentication-2_0.html
The values that RPs SHOULD accept
for backward compatibility with 1.0 & 1.0 are confusing.
The 2.0 spec sometimes talks about …signon/1… URLs:
"http://openid.net/signon/1.0"; and
"http://openid.net
Section 14.2.1 "Relying Parties" (discussing compatibility with OpenID 1.1)
says:
"the end user's OP-Local Identifier appears in the 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
The RP could put its own nonce in the openid.return_to URI. The signature from
the OP covers this field.
I don’t think different return_to URIs for each request can have any negative
consequences -- as long as an unchanging openid.realm is also included in the
authentication requests.
-Orig
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 “op
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
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
r 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
Sen
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
TECTED] 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
care
: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 incl
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:
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 wo
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
---
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
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 givin
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
27 matches
Mail list logo
