Subject: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Apr 2013 13:17:18 -0700

For parameters to token_endpoint_auth_method, the spec has defined "client_secret_jwt" and "private_key_jwt". Shouldn't there be similar options of SAML?

Shouldn't there be an extension point for other methods?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Apr 2013 17:57:10 -0300

Yes there should be corresponding client_secret_SAML and private_key_SAML.  Those parameters were taken from Connect which is more JWT focused so I didn't put in the SAML options for token endpoint authentication, though they would be valid.

There is probably some profiling that needs to be done for the client_secret_SAML to define how the client secret is used to hmac the SAML assertion.   You might want to just skip that and only do private_key_SAML which is more strait-forward with a asymmetric signature.

John B.

On 2013-04-24, at 5:17 PM, Phil Hunt <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Apr 2013 17:07:23 -0400

Seems reasonable to me, can you suggest language to add in the 
capability? Would it require an IANA registry? Right now there isn't any 
other place that enumerates the various methods that a client can use to 
access the token endpoint.

  -- Justin

On 04/24/2013 04:17 PM, Phil Hunt wrote:
> For parameters to token_endpoint_auth_method, the spec has defined 
> "client_secret_jwt" and "private_key_jwt". Shouldn't there be similar 
> options of SAML?
>
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Apr 2013 15:30:26 -0700

Hmmm… what was the objective or use case for having the client being able to choose in the first place?

It seems to me that the AS will make a decision based on many factors. As you say, there isn't any other place that enumerates the various [authn] methods a client can use to access the token endpoint.  So, why do it?

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-04-24, at 2:07 PM, Justin Richer wrote:

> Seems reasonable to me, can you suggest language to add in the capability? Would it require an IANA registry? Right now there isn't any other place that enumerates the various methods that a client can use to access the token endpoint.
> 
>  -- Justin
>

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Apr 2013 19:41:26 -0300

In Connect the AS may support a number of token endpoint authentication methods.   The reason to allow a client to register using a particular one is to prevent downgrade attacks.

If the client wants to always use an asymmetric signature you don't want to allow attackers to use weaker methods like http basic.

So a server may support any number of methods, but it is reasonable for a client to specify which one it is going to use.   In a closed system that may not be that useful but in a open system where the AS has a looser relationship to the client it is important.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Apr 2013 15:55:13 -0700

Right and if the client wants a method not supported then what?

Why can't the client offer up a list of methods it is able to support, say in order of preference?

The text appears to indicate only one value may be passed.

Given the way it is written. It seems better to just have the server say the client must do authn method X in the response.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Apr 2013 23:17:26 +0000

What you're missing is the part of the OpenID Connect flow where the client first discovers the capabilities that the Server advertises.  In this case, it uses this discovery parameter:

token_endpoint_auth_signing_alg_values_supported
OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the private_key_jwt and client_secret_jwt methods to encode the JWT. Servers SHOULD support RS256.

So in this use case, the client already knows what algorithms it can choose from, and it makes the choice.

Other OAuth flows could do the same thing, given either dynamic discovery or a published algorithm list by the server.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, April 24, 2013 3:55 PM
To: John Bradley
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

John B.

On 2013-04-24, at 7:30 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Hmmm... what was the objective or use case for having the client being able to choose in the first place?

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Apr 2013 20:23:04 -0300

In Connect there is a AS discovery before registration.   

The general pattern is the RP discovers the capabilities of the AS authentication methods and algorithms supported by the AS.  
The client then picks the best options for it and registers them.

It would in theory work of the client knowing nothing about the AS pushed it's capabilities at the AS as you are suggesting and let the AS pick.

My general feeling is that discovery with the client picking the options works best.

In many cases the client doesn't need to register parameters as they can be selected at run time once it knows what a server supports.  
The token endpoint authentication method was a bit of a special case where even though it could be all dynamic and work, you do want to register a choice to prevent backwards compatibility attacks.

I don't really want to complicate registration by trying to make it also cover AS discovery.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Apr 2013 16:28:12 -0700

Fair enough, but that doesn't make sense in this broader forum where discovery isn't assumed.   

