Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

Brian Campbell <bcampbell@pingidentity.com> Wed, 23 April 2014 22:59 UTC

Return-Path: <bcampbell@pingidentity.com>
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 03B641A0729 for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 cmQyclFVuc3h for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:59:00 -0700 (PDT)
Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 72D881A0728 for <oauth@ietf.org>; Wed, 23 Apr 2014 15:59:00 -0700 (PDT)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKU1hFrjn3ddFMCoNHXbZ7yASE7aI7E6g4@postini.com; Wed, 23 Apr 2014 15:58:55 PDT
Received: by mail-ie0-f179.google.com with SMTP id lx4so1586184iec.24 for <oauth@ietf.org>; Wed, 23 Apr 2014 15:58:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=e3hVKuMRpJtQkJdMmYPNvmTDyoEPt6+ZYlfdUwMHNdc=; b=Ab2Lpg0dA8ymOMnpilYqTr2egnA1QyBBK7kyjCXz/bWxkoKrNsDcWJiQ62a3zI81Kw qe3W0qJCcHtoJ3UBVDZ6dq2DYfB+a8OL4glIMpyjm/tqiAwL4ftxsAQAvC7O5o+IHLJu 9/Pc3GX5s6qb6i7UZC3z07CanHycceducQGKeES1ae3P865YV8dAt4IH91Go1eHhgfZo Dq/G0SD5JLi8mvD3S3EjWHuWg7yTf3jha60/4TO/tcP97zi6PqOGP1PPd1vO2QUBxXs+ pZYKruG/H6MqRXQep63MSGWTgb/rgZjNP/XQxI1K4mfj6LbokQ8Dd+hDKeRrJX8m+dWS 6h+Q==
X-Gm-Message-State: ALoCoQmX4VXcggCBbivcr15yec6uHxbo7bamqzaf9zbeheFFYIRR0f0UUi5915GjAvPA8GgttlsAhTOx41fMV5WFLfzBVwwJAKpBBlctU6bQ0ssbRiNxDZAP+qpVxnBcN9RBJraBU2c0
X-Received: by 10.43.143.211 with SMTP id jn19mr47402971icc.0.1398293934563; Wed, 23 Apr 2014 15:58:54 -0700 (PDT)
X-Received: by 10.43.143.211 with SMTP id jn19mr47402958icc.0.1398293934433; Wed, 23 Apr 2014 15:58:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Wed, 23 Apr 2014 15:58:24 -0700 (PDT)
In-Reply-To: <5357EF2E.1020503@mitre.org>
References: <4E1F6AAD24975D4BA5B16804296739439A191DC0@TK5EX14MBXC288.redmond.corp.microsoft.com> <5357EF2E.1020503@mitre.org>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 23 Apr 2014 16:58:24 -0600
Message-ID: <CA+k3eCTSQmWihysbvUi+pqwuqmfPT5PuOs0mH5tTiRFAS=JVjA@mail.gmail.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: multipart/alternative; boundary=001a11c2f1ac40fe1c04f7bdad1d
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3ojjIEEBmZmupRCqiGsTOKpTvPg
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: Wed, 23 Apr 2014 22:59:03 -0000

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> 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] On Behalf Of Hannes
>> Tschofenig
>> Sent: Wednesday, April 23, 2014 5:09 AM
>> To: 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 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
>>
>> Am I reading too much into Section 6.1 of the assertion draft?
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>