Re: [OAUTH-WG] OAuth Discovery

John Bradley <> Sun, 13 December 2015 20:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 423A71A03ED for <>; Sun, 13 Dec 2015 12:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r2nkVQtqSl0L for <>; Sun, 13 Dec 2015 12:52:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A5841A037E for <>; Sun, 13 Dec 2015 12:52:26 -0800 (PST)
Received: by obbsd4 with SMTP id sd4so69161877obb.0 for <>; Sun, 13 Dec 2015 12:52:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8CXOGl4B7m4Kb+3Rl7BKieP6Cio259j3pa+xTA5HHHM=; b=YhX0COB6Y5AyGzLsr2NF+SSdFsi9GkeBqP22gfhvl69z/x+lW3JZ/bCZDO2B7bMBrO +uVQZIvHk+klsVQLWHFCld9XLBjpS1UlM+U2T5fo2VRudQ3CbbnRUy0ra/LaJczqFtHt ufnEk6bZkqaG603Z/xrDYYwYJAXdIu6/Dg+/RyLVTBu5kTZ8egQnifmVwmijnSPYO16P LD99CoWNiBr/PLeISXKmjReaBFx0lehD4euFWthJnrnHflr9Gs/9h3NYcDMWUFjKduc8 FCqcc15B8UnRZGrc8/HA94I8soGvVMkKaqP6Ll7LSXc7Pmj9zbLraq+65qzss1vzUBJg sUVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8CXOGl4B7m4Kb+3Rl7BKieP6Cio259j3pa+xTA5HHHM=; b=auB3ja+yyBhi65mWQhTZvQDjuC2Y9mkow48MV/rakt3zNZ4Mjot7LDQPFykKRvXVLN 07Z5AAQyvdeKURJJCXGyVo+zJUGTw+pOX5gGfnaZ95iv3r+NSd5/x8hZ8jHuUMm9cIEo yZ+6qG1fBHltxCKDD9QFWPMybSl5MFPOMTg5Zx3sdi6LeabMXggEtHbJUzSWppjduWcJ cQS3CX0PqnkdV226RTzWwrjHY+KjFertxy78tisPJEyK50JrqMLCyrA36VFeEXaDM2w3 CbNHHrlEeaGRU7gKrWuEBSCyVfYf3MH+0Twousf+dvLn0Ez8i9+O6h3/Jm/jh4yAtLpe 1+VQ==
X-Gm-Message-State: ALoCoQlpu1AHuJN+uqvPdY6s8HV/AK4SoBq21/bg+eYm541A0F/YZD8jKfB92WZL2M9b+FoVSVJlPQs8tcjL+SMFK/4vT/ssGQ==
X-Received: by with SMTP id d3mr22235938oer.24.1450039945608; Sun, 13 Dec 2015 12:52:25 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id mj8sm13548418obc.25.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Dec 2015 12:52:24 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A2C2D40-9B41-4618-871D-3F490E3C3426"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <>
In-Reply-To: <>
Date: Sun, 13 Dec 2015 14:52:23 -0600
Message-Id: <>
References: <> <>
To: Torsten Lodderstedt <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] OAuth 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: Sun, 13 Dec 2015 20:52:29 -0000

I tend to agree that we need both.

We needed to start someplace.   

The user based discovery may better be described as finding a OAuth Service/API for the user, authentication, photo, calendar, health record etc.
We may want to separate that from the OAuth discovery as that could be used independently.

Anyway the document is a start.

John B.

> On Dec 13, 2015, at 2:43 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,
> Torsten.
> Am 26.11.2015 um 00:37 schrieb Mike Jones:
>> 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
>> <>
>> <>