Phil

On 2013-04-24, at 16:17, Mike Jones <[email-masked]> wrote:

> What you’re missing is the part of the OpenID Connect flow where the client first discovers the capabilities that the Server advertises.  In this case, it uses this discovery parameter:
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 25 Apr 2013 10:12:41 +0100

> Fair enough, but that doesn't make sense in this broader forum where
I guess it is true, I wonder, even with the discovery, would real world 
clients be able to choose from a list of the supported methods 
dynamically ? They are probably pre-configured to work with a specific 
method.

Sergey

> Phil
>
> On 2013-04-24, at 16:17, Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> What you’re missing is the part of the OpenID Connect flow where the
>> client first discovers the capabilities that the Server advertises. In
>> this case, it uses this discovery parameter:
>>
>> OPTIONAL. JSON array containing a list of the JWS signing algorithms
>> (algvalues) supported by the Token Endpoint for the private_key_jwtand
>> client_secret_jwtmethods to encode the JWT. Servers SHOULD support RS256.
>>
>> Other OAuth flows could do the same thing, given either dynamic
>> discovery or a published algorithm list by the server.
>>
>> -- Mike
>>
>> *From:[email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked]] *On Behalf Of *Phil Hunt
>> *Sent:* Wednesday, April 24, 2013 3:55 PM
>> *To:* John Bradley
>> *Cc:* [email-masked] <mailto:[email-masked]> WG
>> *Subject:* Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
>> token_endpoint_auth_method
>>
>> Given the way it is written. It seems better to just have the server
>> say the client must do authn method X in the response.
>>
>> Phil
>>
>> @independentid
>>
>> In Connect the AS may support a number of token endpoint
>> authentication methods. The reason to allow a client to register using
>> a particular one is to prevent downgrade attacks.
>>
>> If the client wants to always use an asymmetric signature you don't
>> want to allow attackers to use weaker methods like http basic.
>>
>> So a server may support any number of methods, but it is reasonable
>> for a client to specify which one it is going to use. In a closed
>> system that may not be that useful but in a open system where the AS
>> has a looser relationship to the client it is important.
>>
>> John B.
>>
>> It seems to me that the AS will make a decision based on many factors.
>> As you say, there isn't any other place that enumerates the various
>> [authn] methods a client can use to access the token endpoint. So, why
>> do it?
>>
>> Phil
>>
>> @independentid
>>
>> www.independentid.com <http://www.independentid.com/>
>>
>> capability? Would it require an IANA registry? Right now there isn't
>> any other place that enumerates the various methods that a client can
>> use to access the token endpoint.
>>
>> -- Justin
>>
>>     "client_secret_jwt" and "private_key_jwt". Shouldn't there be
>>     similar options of SAML?
>>
>>     www.independentid.com <http://www.independentid.com/>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 08:57:07 -0300

I think discovery is required.  One of the things that needs to be discovered is the dynamic registration endpoint.

We can try and back pseudo discovery into Dynamic registration, however just doing discovery as a separate step will be easier.

If you start wanting to overload registration there are lots of things in discovery like endpoints and key information from the AS that are not currently included in dynamic registration.   You picked only one thing out of a long list of things that would need to change if you wanted to include discovery functionality in dynamic registration.

I think Discovery can be done a number of ways but probably deserves its own spec as we did with Connect.

John B.

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Apr 2013 09:29:57 -0400

The thing to remember is that all of these parameters are bi directional 
since the configuration is echoed back to the client. On the one hand 
(C->S), it's the client stating its preference. On the other direction 
(S->C) it's the server specifying the client's configuration. So the 
server *does* say that the client must do authn method X in its 
response, using the same parameter. And if the client wants a method 
that doesn't get supported, then it doesn't get to use it. But at least 
it has a chance to know about that by looking at the server's response. 
Same goes with scopes, grant types, and others.

It is a singular value. At one point I had had it in there as an array 
(space separated list of strings, I think), but the Connect working 
group didn't want to make it plural at the time.

  -- Justin

