search

AMWA-TV / is-10

AMWA IS-10 NMOS Authorization Specification
https://specs.amwa.tv/is-10
Apache License 2.0
3 stars 4 forks source link

[dannym-refactor] Location of Authorization Server Metadata #8

Closed garethsb closed 4 years ago

garethsb commented 4 years ago

The current goal is to align IS-10 with RFC 8414, and as such support the method defined in RFC 8414 Section 3 for discovery of the server endpoints.

The current RAML adds a /.well-known/oauth-authorization-server endpoint. However, that is relative to the base URL defined in the RAML which is /x-nmos/auth/{version}.

I wondered if the intent was to have a top-level /.well-known/oauth-authorization-server endpoint that redirected to the one defined in the RAM L, but I can't see that RFC 8414 (or RFC 5785) allow a redirect response, suggesting only 200 OK for a successful response?

(I'm also not clear as to the use-cases for RFC 8414 multiple issuers on a host, which it describes in section 3.1, resulting in the well-known URL request being to https://api.example.com/.well-known/oauth-authorization-server/{issuer} instead. Can you explain?)

dannymeloy commented 4 years ago

Hi Gareth,

  1. The RAML is currently mistaken - the /.well-known/.. endpoint will hang off the the root path (e.g. https://{host}:{port}/.well-known/oauth-authorization-server.)
  2. With regards to both versioning of the well-known endpoint (mentioned in issue #9) and multiple issuers on the same host, the thinking currently is that we define another text record in the DNS-SD announcement (call it issuer_path.), for a given auth server instance, that defines the {issuer} tag in the .well-known url. This will usually be blank or omitted, meaning clients default to the URL you have given above. If multiple auth services are hosted on the same host, or if integrating with an Off-the-Shelf auth server with a metadata URL with a different {issuer}, this issuer_path record can distinguish/point-at the auth server instances. From an NMOS perspective, this record could also give clients distinct server metadata URLs for different versions if we needed to - using two DNS-SD records with different text records. In this case, both the api_ver and issuer_path records may both be equal to v1.1 for example.

I hope that makes sense...

garethsb commented 4 years ago

Thanks, that does start making sense. I think it's going to be simpler to document the /.well-known/ URL via separate means, whether that's pure documentation or a separate RAML file.

NEOAdvancedTechnology commented 4 years ago

worked out