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

[Justin Richer]

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
>>>> *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"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 
>>>> <mailto: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
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto: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/3e363dc0/attachment.html>