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
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
---
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 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
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
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
: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
, 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
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
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
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
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
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.
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
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,
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
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
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
18 matches
Mail list logo
