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

[Justin Richer]

Not all clients can necessarily use all forms of auth that a server 
supports, so I see the two values as complimentary.

  -- Justin

On 01/23/2013 12:14 PM, Mike Jones wrote:
>
> The server expresses what the client should do in the discovery phase 
> – not during registration.  See the 
> “token_endpoint_auth_methods_supported” discovery result parameter in 
> http://openid.net/specs/openid-connect-discovery-1_0-12.html.
>
> -- Mike
>
> *From:*John Bradley [mailto:ve7jtb at ve7jtb.com]
> *Sent:* Wednesday, January 23, 2013 9:02 AM
> *To:* Justin Richer
> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] token_endpoint_auth_method 
> Registration example error?
>
> Like discovery the response could be multi value.  However the client 
> souls only register one value if it wants to restrict what the server 
> accepts for that client_id.
>
> Sent from my iPhone
>
>
> On 2013-01-23, at 4:33 PM, Justin Richer <jricher at mitre.org 
> <mailto: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
>         <mailto: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]
>                 *Sent:* Wednesday, January 23, 2013 7:02 AM
>                 *To:* Mike Jones
>                 *Cc:* openid-specs-ab at lists.openid.net
>                 <mailto: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
>                 <mailto: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,
>                 andprivate_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 isclient_secret_basicHTTP 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130123/676c1e10/attachment.html>