On 04/24/2013 06:55 PM, Phil Hunt wrote:
>> authentication methods.   The reason to allow a client to register 
>> using a particular one is to prevent downgrade attacks.
>>
>>> It seems to me that the AS will make a decision based on many 
>>> factors. As you say, there isn't any other place that enumerates the 
>>> various [authn] methods a client can use to access the token 
>>> endpoint.  So, why do it?
>>>
>>> Phil
>>>
>>> @independentid
>>>> capability? Would it require an IANA registry? Right now there 
>>>> isn't any other place that enumerates the various methods that a 
>>>> client can use to access the token endpoint.
>>>>
>>>>  -- Justin
>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Apr 2013 09:41:43 -0400

John, I don't think that anybody's actually suggesting that we add 
server discovery in here. :) But since the server does echo back the 
configuration in its response, the client is discovering a few things at 
run time about what it can and can't do with a particular server. It's 
entirely possible that the client might get back a configuration option 
that it can't use (say, it can't do client_secret_jwt assertions but it 
can do

 From what I can see from this thread though there are two open 
questions that Phil's raised:

  1: Extensibility of token_endpoint_auth_method values, and where 
potential values are listed (IANA? fully qualified URIs for things not 
in the base spec?)

  2: Plurality of token_endpoint_auth_method (could be left as a string, 
made an array, or be a JSON-style optional plural: string value if 
singular or array if plural)

I think the first one should be addressed, but we just need to pick the 
method. I'm personally in favor of the same method we used for 
grant_type, which is short values in the spec and extensions as fully 
qualified URIs. The second one could break existing implementations (and 
other dependent specs), so if we change it, it has to be for very good 
reason.

  -- Justin

On 04/24/2013 07:23 PM, John Bradley wrote:
> The general pattern is the RP discovers the capabilities of the AS 
> authentication methods and algorithms supported by the AS.
> It would in theory work of the client knowing nothing about the AS 
> pushed it's capabilities at the AS as you are suggesting and let the 
> AS pick.
>
> In many cases the client doesn't need to register parameters as they 
> can be selected at run time once it knows what a server supports.
> The token endpoint authentication method was a bit of a special case 
> where even though it could be all dynamic and work, you do want to 
> register a choice to prevent backwards compatibility attacks.
>
> On 2013-04-24, at 7:55 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>>> factors. As you say, there isn't any other place that enumerates 
>>>> the various [authn] methods a client can use to access the token 
>>>> endpoint.  So, why do it?
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>>>> For parameters to token_endpoint_auth_method, the spec has 
>>>>>> defined "client_secret_jwt" and "private_key_jwt". Shouldn't 
>>>>>> there be similar options of SAML?
>>>>>>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 11:21:12 -0300

I am OK with having a registry,  Connect profiles the jwt assertions draft to add specifics around keying material for interoperability.  
It may well be that people will want other methods including SAML assertions.

While sending a list of methods the client supports to the server and getting back what is supported by the server works, it is awkward.

My point is mostly that there are lots of other parameters that are set only by the server.  I don't know if we want to start adding them to registration just to allow for them to be discovered.   Using a simple .well-known discovery document seems simpler.

So making token_endpoint_auth_method an array is not the end of the world and would work, but heads us in what I think is the wrong direction.

John B.

On 2013-04-25, at 10:41 AM, Justin Richer <[email-masked]> wrote:

> John, I don't think that anybody's actually suggesting that we add server discovery in here. :) But since the server does echo back the configuration in its response, the client is discovering a few things at run time about what it can and can't do with a particular server. It's entirely possible that the client might get back a configuration option that it can't use (say, it can't do client_secret_jwt assertions but it can do 
> 
> From what I can see from this thread though there are two open questions that Phil's raised:
> 
> 
>  1: Extensibility of token_endpoint_auth_method values, and where potential values are listed (IANA? fully qualified URIs for things not in the base spec?)
> 
>  2: Plurality of token_endpoint_auth_method (could be left as a string, made an array, or be a JSON-style optional plural: string value if singular or array if plural)
> 
> 
> 
> I think the first one should be addressed, but we just need to pick the method. I'm personally in favor of the same method we used for grant_type, which is short values in the spec and extensions as fully qualified URIs. The second one could break existing implementations (and other dependent specs), so if we change it, it has to be for very good reason.
> 
>  -- Justin
> 
>>>>>>> For parameters to token_endpoint_auth_method,
>>>>>>>                                           the spec has defined "client_secret_jwt" and "private_key_jwt". Shouldn't there be similar options of SAML?
>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 25 Apr 2013 09:23:10 -0700

