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

Le mar. 10 juil. 2018 21:55, Andres Torres <janthoe@gmail.com> a écrit :

>    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
>


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 <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
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>