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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 08:48:39 UTC 2013


Using dyn reg for this purpose defeats the basic requirement that the
server does not want to keep the per client state.
Out-of-band in which case the server uniformly applies a capability across
the clients is nicer.


2013/7/29 John Bradley <ve7jtb at ve7jtb.com>

> One place to put this is in dynamic registration then the configuration
> can be indicated on a per client basis.
>
> So indicating support in Discovery for connect,  in Dynamic registration
> where that is used and out of band in the other cases.
>
>
> On 2013-07-29, at 10:03 AM, Anthony Nadalin <tonynad at microsoft.com> wrote:
>
> I think this gets us in a bind with information exposure, as this all can
> be very app dependent and not authorization server general****
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:openid-
> specs-ab-bounces at lists.openid.net] *On Behalf Of *Torsten Lodderstedt
> *Sent:* Monday, July 29, 2013 12:58 AM
> *To:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Transient Client Secret Extension for
> OAuth****
> ** **
>
> Hi all,****
>
> I think OAuth authorization servers need a way to announce their
> capabilities (e.g. grant types, dyn client reg, revocation, support for
> tcse :-)) and respective endpoints. Using a config file at a well-known
> location****
>
> /.well-known/oauth-configuration****
>
> seems straightforward. For authorization servers, which are also OIDC OPs,
> the same (or a different) file might be exposed at****
>
> /.well-known/openid-configuration.****
>
> Thoughts?****
>
> regards,
> Torsten.****
>
> Am 29.07.2013 09:45, schrieb Nat Sakimura:****
>
> 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****
> ** **
>
> _______________________________________________****
>
> Openid-specs-ab mailing list****
>
> Openid-specs-ab at lists.openid.net****
>
> http://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
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/ad1e311f/attachment-0001.html>


More information about the Openid-specs-ab mailing list