Re: [OAUTH-WG] OAuth Discovery

Brian Campbell <bcampbell@pingidentity.com> Sun, 13 December 2015 23:33 UTC

Return-Path: <bcampbell@pingidentity.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 689D81A8968 for <oauth@ietfa.amsl.com>; Sun, 13 Dec 2015 15:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 K3qthKrsIcBm for <oauth@ietfa.amsl.com>; Sun, 13 Dec 2015 15:33:30 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 5B1421A896A for <oauth@ietf.org>; Sun, 13 Dec 2015 15:33:28 -0800 (PST)
Received: by iofq126 with SMTP id q126so17364299iof.2 for <oauth@ietf.org>; Sun, 13 Dec 2015 15:33:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E+YHJrEwdKAVFDBCemOTWuGZTIuV+uwL7VhleASE6c4=; b=AtJK7AeHrogCQ8/gOAVLUUb/yBenB5ORy/xoCtbBs1XIMhmcFvkC0Rp6aomrsDtPwE 7ZIWWD9dAoXHRb0jSjRqNdjiOCPP4bIDdIhsI+d3Qold5pJruFJ9lzBHkREQ3lfK8CcZ qY5IyUaGuZXsMG5YbPWB+qBr9sjMA80ILIN4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E+YHJrEwdKAVFDBCemOTWuGZTIuV+uwL7VhleASE6c4=; b=QVnvvnvvdkycOX15ppLKutuMLuJ+Hu8hi/og+vuFxzOdB2B+DvqKYeSmfqmRZZPxLK +dkmJxkPV7FDEA2iMUTvjClIlt+dcqgLYar44n0fe0RYTchV+PdM26Bcgvf4Pwp6QjqQ 9xW6gedJZuswkTnij5eZ0XpLiryOenDj1/8zfo2pGUeG10PPItMXSENcw9yAssEDyN97 58gXfglSRr0tw0bMLb9Zawlc/X2cebhC6D5jzBvhiV/X08yIorroUZoo+giUt4TJSNQw llwcrtvfkTBL5qDI6gYslyefmh7gshSIE1407lmmJc+PVFvsoCgOt0m4gNJllFp5VzId 0MmA==
X-Gm-Message-State: ALoCoQn3QvM9mp0YmNynH32yHxFEC/KkTu11OI8JG4uIrX7Wa9gRJ/UqePS9GfZUYq8mt3RXNuTFhkzoKtqVv9ayAZN738ntD89Le8YFryiBF9yUKK3tIj4=
X-Received: by 10.107.158.213 with SMTP id h204mr32889424ioe.129.1450049607725; Sun, 13 Dec 2015 15:33:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.23.133 with HTTP; Sun, 13 Dec 2015 15:32:58 -0800 (PST)
In-Reply-To: <4294D9BE-FE7C-48DB-80D8-56744792873B@ve7jtb.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com> <566DD856.1010603@lodderstedt.net> <4294D9BE-FE7C-48DB-80D8-56744792873B@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Sun, 13 Dec 2015 16:32:58 -0700
Message-ID: <CA+k3eCRKTKiddNc9eaKVeEpRQyWrN5r=2uZKkExGoVvFJZG7HQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="001a114075c2c68ee90526cffb0e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/QoIU7KjJbH9asNBgkuqEj83W6K4>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery
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: Sun, 13 Dec 2015 23:33:32 -0000

Would it be worth considering constraining the scope of this document to
the publication and content of AS metadata? And keep the actual discovery
of that metadata out of scope or in a different document(s)?

On Sun, Dec 13, 2015 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> 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 <torsten@lodderstedt.net>
> 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
> <https://tools.ietf.org/html/rfc6749#section-1.8>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
> <http://openid.net/specs/openid-connect-discovery-1_0.html> 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:
> ·          <http://tools.ietf.org/html/draft-jones-oauth-discovery-00>
> http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> An HTML-formatted version is also available at:
> ·         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
>
>                                                                 -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as
> @selfissued <https://twitter.com/selfissued>.
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>