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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 12:27:39 UTC 2013


Good catch.

I am also thinking of change the name for client secret hash to request
token, and parameter name from 'tcsh' to 'rt'.
Also, I am thinking of reverting salted hash to just a hash per the
discussion with Dirk.

What do you think?


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

> In general, those changes look good to me. Though 2nd paragraph of section
> 1 still says "this extension utilizes OpenID Server Configuration Document"
> which should probably be removed now.
>
> I am also unsure about needing to salt the hash.
>
>
>
>
>
>
> On Mon, Jul 29, 2013 at 12:26 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> Updated the draft.
>>
>> Changes:
>>
>> * Removed the discovery, and made the method to find out the server
>> capability out-of-scope.
>> * Salted the hash. <<< Still not sure but for the time being.
>> * Fixed the working group and area
>>
>>
>>
>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>
>>> I'm just trying to be realistic.
>>>
>>> The client can send the values regardless of if the sever supports this
>>> or not.
>>>
>>> If a client really cares enough and will not use the AS if this isn't
>>> supported, it can find out out of band. Or it's easy enough to test it out.
>>>
>>> Most clients are written to a particular AS so they'll know already.
>>> Libraries are more general and they need to support it first.
>>>
>>> Connect (and eventually general OAuth) can put this in dico. But the
>>> basic functionality doesn't need to address that.
>>>
>>>
>>> On Mon, Jul 29, 2013 at 9:45 AM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>
>>>> Hmmm. Then, the client has lost its capability to find out whether the
>>>> server is secure or not dynamically.
>>>> Do you mean that the client should find it out out-of-band?
>>>> That's possible, and is more OAuthy.
>>>>
>>>> So, instead of current 3.2, it can just state :
>>>>
>>>> The client MUST find out if the server supports this mode before
>>>> issuing the authorizaiton request. The exact method of how it can be done
>>>> is out of scope.
>>>>
>>>> Is that what you mean?
>>>>
>>>> Nat
>>>>
>>>>
>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>
>>>>> Pretty much just removing 3.1 and 3.2 and 2.2 from your draft.
>>>>>
>>>>>
>>>>> On Mon, Jul 29, 2013 at 9:36 AM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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/817ea850/attachment-0001.html>


More information about the Openid-specs-ab mailing list