Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

John Bradley <ve7jtb@ve7jtb.com> Thu, 18 February 2016 17:22 UTC

Return-Path: <ve7jtb@ve7jtb.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 2EE181ACDD8 for <oauth@ietfa.amsl.com>; Thu, 18 Feb 2016 09:22:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 N6glDyxX6eYM for <oauth@ietfa.amsl.com>; Thu, 18 Feb 2016 09:22:00 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 78DA71ACAD4 for <oauth@ietf.org>; Thu, 18 Feb 2016 09:22:00 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id e185so50823021vkb.1 for <oauth@ietf.org>; Thu, 18 Feb 2016 09:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Z90KeViVOHpfrQqimxDubnbJUGcboZn2q9VKzdnSRlA=; b=pstLGZXdLQqStJjfL2M0Stw1e4SxzL07Se7EmtExQe/QyavgRfTikHcqqCbVLOeacl H97YhhR8Xv2oY7/DFyo7tzlGmMCgljumjvXOTgfWorrnfqK0WYUhaC1lZLLdiwmldXHK WiUCwuzRXEhPPH/wYfU8pS0SaHEaX78bvVPpRMRx2U7hIgYueaAoPaZB48S5tigddtus IoqNdnZTRlsTeS6Dlvw6Z4I9SR1h+mZJ/j7WRQSCYep1xLBMdOSetSu3gFX42+RqcRee i2b2hA0REd1QReGyNRSt1b7vpJJy1sjw7KSwaM9/5//gtrf2K1f9Ix+C2+bekMt5ajVh ncyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Z90KeViVOHpfrQqimxDubnbJUGcboZn2q9VKzdnSRlA=; b=GgjWe6nAKY3sq9MQMGJsYsM8UI0Fzz1k+qPLhCobmVB0u2pNqzAmAkO8NKxToD2+zM 0KhTnRDedocVmuNUi4RqpkExUjnGs+tGB/vaPsUpOSRUY1+6yAzLq2MybsN3sdnUJp5p HkZxRHkUh/XqRajmg/v7USZujWvnzeNStNaGNa4/eBAodNXUMAnVmdMkkK0VdDEFrgaq bu3VIq3cC4Lx3WIIp+pt3f5tuuTw4sZ+wdzlz7/iG0hU55ioHF+4FkrHESTO0HTnDBb3 pBf8VBkCWQNjRnTnrxGuvRZ2GFY32DqCpKgdPPjJHRVIpuIyJoUUneHIM1YulcVyfhWW 5jqQ==
X-Gm-Message-State: AG10YOSUfcL9pXMjaPmrjUnDmXi5PdIn1YP6fZr1A5zfwrsXOarQP2pNdeHV7mjBsRtRMQ==
X-Received: by 10.31.173.8 with SMTP id w8mr7236242vke.42.1455816119414; Thu, 18 Feb 2016 09:21:59 -0800 (PST)
Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id w144sm850818vkd.2.2016.02.18.09.21.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 09:21:57 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_3A280F6A-FA7F-49A4-835C-4817D00CFBD1"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com>
Date: Thu, 18 Feb 2016 12:21:56 -0500
Message-Id: <6FEF11D0-C150-4DDA-9152-A71FBC28564C@ve7jtb.com>
References: <BY2PR03MB44236EF33376F8C2BB135E8F5AF0@BY2PR03MB442.namprd03.prod.outlook.com> <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <A52BE40A-DEF2-48D6-9612-5BD035104DDB@oracle.com> <ACE3AB4B-7400-443B-AFFF-4832BADB371B@ve7jtb.com> <FFEF6A31-B9FD-432E-97F7-3E03F9541B88@oracle.com> <A3C1068B-446E-405A-A441-86503F60D17C@ve7jtb.com> <BY2PR03MB4425DF67B0BB624401EE7A0F5AF0@BY2PR03MB442.namprd03.prod.outlook.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/pqRTwAsOnxGt3ASzeb_q7Bc7iio>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
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, 18 Feb 2016 17:22:06 -0000

The protocol would need to have a .well-known location registered or use the default well-known for OAuth.

Apps would look for there specific configuration and fall back to the generic one if that is not available.

To save apps making multiple request the server can just link the  app specific well-knowns  to the OAuth well-known.

I don’t know of a OAuth app that doesn’t have preconfigured logic about the API it is using.  
Part of that pre configuration should be what well-known file to look for if required.

Also nothing stops enterprises from making up there own well-known locations for specific apps.

