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

Mike Jones <> Wed, 24 April 2013 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F37321F8D05 for <>; Wed, 24 Apr 2013 16:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SqVJNNHdxrzB for <>; Wed, 24 Apr 2013 16:18:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A227A21F8CEC for <>; Wed, 24 Apr 2013 16:18:46 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 24 Apr 2013 23:18:43 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 24 Apr 2013 23:18:43 +0000
Received: from ([]) by ([]) with mapi id 14.02.0318.003; Wed, 24 Apr 2013 23:17:27 +0000
From: Mike Jones <>
To: Phil Hunt <>, John Bradley <>
Thread-Topic: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
Date: Wed, 24 Apr 2013 23:17:26 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676ABC64TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(479174001)(24454001)(60454002)(199002)(189002)(66066001)(51856001)(71186001)(56776001)(79102001)(65816001)(16236675002)(55846006)(6806003)(47446002)(16601075002)(31966008)(53806001)(20776003)(15202345002)(74502001)(56816002)(564824004)(54356001)(49866001)(81342001)(81542001)(63696002)(74366001)(33656001)(16406001)(59766001)(54316002)(15974865001)(4396001)(76482001)(80022001)(69226001)(47736001)(74662001)(77982001)(50986001)(512954001)(47976001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB028;; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Forefront-PRVS: 0826B2F01B
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Apr 2013 23:18:49 -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:

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: [] On Behalf Of Phil Hunt
Sent: Wednesday, April 24, 2013 3:55 PM
To: John Bradley
Cc: WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

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.



On 2013-04-24, at 3:41 PM, John Bradley wrote:

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.

On 2013-04-24, at 7:30 PM, Phil Hunt <<>> wrote:

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?



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
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?

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




OAuth mailing list<>

OAuth mailing list<>