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

[Allen Tom]

A couple minor edits are needed to Section 12: Security Considerations.

I assume that the response_token in Section 12 is the same as the 
request_token in Section 9. The terminology needs to be consistent.

"Is" shoudl be changed to "are" in the phrase "The following security 
principles is reflected in this design"

Otherwise, the spec is looking pretty good!

Allen

Dirk Balfanz wrote:
>
> Ok, new version is up. I took out the sentence that recommended to 
> send a cancel. I also added a section on discovery (just copied 
> whatever the AX extension says about that).
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Allen Tom]

How about if the openid.oauth.scope response parameter defined in 
Section 9 be changed to be a more generic OAuth status indicator? It can 
be used to indicate which scopes were authorized in the success case, or 
it can be used as status/problem indicator if there was an error.


Perhaps the allowed values can be the same as the values defined in the 
ProblemReporting extension.

http://oauth.pbwiki.com/ProblemReporting

Allen




Dirk Balfanz wrote:



On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom <[EMAIL PROTECTED] 
> wrote:


Since the new hybrid draft spec doesn't affect the OpenID
association method, this is moot.

However, the spec should mention what SPs should do if the CK is
invalid (or doesn't match the realm) in the OpenID authentication
request. Presumably, the SP should continue servicing the OpenID
portion of the request, however, the response should indicate why
the OAuth portion of the request failed.


How about, to mimic what happens with association handles, we can 
return in the response an openid.oauth.invalid_consumer parameter 
instead of openid.oauth.consumer? It would mean that either the CK was 
just wrong or that it didn't match the realm. Although at this point 
it starts to get pretty complicated. 

Does this error condition really need to be communicated back to the 
RP? For development etc., it might be enough to just show an error 
page to the user explaining what happened. 


Dirk.

 



Allen



Dirk Balfanz wrote:



I'd recommend an error consistent with Section 8.2.4 in the
OpenID 2.0 spec, with a new error_code value indicating that
the either the CK or the realm was invalid. There may
actually need to be 2 errors, one to indicate that the CK is
invalid, and another to indicate that the CK is not valid for
the realm.

http://openid.net/specs/openid-authentication-2_0.html#anchor20


But Section 8.2 is about the association response. In the auth
response, we currently only have cancel or setup_needed. If we
invent another error condition there, we're no longer a pure
"extension". 
 





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

Invitation to join the Metadata Discovery Coordination Group

[Eran Hammer-Lahav]

Discussions about URI metadata discovery have been going on in many places
for the past couple of years. This has been reaching its boiling point with
the recent discussions between the W3C TAG, XRI TC, POWDER WG, the OpenID /
Yadis, OAuth, Portable Contacts, XRDS-Simple, and OpenSocial communities,
and various IETF I-Ds published on related topics.

Web Discovery is likely to consist of two parts, the *retrieval* and
*format* of a metadata document linked to a resource identified by a URI.
There are multiple proposals for the metadata document format, with XRDS and
POWDER as two notable examples. Discussions regarding metadata format should
and will remain where they are currently being held.

However, there is great recognizable value in a single (simple) mechanism
for *retrieval* of metadata for resources identified with a URI. From the
most basic use case of identifying which API is supported by a given
endpoint, to a more complex trusted identity resolution, the requirements
seems to be significantly overlapping.

For many of these communities, time is running out and most are getting
ready to put the final touches and ship specifications that already have
running code. We have a rare (but narrow) opportunity to quickly go through
the current proposals and at least set the tone for current and future
discovery solutions.

I am not ignoring the political complications of trying to reach consensus
among so many entities and communities but I truly believe from the many
hours of conversations I had the past 2 months that we are mostly all on the
same page. All I think we now need is a room, and hence this new list:
[EMAIL PROTECTED]

This is not a working group, nor does this group have any deliverables or
will produce specifications. It is designed as a coordination venue for the
various efforts going on to discuss their proposals and progress. It is also
for soliciting feedback and confirming assumptions about discovery
proposals.

Given the complexities behind IPR policies and the significant differences,
this list does not have an IPR policy. This means that discussions held here
are not covered, and if produce anything other than normative references to
existing standards (which is clearly the intention), will need to be
resolved if adopted elsewhere.

Web discovery has been my top priority for the past year and I am excited to
finally reach the point where a critical mass is formed to finally address
it. Please join the discussion at
http://groups.google.com/group/metadata-discovery.

EHL

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