Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 01 March 2016 08:39 UTC

Return-Path: <vladimir@connect2id.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 862C01B35BF for <oauth@ietfa.amsl.com>; Tue, 1 Mar 2016 00:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 R6OlYGYlfydy for <oauth@ietfa.amsl.com>; Tue, 1 Mar 2016 00:39:27 -0800 (PST)
Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5989B1B35BE for <oauth@ietf.org>; Tue, 1 Mar 2016 00:39:27 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-05.prod.phx3.secureserver.net with id QYfR1s00115ZTut01YfRhe; Tue, 01 Mar 2016 01:39:26 -0700
To: oauth@ietf.org
References: <E3BDAD5F-6DE2-4FB9-AEC0-4EE2D2BF8AC8@mit.edu> <BN3PR0301MB123439E7F8083A5C557EED28A6A50@BN3PR0301MB1234.namprd03.prod.outlook.com> <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com> <BY2PR03MB442E135F59374B40084665EF5A50@BY2PR03MB442.namprd03.prod.outlook.com> <17E6C845-D633-45F6-A123-515437583F02@oracle.com> <BY2PR03MB442BA8094FF4718BCA93112F5A50@BY2PR03MB442.namprd03.prod.outlook.com> <BY2PR03MB442C4E813E7ADFED795526BF5A50@BY2PR03MB442.namprd03.prod.outlook.com> <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com> <BY2PR03MB442847F4E292B4AA0498F52F5A60@BY2PR03MB442.namprd03.prod.outlook.com> <E7CF381C-5780-415C-8182-714B43F149CA@oracle.com> <56CEC24C.8040709@connect2id.com> <BY2PR03MB4425461F4C68FAAABC422BDF5A60@BY2PR03MB442.namprd03.prod.outlook.com> <CAF2hCbaowJs+aBU_RrQVj3R6RGX89nsUqinSgAevQeu2+=PS1A@mail.gmail.com> <BY2PR03MB442FFEDAA5B8ED7A8FAAD9BF5B80@BY2PR03MB442.namprd03.prod.outlook.com> <CA+k3eCTg_ztKj4z7y3JpUMF6Mt9PQdHjUw1J0_Rg4tVS=dsP6A@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D5553C.3070709@connect2id.com>
Date: Tue, 01 Mar 2016 10:39:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTg_ztKj4z7y3JpUMF6Mt9PQdHjUw1J0_Rg4tVS=dsP6A@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090305020601000302080108"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/uRrYySMOi4cicLrZdF7GJssyMw0>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
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: Tue, 01 Mar 2016 08:39:29 -0000


On 01/03/16 00:34, Brian Campbell wrote:
> +1 for "OAuth 2.0 Authorization Server Discovery” from those two options.
>
> But what about "OAuth 2.0 Authorization Server Metadata”?
>
> The document in its current scope (which I agree with, BTW) isn't really
> about discovery so much as about describing the metadata at some
> well-known(ish) resource.

This sounds even more precise. The updated draft no longer mentions how
the client arrives at the AS metadata URL, just its format and
parameters. So the discovery bit is essentially gone from it.

Because if we take the OIDC definition of discovery, then

"OpenID Provider Issuer discovery is the process of determining the
location of the OpenID Provider."

(from
http://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery )

So the draft has been reduced to mimicking sections 3 and 4 of OIDC
Discovery:

3.  OpenID Provider Metadata ->
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
4.  Obtaining OpenID Provider Configuration Information ->
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

I would like to vote for "OAuth 2.0 Authorization Server Metadata”


Cheers,

Vladimir


> On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
>> It’s clear that people want us to move to the name “OAuth 2.0
>> Authorization Server Discovery”.  The editors will plan to make that
>> change in the draft addressing Working Group Last Call comments.
>>
>>
>>
>>                                                           Thanks all,
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Samuel Erdtman [mailto:samuel@erdtman.se]
>> *Sent:* Saturday, February 27, 2016 6:47 AM
>> *To:* Mike Jones <Michael.Jones@microsoft.com>
>> *Cc:* Vladimir Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org
>>
>> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>
>>
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>>
>>
>>
>> //Samuel
>>
>>
>>
>> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>>
>> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
>> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
>> 2.0 Authorization Server Discovery”.  While the abstract already makes it
>> clear that the scope of the document is AS discovery, doing so in the title
>> seems like it could help clarify things, given that a lot of the discussion
>> seems to be about resource discovery, which is out of scope of the document.
>>
>>
>>
>> I’m not saying that resource discovery isn’t important – it is – but
>> unlike authorization server discovery, where there’s lots of existing
>> practice, including using the existing data format for describing OAuth
>> implementations that aren’t being used with OpenID Connect, there’s no
>> existing practice to standardize for resource discovery.  The time to
>> create a standard for that seems to be after existing practice has
>> emerged.  It **might** or might not use new metadata values in the AS
>> discovery document, but that’s still to be determined.  The one reason to
>> leave the title as-is is that resource discovery might end up involving
>> extensions to this metadata format in some cases.
>>
>>
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
>> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
>> document is about the AS.  We don’t yet have a specification or existing
>> practice for RS discovery, which would be the 6750 analogy.
>>
>>
>>
>> In summary, which title do people prefer?
>>
>> ·       “OAuth 2.0 Discovery”
>>
>> ·       “OAuth 2.0 Authorization Server Discovery”
>>
>>
>>
>>              <OAuth@ietf.org>
>>
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth