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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 10:26:54 UTC 2013


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


More information about the Openid-specs-ab mailing list