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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 07:36:41 UTC 2013


Yup. It is too late. The client needs to know whether the server is secure
or not to start with.

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

Could you kindly propose a concrete method? A concrete text would be even
better.


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

> 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
>>
>
>


-- 
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/3c80b352/attachment-0001.html>


More information about the Openid-specs-ab mailing list