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 <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> 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". 
>>      
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081121/263c002b/attachment-0001.htm>