Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?
Justin Richer <jricher@mitre.org> Thu, 24 April 2014 13:56 UTC
Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DAB1A0232 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 06:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.471
X-Spam-Level:
X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9Vsl_dzAOyz for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 06:56:49 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7D1A0248 for <oauth@ietf.org>; Thu, 24 Apr 2014 06:56:49 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 854821F0899; Thu, 24 Apr 2014 09:56:43 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6CD711F0898; Thu, 24 Apr 2014 09:56:43 -0400 (EDT)
Received: from [10.146.15.6] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 24 Apr 2014 09:56:43 -0400
Message-ID: <535917F4.1040909@mitre.org>
Date: Thu, 24 Apr 2014 09:56:04 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Brian Campbell <bcampbell@pingidentity.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <4E1F6AAD24975D4BA5B16804296739439A191DC0@TK5EX14MBXC288.redmond.corp.microsoft.com> <5357EF2E.1020503@mitre.org> <CA+k3eCTSQmWihysbvUi+pqwuqmfPT5PuOs0mH5tTiRFAS=JVjA@mail.gmail.com> <5358D4B2.1070500@gmx.net> <CA+k3eCTf5Tk8pRFGoo9+aZ2_T3sK2aqQLRgnz0A=E=y+gxzMyA@mail.gmail.com>
In-Reply-To: <CA+k3eCTf5Tk8pRFGoo9+aZ2_T3sK2aqQLRgnz0A=E=y+gxzMyA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070106080304050709060509"
X-Originating-IP: [129.83.31.51]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/suBa_ih80IMdiXO9rFEG9N7am3M
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 13:56:53 -0000
This is the intent of my draft (and results of my implementation), and if the WG ever picks up token introspection as a work item then we can make sure it says that. -- Justin On 04/24/2014 08:44 AM, Brian Campbell wrote: > Perhaps it'd be more appropriate for this introspection endpoint to > say that it accepts the same client authentication mechanisms as the > token endpoint rather than describing specific methods itself in the > document? > > > On Thu, Apr 24, 2014 at 3:09 AM, Hannes Tschofenig > <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote: > > Hi Brian, > > does it sound reasonable for you to add text to the token > introspection > endpoint regarding the use of the JWT bearer assertion for the token > introspection endpoint? > > Ciao > Hannes > > On 04/24/2014 12:58 AM, Brian Campbell wrote: > > Just to pile on here - the Assertions draft(s) do define client > > assertion authentication only for the token endpoint (and > register token > > endpoint parameters). But it certainly doesn't preclude it from > being > > profiled for use elsewhere. > > > > FWIW we used the token endpoint in our implementation of token > > introspection/validation partly because all supported forms of > client > > authentication come along for free by doing so. My esteemed > colleague, > > Dr. Paul Madsen, posted a rough draft of what we've implemented in > > product a while back: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html > > > > > > On Wed, Apr 23, 2014 at 10:49 AM, Justin Richer > <jricher@mitre.org <mailto:jricher@mitre.org> > > <mailto:jricher@mitre.org <mailto:jricher@mitre.org>>> wrote: > > > > For introspection, we really just wanted to say "you can > > authenticate the caller (client or RP) just like you would > to the > > token endpoint". So if you've got the means to do that with the > > assertion draft or with client secrets or TLS certs or anything > > else, go for it. I would not read the text of the assertions > draft > > as restricting this other use case. > > > > -- Justin > > > > > > On 04/23/2014 12:42 PM, Mike Jones wrote: > > > > The assertions draft is only trying to describe how to > perform > > assertion-based authentication at the Token Endpoint. Other > > drafts, such as the introspection draft, could > explicitly say > > that this can also be done in the same manner there, but > that's > > an extension, and should be specified by the extension > draft, if > > appropriate - not in the assertions draft. > > > > Justin may have more to say about the applicability or > lack of > > it to the introspection draft, but I'm personally not > familiar > > with it. > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org> > > <mailto:oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>>__] On Behalf Of Hannes Tschofenig > > Sent: Wednesday, April 23, 2014 5:09 AM > > To: oauth@ietf.org <mailto:oauth@ietf.org> > <mailto:oauth@ietf.org <mailto:oauth@ietf.org>> > > Subject: [OAUTH-WG] Assertions: Client authentication for > > non-token endpoints? > > > > Hi all, > > > > in a discussion about re-using the client authentication > part of > > the assertion framework for other specifications > currently in > > progress I ran into the following question: > > > > Section 6.1 of > > http://tools.ietf.org/html/__draft-ietf-oauth-assertions-15 > > <http://tools.ietf.org/html/draft-ietf-oauth-assertions-15> > > talks about the client using the assertion with the **token > > endpoint**. > > > > Now, it appears that one cannot use the client > authentication > > with other endpoints, such as the introspection endpoint > defined in > > > http://tools.ietf.org/html/__draft-richer-oauth-__introspection-04#section-2 > > > <http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2> > > > > Am I reading too much into Section 6.1 of the assertion > draft? > > > > Ciao > > Hannes > > > > _________________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/__listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > _________________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/__listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > >
- [OAUTH-WG] Assertions: Client authentication for … Hannes Tschofenig
- Re: [OAUTH-WG] Assertions: Client authentication … Mike Jones
- Re: [OAUTH-WG] Assertions: Client authentication … Justin Richer
- Re: [OAUTH-WG] Assertions: Client authentication … Brian Campbell
- Re: [OAUTH-WG] Assertions: Client authentication … Hannes Tschofenig
- Re: [OAUTH-WG] Assertions: Client authentication … Hannes Tschofenig
- Re: [OAUTH-WG] Assertions: Client authentication … Brian Campbell
- Re: [OAUTH-WG] Assertions: Client authentication … Hannes Tschofenig
- Re: [OAUTH-WG] Assertions: Client authentication … Justin Richer