Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

Phil Hunt <> Tue, 02 February 2016 23:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 325AF1A90D5 for <>; Tue, 2 Feb 2016 15:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-ir4H57bZVp for <>; Tue, 2 Feb 2016 15:49:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83A3F1A90D0 for <>; Tue, 2 Feb 2016 15:49:00 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u12NmwSK010686 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Feb 2016 23:48:59 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u12Nmw7v010543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 23:48:58 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u12Nmw5Q024063; Tue, 2 Feb 2016 23:48:58 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Feb 2016 15:48:58 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FBE4939-A9E4-4207-B605-A96EDB614028"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt <>
In-Reply-To: <>
Date: Tue, 02 Feb 2016 15:48:56 -0800
Message-Id: <>
References: <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3112)
X-Source-IP: []
Archived-At: <>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Feb 2016 23:49:03 -0000

I have two separate comments here:

Item 1: Regarding Torsten’s comment

I think there are two scenarios….
A. The client, not knowing who the user is wants to discover the appropriate OAuth endpoint - a generic discovery via ./well-known/oauth

Or wants to discover the OAuth server for a particular web resource.  Maybe a webfinger query that is resource=service:someurl  is more appropriate.

B.  A server wants to discover the OAuth endpoint based on an account identifier for the user. This is appropriate particularly when cloud service providers run multiple oauth tenancies.   (I don’t believe we have this case).

Item 2:  rel value for webfinger
It seems to me while the discovery requirements for plain OAuth and OIDC are the same for today that might not always be true.  What will happen if OIDC wants to add more stuff?  Will plain oAuth sites have to comply?

A client may want to know both the OAuth discovery endpoint information for a resource AND it might want to know the OIDC discovery information.  They endpoints might not always be the same - how do we tell them apart?

I don’t see a big inter-op issue.  Implementation is easy - support for rel=oauth might be as simple as making rel=oauth an alias for rel=  OIDC clients can continue to use rel=


@independentid <> <>

> On Feb 2, 2016, at 3:02 PM, Brian Campbell <> wrote:
> I agree (kind of anyway) with Torsten. Discovery based on the user id of the resource owner doesn't necessarily make sense for general OAuth cases. 
> Also restating what I already posted about the draft: Would it be worth considering constraining the scope of this document to just the publication and content of AS metadata? And keep the actual discovery of that metadata, be it from the RS or the user id or what have you, out of scope or in a different document(s)? The former is relatively well understood and provides some value. While the ideas about how the the latter should work seem to have a pretty broad range. 
> On Tue, Jan 26, 2016 at 12:35 PM, Torsten Lodderstedt < <>> wrote:
> Hi,
> I support the adoption of this document as starting point for our work towards OAuth discovery.
> Restating what I already posted after the last IETF meeting: It seems the document assumes the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. I think the spec needs to cover the latter case as well. 
> kinds regards,
> Torsten.
> Am 19.01.2016 um 12:48 schrieb Hannes Tschofenig:
>> Hi all,
>> this is the call for adoption of OAuth 2.0 Discovery, see
>> <>
>> Please let us know by Feb 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> Note: If you already stated your opinion at the IETF meeting in Yokohama
>> then you don't need to re-state your opinion, if you want.
>> The feedback at the Yokohama IETF meeting was the following: 19 for /
>> zero against / 4 persons need more information.
>> Ciao
>> Hannes & Derek
>> _______________________________________________
>> OAuth mailing list
>> <>
>> <>
> _______________________________________________
> OAuth mailing list
> <>
> <>
> _______________________________________________
> OAuth mailing list