Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-discovery

Andres Torres <janthoe@gmail.com> Tue, 10 July 2018 19:55 UTC

Return-Path: <janthoe@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1550C1311A3 for <oauth@ietfa.amsl.com>; Tue, 10 Jul 2018 12:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yU2VhSmu0LUD for <oauth@ietfa.amsl.com>; Tue, 10 Jul 2018 12:55:10 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 74D861310CD for <oauth@ietf.org>; Tue, 10 Jul 2018 12:55:10 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id q11-v6so19399486oic.12 for <oauth@ietf.org>; Tue, 10 Jul 2018 12:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hao9trAvwiGpPtuEKgQwREDOtBMhiFWSyh/G/Xz1kck=; b=B4dg2Ya9v9/V812k0sPGe9xScV39WSvdWM689kR8rHPUR74wMeY/ZSePgaGtQLK6B/ QO/Noz7DUDbTVC70LkGLocZq/be/AiBFqjVcAUYSBwwEJQbQd8J1N+85ySwRW/tC5tlv THPhCm+BLy3PX1hdZZTM1eJgDRNJ5JqF1bw+unM394WNbHs+LBh35DHhG4ZOHp+kKiaq Ik8KW9S88VoNr17lVloMazAdoUgQvVLRXc0XotRFvYsC2etZoZLs6R+eiYDOTQMx/PWk Dd+ciHJM7u/Zeysii9zTRsoaZ4J8TQGxFGaiKkA6z0ha/BV1dZOpTVXQQrBDCxfaBiwt 8GCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hao9trAvwiGpPtuEKgQwREDOtBMhiFWSyh/G/Xz1kck=; b=bgrFfpUgJWENwHPpdulJeITA4c1K7rnIX/x8UKrC0rG39mL3QiMgeQmB5yZPwh17c1 wq4CVJNRknk7d8incta22k120etGrw+nEbkVRxsJVG3bPXdT1CKsFJElHkU3RrhcNR8S MLmXw74J3Pofy4nxDrhuae8FkN7s9SNJYZ4bzPTOP5n6N0rGu0TmwJWVpMREmvpD2MfH tLbIh/FJrwHdJDst9n4Q3u2zb+OMDXjNmm9qthp+CHRjxJtZgzQSW7iZGFZu0BA+/Yeq uG2FpEOriXRfMNyZFIl8rQDGd7cUF7rGh1wxVknXweIWiYXtO546KhNGARijRgP90uYa bHrg==
X-Gm-Message-State: APt69E0wF17usrEJHcASQ7pxeA5lEhgSlAftAJLkEjrR8p/YDztEDhzD daSqtQqPoTMQVOxE5mHpbyJeeqZ60LfXPPkPjE0=
X-Google-Smtp-Source: AAOMgpfvZSaW56poKRyceexPZD/rfUaApzj1QX6Q0iei4BKlWDcpt4IPPxF0H+sH4HDm01de21Wr5J7WKWRaFY2716U=
X-Received: by 2002:aca:cf97:: with SMTP id f145-v6mr30423795oig.131.1531252509837; Tue, 10 Jul 2018 12:55:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:2369:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 12:54:49 -0700 (PDT)
In-Reply-To: <273B4B99-866D-4F6D-A2A8-3410B4ED2A3D@alkaline-solutions.com>
References: <CAEdHPxrSNT0N4CiaDv+rzhh44m0g4zqUNwFq85tp6kMeVC7h-w@mail.gmail.com> <273B4B99-866D-4F6D-A2A8-3410B4ED2A3D@alkaline-solutions.com>
From: Andres Torres <janthoe@gmail.com>
Date: Tue, 10 Jul 2018 15:54:49 -0400
Message-ID: <CAEdHPxpJej4A2S-_tnqMP1sj=ntbcETarrNMXRSGRce4tN8epQ@mail.gmail.com>
To: David Waite <david@alkaline-solutions.com>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e90d800570aa81e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Z5LYh9IT3r_UApQCROkNqDP1Wp4>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 19:55:14 -0000

   If the issuer identifier value contains a path component, any
   terminating "/" MUST be removed before inserting "/.well-known/" and
   the well-known URI suffix between the host component and the path
   component.


Just as clarification then, this section does not require that path
components not related to the issuer should be removed from the URI:
ex:
https://example.com/{application-identifier}/.wellknown/oauth-authorization-server/{issuer}

Is that correct?

The language in this section suggests that the url path should start in
every case with /.well-known, which would not allow to have URIs like the
one in the example above, ie: {application-identifier} and
/.wellknown/oauth-authorization-server
should always be at the root of the host

~AT

On Tue, Jul 10, 2018 at 2:39 PM, David Waite <david@alkaline-solutions.com>
wrote:

>
>
> On Jul 10, 2018, at 12:19 PM, Andres Torres <janthoe@gmail.com> wrote:
>
>
> In terms of API design the final result is confusing. The resource
> /.well-known/oauth-authorization-server becomes a collection of resources
> where issuer is a subresource.. However,
> /.well-known/oauth-authorization-server should be a subresource of the
> issuer/tenant. It is my understanding that .well-known is a prefix for
> known resources in a given service. Multiple instances of a service (ie:
> tenants) can be hosted using the same hostname in the form
> {issuer|tenant-identifier}/.well-known/{known-resource}. This way a
> proper resource hierarchy can be maintained in the URI namespace
> and heterogeneous services can be deployed under the same hostname.
>
>
> This is/was actually how it was done within OpenID Connect. However, the
> only structured URL components allowed within IETF specifications are
> underneath a /.well-known root. Since a multi-tenant application may have a
> different issuer per tenant all within one origin, this transformation was
> created such that each can have their own metadata.
>
> Another option would have been to have the issuer URL be the discovery
> URL, but this would require an issuer of https://example.com to modify
> the root of their service to respond to requests for metadata (such as in
> response to the requirements of an Accepts header).
>
> A third option might be to define an ‘issuer’ parameter and behavior on
> the metadata endpoint, such that servers which host only one issuer could
> ignore it, but a server with multiple issuers could require and act on this
> parameter.
>
> -DW
>