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

Brian Campbell bcampbell at pingidentity.com
Mon Jul 29 12:39:35 UTC 2013


I'm sure we can do a lot of bikeshedding on the parameter names but I agree
with Torsten that "request token" will likely cause a lot of confusion.

I don't see the value of the salt here so I'm okay reverting that part. But
I'll freely admit that I may not understand it fully.


On Mon, Jul 29, 2013 at 2:31 PM, Torsten Lodderstedt <
torsten at lodderstedt.net> wrote:

> **
>
> don't use "request token", please! I expect this to totally confuse
> people. Probably request secret or similar.
>
> Am 29.07.2013 14:27, schrieb Nat Sakimura:
>
> 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
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/0b6ade97/attachment-0001.html>


More information about the Openid-specs-ab mailing list