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

Brian Campbell bcampbell at pingidentity.com
Mon Jul 29 07:32:06 UTC 2013


As John pointed out, putting metainfo about support into the token response
is too late in the flow.

I still think that a base definition of this shouldn't try and address
discovering or publishing support for the functionality.


On Mon, Jul 29, 2013 at 9:28 AM, Nat Sakimura <sakimura at gmail.com> wrote:

> 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/5bba4524/attachment-0001.html>


More information about the Openid-specs-ab mailing list