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

Dirk Balfanz balfanz at google.com
Mon Nov 24 18:27:04 UTC 2008


I'm not sure. While I've seen OAuth interop really being hampered by that
extension not being implemented in many libraries, and I generally think
it's a good thing to report errors as detailed as possible, this does seem a
very Un-OpenID-thing to do. They specify only two error conditions: "the
user didn't want to log in" and "we can't log in the user without showing
them a UI" (and this includes the AX extension). Of course, a lot more can
go wrong, and there doesn't seem to be a notion in OpenID that this would be
communicated, through a browser redirect, to the consumer. Perhaps the
unspoken rule is that the redirect just doesn't happen when something goes
wrong? In that case, the OP would just show a descriptive error page to the
user? I don't know...

Dirk.

On Fri, Nov 21, 2008 at 4:04 PM, Allen Tom <atom at yahoo-inc.com> wrote:

>  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> 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/20081124/629ed7cf/attachment-0002.htm>


More information about the specs mailing list