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

Brian Campbell bcampbell at pingidentity.com
Mon Jul 29 11:53:53 UTC 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/7f06a5e3/attachment.html>


More information about the Openid-specs-ab mailing list