I am not sure what to think about this. 

1. I don't want this spec to be incomplete because there is another external spec published for a specific purpose. 

2. In general i would like to avoid negotiations. It seems to me that any developer making a client for a mutli-site deployed service would already be aware of what the generic service require and implement based on that oob knowledge. Thus when the server merely informs, the client should be prepared. 

IMHO, though i understand the motivation, negotiation of client auth creates more problems then it seems to solve in this case. Downgrade attack is just one of the problems. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Apr 2013 12:35:13 -0400

On 04/25/2013 12:23 PM, Phil Hunt wrote:
> 1. I don't want this spec to be incomplete because there is another 
> external spec published for a specific purpose.
If we needed a registry we could define it in this spec. If we chose a 
non-registry method (like how grant_type uses URIs) then it's 
self-contained. I prefer the latter, myself.

> 2. In general i would like to avoid negotiations. It seems to me that 
> any developer making a client for a mutli-site deployed service would 
> already be aware of what the generic service require and implement 
> based on that oob knowledge. Thus when the server merely informs, the 
> client should be prepared.
The client already has to be prepared because the server will inform, 
though. But by making it bidirectional (like all the other parameters) 
it gives the client a chance to ask based on whatever information it 
wants to. The server is perfectly free to ignore what the client asks 
for and just hand it something, just as it's free to do so for all fields.

> IMHO, though i understand the motivation, negotiation of client auth 
> creates more problems then it seems to solve in this case. Downgrade 
> attack is just one of the problems.
The parameters of the negotiation are going to be application-protocol 
specific and depend on things like a Discovery layer for them to be 
fully dynamic from a cold boot. And even then servers and clients that 
care about this value are going to have to know how to enforce it (it's 
the same as it is with grant_type, response_type, scope, and others).

If nothing else, it lets servers tell clients which auth method to use 
at the token endpoint. The client can be smart and try to figure out if 
it actually supports that method before trying it, or it can be dumb and 
ignore the returned value. But with this parameter in the protocol, both 
sides at least have a *chance* of doing the right thing.

  -- Justin

>
> Phil
>
> On 2013-04-25, at 7:21, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I am OK with having a registry,  Connect profiles the jwt assertions 
>> draft to add specifics around keying material for interoperability.
>> While sending a list of methods the client supports to the server and 
>> getting back what is supported by the server works, it is awkward.
>>
>> My point is mostly that there are lots of other parameters that are 
>> set only by the server.  I don't know if we want to start adding them 
>> to registration just to allow for them to be discovered.   Using a 
>> simple .well-known discovery document seems simpler.
>>
>> So making token_endpoint_auth_method an array is not the end of the 
>> world and would work, but heads us in what I think is the wrong 
>> direction.
>>
>> John B.
>>
>> On 2013-04-25, at 10:41 AM, Justin Richer <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> configuration in its response, the client is discovering a few 
>>> things at run time about what it can and can't do with a particular 
>>> server. It's entirely possible that the client might get back a 
>>> configuration option that it can't use (say, it can't do 
>>> client_secret_jwt assertions but it can do
>>>
>>> potential values are listed (IANA? fully qualified URIs for things 
>>> not in the base spec?)
>>>
>>>  2: Plurality of token_endpoint_auth_method (could be left as a 
>>> string, made an array, or be a JSON-style optional plural: string 
>>> value if singular or array if plural)
>>>
>>>
>>>
>>> I think the first one should be addressed, but we just need to pick 
>>> the method. I'm personally in favor of the same method we used for 
>>> grant_type, which is short values in the spec and extensions as 
>>> fully qualified URIs. The second one could break existing 
>>> implementations (and other dependent specs), so if we change it, it 
>>> has to be for very good reason.
>>>
>>>  -- Justin
>>>
>>>> pushed it's capabilities at the AS as you are suggesting and let 
>>>> the AS pick.
>>>>
>>>> In many cases the client doesn't need to register parameters as 
>>>> they can be selected at run time once it knows what a server supports.
>>>> The token endpoint authentication method was a bit of a special 
>>>> case where even though it could be all dynamic and work, you do 
>>>> want to register a choice to prevent backwards compatibility attacks.
>>>>
>>>>> Given the way it is written. It seems better to just have the 
>>>>> server say the client must do authn method X in the response.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>>> If the client wants to always use an asymmetric signature you 
>>>>>> don't want to allow attackers to use weaker methods like http basic.
>>>>>>
>>>>>> So a server may support any number of methods, but it is 
>>>>>> reasonable for a client to specify which one it is going to use. 
>>>>>>   In a closed system that may not be that useful but in a open 
>>>>>> system where the AS has a looser relationship to the client it is 
>>>>>> important.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>>>> isn't any other place that enumerates the various methods that 
>>>>>>>> a client can use to access the token endpoint.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 25 Apr 2013 10:09:51 -0700

