Re: [OAUTH-WG] OAuth Discovery

Bill Mills <> Mon, 14 December 2015 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 027781AD0BB for <>; Mon, 14 Dec 2015 09:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.491
X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l1g048OmU8kf for <>; Mon, 14 Dec 2015 09:54:51 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D79861ACE8D for <>; Mon, 14 Dec 2015 09:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1450115689; bh=n3qsd7BFotG//zoMbLo8WH5907C8x5sSq5Px5REiUPQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qqEGGHitjlhbl7vReILIeYwuzve8IpiROXxtgmEFGV1Tuhq928ABdQAnKM71aCvv4/TCm9AagMwUfBHW3WYyDy6agdQwa0YEft0XktSwAFIyHwYy2T/Hr0OQqueJqemxWA24dkg+oc2fztTM7UZyfgP4fMkDTYK7PwGwKC2WF0p9xSLafXubC2hlTgY3Xhq5QqS/x/xaQl1e0nmj6X1fk57ec+eAI4lcgNvkOOpe65evyreBXt7qsMHjS0Dzpsa9FUYa8oDbDYhNgY66nCDxtp2USUoS7gFktbmHjs3lb/J32LptxECuh7LIcJ+0I8n9fC33ni8gaW07wZJz01RL+w==
Received: from [] by with NNFMP; 14 Dec 2015 17:54:49 -0000
Received: from [] by with NNFMP; 14 Dec 2015 17:54:49 -0000
Received: from [] by with NNFMP; 14 Dec 2015 17:54:49 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: ihia6nIVM1lURd7qt2rAnfogQNkzQCgxoW435fPlrun8mStCN3KZeQIcLL9i5Yb uVrhPDS9gxVdRd2DHZ6bZ7y99XhXbxYB1bZmohgpR69l5CQDJ7LOnF7o9GAe7_g44Qn2gh9tAAKE mV7_IMTuLJYWI6IASoSAR6smXtSHP40gaoBpG4USSfRArYEX7cQf1.ykpvoW0xURxQ4fq14wjTHm lJjoAbh5f9Jq5aC1A5h.1._GqfsDpcVjjoVUqrAlLq4Icws1LPz8kzfRnLNDOyboYVM0YtKzRDzx 1jPFV0jNYqGuAqrF0IqZUuB6FgWejbafwwGno3Q6IHSZAbmr0kYxykbnNdM9BqPTZmb0btqb9l6P 5qtdNkwjRGWt.6cd0AM3srP7EPnHfmZs_k6ls3_IuNd7wSkPmMqJkmJacB5sXiihuCNtRSQLzalz 2GXPrJj1iMTHROsKxz.iAr43PSxG4jjRDtTURWMEkfsmXf_g_fmNsnYldvkx85v4zZb8HnXk4qvi Q.AkpsyvXM4A-
Received: by; Mon, 14 Dec 2015 17:54:49 +0000
Date: Mon, 14 Dec 2015 17:54:49 +0000
From: Bill Mills <>
To: Torsten Lodderstedt <>, Mike Jones <>, "" <>, Nat Sakimura <>, John Bradley <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_990700_863714657.1450115689082"
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth Discovery
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Dec 2015 17:54:54 -0000

I think it is more likely that the flow for the user will be that they know an RS and the RS provides some reference to the AS.  The RS might well consume a generic lookup flow though.  We do need the "updated webfinger thing" for users as a generic though.

The WF type thing for a generic user lookup in a domain might be used for discovering the SMTP/IMAP/webmail entrypoints for a user along with the AS and that's another possible useful thing.  User specific rather than apparently server/service specific. 

    On Sunday, December 13, 2015 12:59 PM, Torsten Lodderstedt <> wrote:

  Hi Mike, Nat, John,
 thanks for starting this work. 
 It seems you assume 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. We potentially need to cover for both cases. 
 What do you think?
 best regards,
 Am 26.11.2015 um 00:37 schrieb Mike Jones:
#yiv5368577927 #yiv5368577927 -- _filtered #yiv5368577927 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv5368577927 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5368577927 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5368577927 {panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv5368577927 #yiv5368577927 p.yiv5368577927MsoNormal, #yiv5368577927 li.yiv5368577927MsoNormal, #yiv5368577927 div.yiv5368577927MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927 a:link, #yiv5368577927 span.yiv5368577927MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv5368577927 a:visited, #yiv5368577927 span.yiv5368577927MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv5368577927 pre {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5368577927 p.yiv5368577927MsoListParagraph, #yiv5368577927 li.yiv5368577927MsoListParagraph, #yiv5368577927 div.yiv5368577927MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927 span.yiv5368577927EmailStyle17 {color:windowtext;}#yiv5368577927 span.yiv5368577927HTMLPreformattedChar {}#yiv5368577927 span.yiv5368577927grey {}#yiv5368577927 .yiv5368577927MsoChpDefault {} _filtered #yiv5368577927 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5368577927 div.yiv5368577927WordSection1 {}#yiv5368577927 _filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Wingdings;} _filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Wingdings;} _filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Wingdings;}#yiv5368577927 ol {margin-bottom:0in;}#yiv5368577927 ul {margin-bottom:0in;}#yiv5368577927  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 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 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 specific to OpenID Connect.    The specification is available at: ·    An HTML-formatted version is also available at: ·                                                                    -- Mike    P.S.  This note was also posted at and as  @selfissued.  
OAuth mailing list
OAuth mailing list