Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Justin Richer <jricher@mit.edu> Tue, 09 February 2016 22:19 UTC

Return-Path: <jricher@mit.edu>
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 8A5541B2BE9 for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 14:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 7E0qMc8pprcN for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 14:19:02 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DA1B2C10 for <oauth@ietf.org>; Tue, 9 Feb 2016 14:19:02 -0800 (PST)
X-AuditID: 1209190c-4ffff7000000165e-cb-56ba65d4eefa
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 8A.99.05726.4D56AB65; Tue, 9 Feb 2016 17:19:01 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u19MJ0jL032033; Tue, 9 Feb 2016 17:19:00 -0500
Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u19MIwkJ010437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2016 17:18:59 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A996B329-3DAC-4828-8787-19E0A1739260"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com>
Date: Tue, 9 Feb 2016 17:18:57 -0500
Message-Id: <0FF7CC5E-3975-4483-8428-3B9718ECFA00@mit.edu>
References: <BY2PR03MB4427E9DAFDE674F71F6074AF5D60@BY2PR03MB442.namprd03.prod.outlook.com> <F6DD25EE-8B49-45E4-BACC-872CA98F2D7B@mit.edu> <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTYRjmOzvbjmsnTtPyc6bRaUEpmwkOLczyT0n5IwYa+EeP7svNtinn bOYMyugCKtrFW815yaREK0zSvOB10kUojS4MNYMlGUtDJAoNo3OcN+jf+77P7f34XkKk+CpW EkaLFbEWxkRLZLhCGqdSf0DdyQcqJrGY3soFPObVnFcS0/JpWXJUlNDYuIglXO1cliZMTDzB T4lSZLF6ZDLmIjYiLk1meNHUieVUt4O8wltvJQXgZS0oAn4EpKKg84sLKwIyQkFdw2Cbqxf4 mlYAX9fNSHzNOAZrnW5MkPhTJ2HRwCVcqElKA73j78QCSUSVA/i5fYknEbyvEt7upwSOhNoL qx5eWdH6UXHQ6SxbicYpFeyaql/xEVEpsLhnUSpISeoQnGsz+XJ7AGx8PCsVOAE8v6/Ps7p2 COz548FuAMqxaQ3H5jUcK77p8OfkN+Crw+H9u99Fvno/7C9+gP8/3wcLf90U++pd8Nmcc3V+ EN67417lH4bjpfWr/nHQU9kgrgdbmkGI3pyvNjNGE4cy1FwGY7EgVh2pMRutGqS3tQHhC/2C 5J1gdpAeAhQBaDnpjupOVoiZXM5uHgJBBEZvJ+Vh/GhrerbebmA4QyprMyFuCKj4LE9ryxhQ 4pZsC6IDyNDZrmQFqWfs+YjNXqMFEzgdSHqWeIjKZKzoLEI5iF1DdxIEDclhPR+wjUWZKO+M 0WTdgDHCbwhAQs6bLwgcksthzJwx04ePgN3KQHJaACgBMNgs61rhPNPmXFovCOSf5U+G8leq kPPHu6728sYYb9z0t0MwtjIbkLIAtOeGBLvLewfnmSxroSPa0jD8cTokWRfduWw/Zkt0Exfp Eet72fXnqsyJ8gHNqC49qw47ob1QYvNW/Zj67e/Ummp2pB4JYE3+ruMz57oqlhOBMmZM9TS+ Famll52GEmVKxB5d6enq2N1ZSbb4N2Xh0801j0Y7tI7Sed1o0nka5wxMZJiI5Zh/bl+NS3kD AAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Owmco6hM-rfORW40UixRnY71jTI>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification
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, 09 Feb 2016 22:19:05 -0000

Webfinger without a rel= doesn’t make much sense for us to define, does it? What output value is the client going to look for in the response, then? I’m with John that we should let applications define their own rel= values and therefore leave webfinger out entirely.


I don’t buy the historical compatibility argument here, and keep in mind I’m an implementer who will need to support both endpoints if we do split it. I already have a server that supports both /.well-known/openid-configuration and /.well-known/uma-configuration so I’m not at all worried about the perceived overhead. If a protocol like OIDC wants to replicate the information in the OAuth discovery document, that’s fine. If it wants to instead reference the OAuth discovery document for the OAuth values, that’s also fine. But that’s a decision up to the application protocol that’s using OAuth.

It’s much cleaner to define something new and keep it structurally compatible (or at least not incompatible) with the OIDC version.

 — Justin


> On Feb 9, 2016, at 5:03 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> If we keep webfinger I don’t think that having a generic OAuth rel makes sense.   It should be up to each API/Protocol to define it’s own rel value like Connect has done.
> 
> It is not reasonable to think that a persons ID provider is going to be the same as the one for calendaring or photo sharing.
> 
> So I could go two ways with webfinger,  leave it out completely, or leave it in but make it up to the application to define a rel value.
> I expect that some things using UMA in web-finger would point directly to the resource and the resource would point the client at the correct UMA server.
> 
> The config file name in .well-known could stay as openid-configuration for historical reasons or we could change it.
> 
> I think we first need to decide if every protocol/API is going to have its own config file, we are going to get apps to retrieve multiple files,  or everything is going to go into one config-file and applicatins just add to that?
> 
> I prefer not to change the file name if we are going for one config file, but if we do one alias/link is probably not the end of the world, as I doubt people will ever remove openid-configuration one if they have it now.
> 
> John B.
> 
> 
>> On Feb 9, 2016, at 2:19 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> 
>> Mike, thanks for putting this up.
>> 
>> 
>> I would like to propose for two changes that have been brought up before:
>> 
>> 1) The wholesale removal of section 2, Webfinger lookup.
>> 
>> 2) The changing of "/.well-known/openid-configuration” to "/.well-known/oauth-authorization-server” or something else not openid-related.
>> 
>> 
>> 
>>  — Justin
>> 
>> 
>>> On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
>>> 
>>> We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.
>>> 
>>> The specification is available at:
>>> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-00>
>>> 
>>> An HTML-formatted version is also available at:
>>> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html <http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html>
>>> 
>>>                                                           -- Mike
>>> 
>>> P.S.  This notice was also posted at http://self-issued.info/?p=1534 <http://self-issued.info/?p=1534> and as @selfissued <https://twitter.com/selfissued>.
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> 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>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>