If the server is free to ignore, doesn't that mean the client ends up having to implement *ALL* methods anyway? In the case of Connect, the client has to implement all methods supported by Connect because it *could* be forced by any particular deployer to use a particular method.

The dynamic draft + unspecified discovery doesn't (as described) doesn't make clients or servers actually easier to implement.  Any client not implementing all methods runs the risk of sooner or later not being compatible.

I agree there is a need for registration to convey to the client what authentication method and client credential it has been issued.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-04-25, at 9:35 AM, Justin Richer wrote:

> If we needed a registry we could define it in this spec. If we chose a non-registry method (like how grant_type uses URIs) then it's self-contained. I prefer the latter, myself.
> 
> The client already has to be prepared because the server will inform, though. But by making it bidirectional (like all the other parameters) it gives the client a chance to ask based on whatever information it wants to. The server is perfectly free to ignore what the client asks for and just hand it something, just as it's free to     do so for all fields. 

> The parameters of the negotiation are going to be application-protocol specific and depend on things like a Discovery layer for them to be fully dynamic from a cold boot. And even then servers and clients that care about this value are going to have to know how to enforce it (it's the same as it is with grant_type, response_type, scope, and others). 
> 
> If nothing else, it lets servers tell clients which auth method to use at the token endpoint. The client can be smart and try to figure out if it actually supports that method before trying it, or it can be dumb and ignore the returned value. But with this parameter in the protocol, both sides at least have a *chance* of doing the right thing.
> 
>  -- Justin
> 
>> 
>> Phil
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Apr 2013 13:21:23 -0400

If you want your client app to be able to speak to all servers, yes, 
you'll have to implement all methods. But even this is a problem because 
servers can come up with a new method -- that's the whole point of 
making this field extensible, isn't it? And again, you could make the 
same argument about grant_type and several other fields. Say you've got 
a client that only does authorization_code, but the server sends back 
"implicit" to the client. Will they be able to speak? No, and if the 
client application or library wants to be able to speak to this server 
it's going to have to implement the implicit flow to do so.

So I think that your concern here, while definitely valid, is a bit 
misleading. I don't think it's OAuth Dyn Reg's goal to solve the 
complete cold-boot problem across all possible combinations of clients 
and servers, since a client application is going to need to be able to 
speak whatever protocol OAuth is protecting anyway in order to do 
anything past the authorization step. However, I do think it makes 
perfect sense for a client library to be able to say "here's the value 
that I want" and have the server say "here's the value that you get" in 
a means that's parallel across all of these fields.

  -- Justin

On 04/25/2013 01:09 PM, Phil Hunt wrote:
> If the server is free to ignore, doesn't that mean the client ends up 
> having to implement *ALL* methods anyway? In the case of Connect, the 
> client has to implement all methods supported by Connect because it 
> *could* be forced by any particular deployer to use a particular method.
>
> The dynamic draft + unspecified discovery doesn't (as described) 
> doesn't make clients or servers actually easier to implement.  Any 
> client not implementing all methods runs the risk of sooner or later 
> not being compatible.
>
> I agree there is a need for registration to convey to the client what 
> authentication method and client credential it has been issued.
>
> Phil
>
> @independentid
>> If we needed a registry we could define it in this spec. If we chose 
>> a non-registry method (like how grant_type uses URIs) then it's 
>>> 2. In general i would like to avoid negotiations. It seems to me 
>>> that any developer making a client for a mutli-site deployed service 
>>> would already be aware of what the generic service require and 
>>> implement based on that oob knowledge. Thus when the server merely 
>>> informs, the client should be prepared.
>> though. But by making it bidirectional (like all the other 
>> parameters) it gives the client a chance to ask based on whatever 
>> information it wants to. The server is perfectly free to ignore what 
>> the client asks for and just hand it something, just as it's free to 
>> do so for all fields.
>>
>> The parameters of the negotiation are going to be 
>> application-protocol specific and depend on things like a Discovery 
>> layer for them to be fully dynamic from a cold boot. And even then 
>> servers and clients that care about this value are going to have to 
>> know how to enforce it (it's the same as it is with grant_type, 
>> response_type, scope, and others).
>>
>> If nothing else, it lets servers tell clients which auth method to 
>> use at the token endpoint. The client can be smart and try to figure 
>> out if it actually supports that method before trying it, or it can 
>> be dumb and ignore the returned value. But with this parameter in the 
>> protocol, both sides at least have a *chance* of doing the right thing.
>>
>>  -- Justin
>>
>>>
>>> Phil
>>>
>>>> I am OK with having a registry,  Connect profiles the jwt 
>>>> assertions draft to add specifics around keying material for 
>>>> interoperability.
>>>> While sending a list of methods the client supports to the server 
>>>> and getting back what is supported by the server works, it is awkward.
>>>>
>>>> set only by the server.  I don't know if we want to start adding 
>>>> them to registration just to allow for them to be discovered.   
>>>> Using a simple .well-known discovery document seems simpler.
>>>>
>>>>> server discovery in here. :) But since the server does echo back 
>>>>> the configuration in its response, the client is discovering a few 
>>>>> things at run time about what it can and can't do with a 
>>>>> particular server. It's entirely possible that the client might 
>>>>> get back a configuration option that it can't use (say, it can't 
>>>>> do client_secret_jwt assertions but it can do
>>>>>
>>>>> I think the first one should be addressed, but we just need to 
>>>>> pick the method. I'm personally in favor of the same method we 
>>>>> used for grant_type, which is short values in the spec and 
>>>>> extensions as fully qualified URIs. The second one could break 
>>>>> existing implementations (and other dependent specs), so if we 
>>>>> change it, it has to be for very good reason.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>> The general pattern is the RP discovers the capabilities of the 
>>>>>> AS authentication methods and algorithms supported by the AS.
>>>>>> It would in theory work of the client knowing nothing about the 
>>>>>> AS pushed it's capabilities at the AS as you are suggesting and 
>>>>>> let the AS pick.
>>>>>>
>>>>>>>> authentication methods. The reason to allow a client to 
>>>>>>>> register using a particular one is to prevent downgrade attacks.
>>>>>>>>
>>>>>>>> reasonable for a client to specify which one it is going to 
>>>>>>>> use. In a closed system that may not be that useful but in a 
>>>>>>>> open system where the AS has a looser relationship to the 
>>>>>>>> client it is important.
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>>> factors. As you say, there isn't any other place that 
>>>>>>>>> enumerates the various [authn] methods a client can use to 
>>>>>>>>> access the token endpoint.  So, why do it?
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>>> Seems reasonable to me, can you suggest language to add in 
>>>>>>>>>> the capability? Would it require an IANA registry? Right now 
>>>>>>>>>> there isn't any other place that enumerates the various 
>>>>>>>>>> methods that a client can use to access the token endpoint.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>