Re: [OAUTH-WG] OAuth Discovery

Nat Sakimura <sakimura@gmail.com> Thu, 26 November 2015 16:35 UTC

Return-Path: <sakimura@gmail.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 59ADC1B2BBA for <oauth@ietfa.amsl.com>; Thu, 26 Nov 2015 08:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.693
X-Spam-Level:
X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no
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 gNg8PcZkjx48 for <oauth@ietfa.amsl.com>; Thu, 26 Nov 2015 08:35:20 -0800 (PST)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910CA1B2BB8 for <oauth@ietf.org>; Thu, 26 Nov 2015 08:35:20 -0800 (PST)
Received: by obbbj7 with SMTP id bj7so65930153obb.1 for <oauth@ietf.org>; Thu, 26 Nov 2015 08:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dh1SbNRLbHkNn0vcMzvdT/7lC/tXvsMGRHRQVxjNyz0=; b=ehqZEqNGb2fMn+uOOrOBzqPiSCJcfZ2EEPuv3aqUQZ5K+RZFi5FzCeOVbvC3wXYP0h uFmHYvctplbiQ3Ieqd1/n6gOX0DSgo3/aPvHRwKJN2PnMmFEfqMbYA2X6uYr0X3caZrz 6WBb4TiAw6nsj5r2iQ4iWOO0RaaBzsMTPJmC7qtD94jX8CxJE4Bv4jeaiW9iYXLzRGeb g4hbAAxGcgzES+FNhxum+Aeaqg/Bi6CKsDKYlp/QuKOkMTNFnd9LK3CNX4mJqG+2wbgy /0M+NBl2L5HlfxTdxP/1Eu008QDaV9ncUCg6KLE4Uk8EzlVuslQKrgDs/AmFABN/gPUa aOuw==
MIME-Version: 1.0
X-Received: by 10.182.251.130 with SMTP id zk2mr28291941obc.57.1448555719970; Thu, 26 Nov 2015 08:35:19 -0800 (PST)
Received: by 10.182.236.196 with HTTP; Thu, 26 Nov 2015 08:35:19 -0800 (PST)
In-Reply-To: <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com> <565717A0.7080805@connect2id.com> <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com>
Date: Fri, 27 Nov 2015 01:35:19 +0900
Message-ID: <CABzCy2DMOuZ_zXKOhESLT9pgDAaxMWkzgPe7KgqhY-VXP14EOQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=089e01634c2a2059b905257429f1
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/zAOBmb8d97ZwLchXb1-OWfjf3fs>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Nov 2015 16:35:26 -0000

Agreed...

2015-11-27 0:59 GMT+09:00 John Bradley <ve7jtb@ve7jtb.com>:

> The methods could be the same but they should probably specified
> separately eg
>
> introspection_endpoint_auth_methods_supported
>
> If we overload them we will probably regret it later.
>
> John B.
>
> On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov <vladimir@connect2id.com>
> wrote:
>
> Good work, Mike, John, Nat!
>
> I see that the introspection and revocation endpoints are included now
> (they've been missing in OpenID discovery).
>
> Regarding client authentication, would it make sense to let
> token_endpoint_auth_methods_supported apply to the introspection and
> revocation endpoints as well?
>
> token_endpoint_auth_methods_supported
>       OPTIONAL.  JSON array containing a list of client authentication
>       methods supported by this token endpoint.  Client authentication
>       method values are used in the "token_endpoint_auth_method"
>       parameter defined in Section 2 of [RFC7591] <http://tools.ietf.org/html/rfc7591#section-2>.  If omitted, the
>       default is "client_secret_basic" -- the HTTP Basic Authentication
>       Scheme specified in Section 2.3.1 <http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-2.3.1> of OAuth 2.0 [RFC6749 <http://tools.ietf.org/html/rfc6749>].
>
>
>
> Vladimir
>
> On 26.11.2015 01:37, Mike Jones wrote:
>
> I'm pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 <https://tools.ietf.org/html/rfc6749#section-1.8> <https://tools.ietf.org/html/rfc6749#section-1.8> states:
>
> In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery).  Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
>
>
>
> This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
>
> This specification enables discovery of both endpoint locations and authorization server capabilities.
>
> This specification is based upon the already widely deployed OpenID Connect Discovery 1.0<http://openid.net/specs/openid-connect-discovery-1_0.html> <http://openid.net/specs/openid-connect-discovery-1_0.html> specification and is compatible with it, by design.  The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not
>  s
> pecific to OpenID Connect.
>
> The specification is available at:
>
> *         http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> An HTML-formatted version is also available at:
>
> *         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
>
>                                                                 -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>.
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> 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
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en