[Openid-specs-ab] Transient Client Secret Extension for OAuth

Nat Sakimura sakimura at gmail.com
Mon Jul 29 07:28:27 UTC 2013


OK. Fair enough.

I will change it to the invalid_grant.

What do you think about the idea for "meta"?


2013/7/29 Brian Campbell <bcampbell at pingidentity.com>

> It's really not client authentication. It's something that links the
> initial authorization request with the corresponding access token request,
> which enables detecting a particular problem/attack. Similar to a mismatch
> on the redirect URI value between the authorization request and the
> corresponding access token request, it's the grant (or transaction) that is
> invalid.
>
> http://tools.ietf.org/html/rfc6749#section-5.2
>
>            invalid_grant
>                The provided authorization grant (e.g., authorization
>                code, resource owner credentials) or refresh token is
>                invalid, expired, revoked, does not match the redirection
>                URI used in the authorization request, or was issued to
>                another client.
>
> Discovery is maybe useful but is definitely not necessary. What is
> necessary is to define the parameter(s) and their treatment on the
> authorization request and access token request so that clients and servers
> can interop.
>
>
> On Mon, Jul 29, 2013 at 9:07 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> Hi Brian,
>>
>> inline:
>>
>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>
>>> IMHO, invalid_grant is the proper error response code, not
>>> invalid_client.
>>>
>>
>> I have thought a bit about that when I was writing it down.
>> invalid_grant is concerned about the token which has been previously
>> issued.
>> invalid_client is concerned about the client authentication.
>> In the initial path, I had it as invalid_grant, then, I thought - well,
>> it is the client
>> authentication that is failing when the client has provided invalid tcs.
>> The code is correct. It is the client authentication which is going
>> wrong, is it not?
>>
>>
>>>
>>> Along the same lines, I'd like to see it named something more like
>>> "message correlation id" rather than anything involving client secret.
>>>
>>
>> The name "message correlation identifier" does not convey the nature of
>> the parameter, which is the high entropy credential for the client. Just
>> for the sake of the correlation, it does not have to have a high entropy.
>> Thus, I have chosen the name.
>>
>>
>>>
>>> This is a general OAuth problem and I believe the solution should be
>>> general too. Thus, at least the base definition of the parameter(s) should
>>> not require discovery or rely on any of the Connect documents.
>>>
>>
>> OAuth generally does not need discovery. However, this spec really needs
>> it, at least in one form or another.
>> I have thought of making a new file but then that would amount to having
>> the client hit those discovery endpoints twice.
>> I did not want the duplicate situation that resulted in the dynamic
>> client registration. That's why I am referring OpenID Connect.
>> OpenID Connect originated the Discovery and Registration. On the hind
>> site, even registration should have been referring OpenID Connect documents
>> instead of duplicating. At least, that's how academic papers work :-)
>>
>> Another idea is to have the metadata come back in the token response.
>> I actually prefer this. It increases the server traffic a bit, though.
>>
>> The way it works is this.
>> Instead of doing the discovery and caching it at the client, the client
>> finds the server capability from the token endpoint reference. For this,
>> the server includes something like:
>>
>> "meta": {
>>    "tcs_supported":true;
>> }
>>
>> You guys know that I like this idea because then I would have a stub to
>> put link relationship there as well.
>> Do you like the idea? If so, I can update the draft in this manner.
>> Well, perhaps I should anyways.
>>
>> Thanks for pointing out.
>>
>> Best,
>>
>> Nat
>>
>>
>>
>>
>>>
>>>
>>> On Sun, Jul 28, 2013 at 9:39 PM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>
>>>> As some of you knows, passing the code securely to a native app on iOS
>>>> platform is next to impossible. Malicious application may register the same
>>>> custom scheme as the victim application and hope to obtain the code, whose
>>>> success rate is rather high.
>>>>
>>>> We have discussed about it during the OpenID Conenct Meeting at IETF 87
>>>> today, and I have captured the discussion in the form of I-D. It is pretty
>>>> short and hopefully easy to read.
>>>>
>>>> You can find it at:
>>>>
>>>> https://bitbucket.org/Nat/drafts/src/
>>>>
>>>> Comments are welcome.
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/96abefc1/attachment-0001.html>


More information about the Openid-specs-ab mailing list