[Openid-specs-ab] token_endpoint_auth_method Registration example error?
Justin Richer
jricher at mitre.org
Wed Jan 23 18:11:40 UTC 2013
That's not an unreasonable interpretation. I think we should consider
collapsing the client_secret_post and client_secret_basic at a future
point, then.
-- Justin
On 01/23/2013 12:45 PM, Mike Jones wrote:
>
> I'd say no. The client has already made its choice. Giving it
> options it didn't ask for after that would likely only create interop
> problems in many cases.
>
> -- Mike
>
> *From:*Justin Richer [mailto:jricher at mitre.org]
> *Sent:* Wednesday, January 23, 2013 9:43 AM
> *To:* Mike Jones
> *Cc:* John Bradley; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] token_endpoint_auth_method
> Registration example error?
>
> All of that I agree with. Question remains if the server, in its
> response to the client, wants to tell the client it has several of the
> X options found in discovery.
>
> -- Justin
>
> On 01/23/2013 12:36 PM, Mike Jones wrote:
>
> I agree they're complimentary.
>
> Discovery tells the client what the server can do. It uses that
> information to pick the option to use that will work for both of
> them, then registers with that option.
>
> -- Mike
>
> ------------------------------------------------------------------------
>
> *From: *Justin Richer
> *Sent: *1/23/2013 9:28 AM
> *To: *Mike Jones
> *Cc: *John Bradley; 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?
>
> 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
> <mailto: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/48919bce/attachment.html>
More information about the Openid-specs-ab
mailing list