-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dannym-refactor] Location of Authorization Server Metadata #8
Comments
Hi Gareth,
I hope that makes sense... |
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. |
worked out |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?)
The text was updated successfully, but these errors were encountered: