[Openid-specs-ab] token_endpoint_auth_method Registration example error?

Wed Jan 23 16:39:44 UTC 2013

+1 for keeping it single registration value.

Another option would be to consolidate client_secret_basic &
client_secret_post into a single value (client_secrete_something???) as
they are effectively equivalent in terms of preventing the OP from
accepting weaker methods from a particular client.

On Wed, Jan 23, 2013 at 9:33 AM, Justin Richer <jricher at mitre.org> wrote:

>  But now that the server responds with the current configuration, it's no
> longer just about client preference but also about the server expressing to
> the client what it should do. So if a client gets a client_secret, and the
> server is OK with it using basic, post, or jwt with that secret, how can
> the server tell the client this?
>
> The simplest thing is to keep it a single value as it is now, but that's
> (as always) a tradeoff between flexibility and complexity.
>
>  -- Justin
>
> On 01/23/2013 11:28 AM, John Bradley wrote:
>
> If you want a client to authenticate multiple ways just don't register a
> prefrence.
>
>  This was intended to prevent IdP from accepting weaker methods of
> authentication from attackers.   If you are not doing that then the client
> should be able to use anything the server supports.
>
>  Now if the client doesn't register a public key then some methods will
> fail, but that is a client decision.
>
>  I think trying to say I only want to use 2 of the 5 available methods is
> overkill.
>
>  The client should just pick the one it is going to use.
>
>  If it really needs two methods maybe it is really two clients and
> somebody is fudging things a bit.
>
>  John B.
>
>  On 2013-01-23, at 4:18 PM, Justin Richer <jricher at mitre.org> wrote:
>
>  Actually come to think of it, why wouldn't a client be able to do both
> client_secret_basic and client_secret_post to a server that supports them?
> It's the same info presented in *almost* the same way.
>
> This combination may be the exceptional case, though, as the other types
> (client_secret_jwt,private_key_jwt, or even "none" that OIDC hasn't adopted
> yet) aren't particularly mutually compatible.
>
>  -- Justin
>
>
> On 01/23/2013 10:53 AM, Justin Richer wrote:
>
> OK, thanks for catching that. I'll file a bug against Oauth2 Dynreg as
> well (which has the same examples). John is right that it is defined as a
> single value and the examples are off.
>
>  -- Justin
>
> On 01/23/2013 10:03 AM, Mike Jones wrote:
>
>  That’s what I thought.  Thanks for confirming.****
>
>
>
>                                                             -- Mike****
>
>
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com>]
> *Sent:* Wednesday, January 23, 2013 7:02 AM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] token_endpoint_auth_method Registration
> example error?****
>
> ** **
>
> The server may support multiple methods, but the client MUST only register
> one, so it shouldn't be multi value for simplicity.****
>
> ** **
>
> If you need two auth methods they should be different client_id.****
>
> ** **
>
> This is intended mostly to enhance security and prevent a server from
> taking client_secret_basic from an attacker when the real client is using
> private_key_jwt.****
>
> ** **
>
> John B.****
>
> ** **
>
> On 2013-01-23, at 9:07 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> ****
>
>
>
> ****
>
> Registration contains the following definition:****
>
>  ****
>
> token_endpoint_auth_method****
>
> OPTIONAL. Requested authentication method for the Token Endpoint. The
> options areclient_secret_post, client_secret_basic, client_secret_jwt, and
>  private_key_jwt, as described in Section 2.2.1 of [OpenID.Messages].
> Other Authentication methods may be defined by extension. If unspecified or
> omitted, the default is client_secret_basic HTTP Basic Authentication
> Scheme as specified in Section 2.3.1 of [RFC6749].****
>
>  ****
>
> It later uses “token_endpoint_auth_method” in two example result values in
> this manner:****
>
>  ****
>
> "token_endpoint_auth_method":****
>
>    "client_secret_basic client_secret_post",****
>
>  ****
>
> This looks like a bug to me, since the string appears to be trying to
> contain multiple values.****
>
>  ****
>
> Thus, I’m changing the string used to just "client_secret_basic" to make
> the example correct.  But I thought I’d point this out in case the example
> may have been intentional in some manner.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> _______________________________________________
> 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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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/20130123/d57417f0/attachment.html>