Also it would be up to app /api developers to register a well known for oauth and one for whatever else they need to configure, or if it is a small amount of info they could extend the OAuth discovery registry with a resource URI location for the protocol etc.

John B.

> On Feb 18, 2016, at 12:09 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
> 
> How does the client request the oauth configuration assigned to xyz?
> 
> The example you give appears to presume a single oauth infrastructure for all apps. 
> 
> The only way right now to have apps specific oauth is to infer the relation by the domain "xyz.example.com <http://xyz.example.com/>".  
> 
> That makes discovery more complex because there arw many more discovery locations and many more configurations to maintain. 
> 
> If example.com <http://example.com/> had separate oauth servers for services xyz and abc, how would discovery work from a single /.well-know endpoint?
> 
> Phil
> 
> On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
> 
>> Let me second John’s point that OAuth configuration information and application configuration information need not be interspersed.  For instance, if the service is at https://example.com <https://example.com/> and the XYZ application is being used, then these configuration metadata documents could both be used:
>> ·       https://example.com/.well-known/openid-configuration <https://example.com/.well-known/openid-configuration> - OAuth configuration metadata
>> ·       https://example.com/.well-known/xyz-configuration <https://example.com/.well-known/xyz-configuration> - XYZ configuration metadata
>>  
>> There’s not much point in defining a new /.well-known/oauth2.0 value, since there is no such thing as generic OAuth 2.0.  By definition, it must always be used in an application context that profiles OAuth 2.0 to enable interoperability.  The existing /.well-known/openid-configuration value works fine for this purpose.  Yes, the optics of having a different value might seem better but it comes at the cost of interoperability problems.  In my view, interop trumps optics.
>>  
>> To a point that George Fletcher made, WebFinger could still be used to learn the locations of these configuration metadata documents if that makes sense in the application context.  The editors took WebFinger out of the OAuth Discovery document since it isn’t always applicable.
>>  
>>                                                           Cheers,
>>                                                           -- Mike
>>   <>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>] 
>> Sent: Thursday, February 18, 2016 7:41 AM
>> To: Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>
>> Cc: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>; oauth@ietf.org <mailto:oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>>  
>> I suspect that the configuration well-knowns are going to be on the root domain.   You could try and get a user to put in crm.example.com <http://crm.example.com/>, but I suspect that is not going to work.
>>  
>> If the app doesn’t have a specific protocol identifier then it would use the default.  
>>  
>> I don’t know if you can get around having some sort of app/protocol identifier configured in the app.
>>  
>> John B.
>>  
>>  
>>  
>>  
>>  
>>  
>> On Feb 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>  
>> resource service X could be any http accessible service:
>>  
>> * CRM
>> * Finance
>> * Payroll
>> * ERP
>> * any application on the web.
>>  
>> The spec seems to suggest that we use /.well-known/crm to discover OAuth config for crm.  But that may cause conflict if crm has its own discovery. Which leads us down the path of doing something like “crm-oauth”.
>>  
>> Then there is confusion about what host the discovery is done on.
>>  
>> For example, hypothetically do I do:
>>  
>> GET /.well-known/crm
>> Host: example.com <http://example.com/>
>>  
>> But what about the CRM’s configuration information. Is this stomping on it?
>>  
>> Or, what If we put the oauth configuration at the host for the crm service:
>> GET /.well-known/openid-configuration
>> Host: crm.example.com <http://crm.example.com/>
>>  
>> I think the point is that there is a relationship between a protected resource and its designated OAuth service. 
>>  
>> The client needs to discover:
>> * Where is its designated resource service and what security does it use
>> * If it is OAuth, where is the intended OAuth configuration for that resource service instance?
>>  
>> Phil
>>  
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>  
>>  
>>  
>> 
>>  
>> On Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>>  
>> Can you clarify what you mean by “resource service x”?
>>  
>> Is that the RS base URI for the resource,  a specific URI that the client is requesting?
>>  
>> That is getting UMA ish. 
>>  
>> The concept of a base RS URI is a rat hole that I prefer not to go down, as it is something everyone thinks exists but like SCIM if it exists it is protocol or deployment specific.
>>  
>> The notion that you would send the URI you are planning on requesting to a Webfinger server to find the OAuth server, is probably going to have privacy issues.
>>  
>> I suspect that you need to hand back a error from the resource to say where the AS is, or have a .well-known for the RS.
>>  
>> RS discovery probably wants to be separate from AS discovery.  (Yes I do think we need something,  UMA rpt or something like it might be a way to go)
>>  
>> John B.
>>  
>> On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>  
>> Maybe SCIM was a bad example.  It functions as a RESTful resource in the context of OAuth.
>>  
>> I find the use of OIDC to be confusing as an example (and the default) because it is both an OAuth resource and a security service.  It is a modification of OAuth.
>>  
>> Start thinking about every application ever written that uses OAuth. Are we expecting 100s of thousands of these to each register?
>>  
>> To me, this specification is a fine specification for OIDC and it should be published there because the specification defines how to discovery OAuth and OpenID information.
>>  
>> Likewise you suggest it is ok for SCIM to do the same. 
>>  
>> How do we expect normal applications to set up and do discovery?
>>  
>> It seems to me that an “OAUTH” discovery spec should have a parameter to ask, I want to discover OAuth configuration for resource service X.
>>  
>> That still allows me to have a separate discovery service that says, tell me about resource service X itself.
>>  
>> BTW. I think we are FAR from Last Call on this topic.
>>  
>> Phil
>>  
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>  
>>  
>>  
>> 
>>  
>> On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>>  
>> Diffrent protocols like Connect and SCIM may have different configurations, endpoints , keys , authentication methods, scopes etc.
>>  
>> It should be posable to have them as one document, but forcing them to use one document is going to cause a explosion of claim registration for discovery.
>>  
>> I think it is better for SCIM to register one well known than to have to register 20 claims with scim prefixes or something silly like that.
>>  
>> Name-spacing the claims by allowing them to be in different well known files is not unreasonable.
>>  
>> Remember some of these protocols may be hosted on SaaS so there is no guarantee that all protocols will have the same OAuth Config.
>>  
>> Nothing stops a protocol from doing what it likes with webfinger if it wants to use that for discovery.
>>  
>> In principal I like the idea of having another protocol as an example.
>>  
>> My only concern is that I haven’t seen any discussion of your SCIM discovery document in the SCIM WG.  
>> I personally think sorting out discovery for SCIM is a good idea,  but OAUTh is but one of several authentication methods for SCIM, and there are probably other non OAuth things that want to be described.
>>  
>> I would feel better about using it as an example if it were adopted by the WG and some general interest shown.
>>  
>> I encourage you to do that so we can use it as a example.
>>  
>> John B.
>>  
>> On Feb 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>  
>> I still find the following text objectionable and confusing…
>>    By default, for historical reasons, unless an application-specific
>>    well-known URI path suffix is registered and used for an application,
>>    the client for that application SHOULD use the well-known URI path
>>    suffix "openid-configuration" and publish the metadata document at
>>    the path formed by concatenating "/.well-known/openid-configuration"
>>    to the authorization server's issuer identifier.  As described in
>>    Section 5 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#section-5>, despite the identifier
>>    "/.well-known/openid-configuration", appearing to be OpenID-specific,
>>    its usage in this specification is actually referring to a general
>>    OAuth 2.0 feature that is not specific to OpenID Connect.
>>  
>> Further, as a default “openid-configuration” as the default further gives people the impression that a plain OAuth server *is* an authentication server and that the normal access token received is evidence of a successful authentication.
>>  
>> It would be better to point out that application may include oauth discovery in their discovery URI and that OAuth is an example of this. It might be good to include two examples.  E.g. OIDC and SCIM (as another referenceable example).
>>  
>>  GET /.well-known/openid-configuration
>> and
>>  GET /.well-known/scim
>> Retrieve the OAuth configuration for the application openid and scim respectively.
>>  
>> The use of:
>>  GET /.well-known/oauth2/
>> Should be the default used when there is no known application based well-known application based URI discovery.
>>  
>> Of course, the concern I raised earlier is that this approach of application specific URIs ends up requiring every application to make an IANA registration if they don’t want to use the default of “oauth2” (or “openid-configuration”).  Is that what the authors expect?
>>  
>> It seemed better to me to use the webfinger syntax to allow the client to say “I want the designated OAuth configuration for the resource service X” would be a better design that avoids extensive IANA registration.
>>  
>> Phil
>>  
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>  
>>  
>>  
>> 
>>  
>> On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
>>  
>> In response to working group input, this version of the OAuth Discovery specification has been pared down to its essence – leaving only the features that are already widely deployed.  Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it.  The WebFinger discovery logic has been removed.  The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.
>>  
>> Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.
>>  
>> The specification is available at:
>> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01>
>>  
>> An HTML-formatted version is also available at:
>> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html <http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html>
>>  
>>                                                           -- Mike & Nat & John
>>  
>> P.S.  This notice was also posted at http://self-issued.info/?p=1544 <http://self-issued.info/?p=1544> 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>