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

From: Andres Torres <[email-masked]>
Date: Tue, 10 Jul 2018 14:19:19 -0400

Regarding RFC 8414 (Proposed Standard) Section 3.1.  Authorization Server
Metadata Request:

   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.  The client would make the following request when the
   issuer identifier is "https://example.com/issuer1" and the well-known
   URI suffix is "oauth-authorization-server" to obtain the metadata,
   since the issuer identifier contains a path component:

     GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
     Host: example.com

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.

Thanks in advance for you time.

Cheers,

Andres Torres

---

From: David Waite <[email-masked]>
Date: Tue, 10 Jul 2018 12:39:53 -0600

> On Jul 10, 2018, at 12:19 PM, Andres Torres <[email-masked]> 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 <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

---

From: Andres Torres <[email-masked]>
Date: Tue, 10 Jul 2018 15:54:49 -0400

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 <[email-masked]>
wrote:

> where issuer is a subresource.. However,
> {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
>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 11 Jul 2018 08:38:56 +0200

Le mar. 10 juil. 2018 21:55, Andres Torres <[email-masked]> a écrit :

> one in the example above, ie: {application-identifier} and /.wellknown/oauth-authorization-server

This is how it is defined in https://tools.ietf.org/html/rfc5785

>
> ~AT
>
> On Tue, Jul 10, 2018 at 2:39 PM, David Waite <[email-masked]
> > wrote:
>
>>
>>
>> /.well-known/oauth-authorization-server becomes a collection of
>> resources where issuer is a subresource.. However,
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>