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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Jul 29 12:31:40 UTC 2013


 

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 [4]
>>>>>>>>>>

>>>>>>>>>> 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. 
>>>>>>>>>>> 
>>>>>>>>>>>> f 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 <
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Nat
Sakimura (=nat) 
>>>>>>>>> Chairman, OpenID Foundation
>>>>>>>>>
http://nat.sakimura.org/ [2]
>>>>>>>>> @_nat_en
>>>>>>> 
>>>>>>> --

>>>>>>> Nat Sakimura (=nat) 
>>>>>>> Chairman, OpenID
Foundation
>>>>>>> http://nat.sakimura.org/ [2]
>>>>>>> @_nat_en
>>>>>

>>>>> -- 
>>>>> Nat Sakimura (=nat) 
>>>>> Chairman, OpenID
Foundation
>>>>> http://nat.sakimura.org/ [2]
>>>>> @_nat_en
>>> 
>>> --

>>> Nat Sakimura (=nat) 
>>> Chairman, OpenID Foundation
>>>
http://nat.sakimura.org/ [2]
>>> @_nat_en
> 
> -- 
> Nat Sakimura (=nat)

> Chairman, OpenID Foundation
> http://nat.sakimura.org/ [2]
> @_nat_en

> 
> _______________________________________________
> Openid-specs-ab
mailing list
> Openid-specs-ab at lists.openid.net
>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]




Links:
------
[1] https://bitbucket.org/Nat/drafts/src/
[2]
http://nat.sakimura.org/
[3]
http://lists.openid.net/mailman/listinfo/openid-specs-ab
[4]
http://tools.ietf.org/html/rfc6749#section-5.2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/20779b5c/attachment.html>


More information about the Openid-specs-ab mailing list