Here is how
OIDC refers to all of this.
The relevant spec is called
OpenID Connect Discovery. However, "discovery" in this context refers primarily to OpenID Provider Issuer discovery, which means determining the location of the OpenID Provider by means of webfinger given an identifier that was input by a user. This takes up all of Section 2. Discovery is optional.
Section 3 catalogues OpenID Provider metadata, the equivalent of what we are currently calling configuration data for an UMA authorization server.
Section 4 describes the process of obtaining configuration information, which seems to be a synonym for what was just previously catalogued as metadata. The well-known location is, in fact, called /.well-known/openid-configuration. There's a GET request called a "configuration request", and the OP's response is called a "configuration response". (This spec accounts for a process of configuration information validation, something we hadn't thought of yet. Also dictating how to do string comparisons. Nice.)
====
Here is how OAuth refers to all of this.
Section 2 catalogues the metadata. (It also explicitly accounts for how to sign bundles of values, which is a nice added capability.)
Section 3 discusses, in a framework sort of way, how the metadata MUST be made available at a /.well-known location whose name MUST be IANA-registered. The word configuration is thrown around a lot wrt what the JSON document might be called, but this isn't required. The word "discovery" doesn't come up.
====
Here is a proposal for people to throw tomatoes at.
- Continue to use "/.well-known/uma2-configuration" for the well-known location. Rationale: This is consistent with what both OIDC and OAuth (in spirit) do.
- Use "configuration data" / "configuration document" to describe the information about the authorization server endpoints etc. Rationale: "Metadata" as an additional word adds no value and actually seems confusing in the OIDC case. "Configuration" is consistent with at least one version of what both OIDC and OAuth conceive this information to be, and "data" is shorter than "information". And it's what we do now. :-)
- Use the word "discovery" only in the context of describing actual discovery: say, when the RS gives the client the as_location, or when the client learns a protected resource's location out of band of UMA, etc.
- Align other wording passages with the OIDC spec wording wherever possible.
- Add something about configuration data validation a la OIDC.
- Check that we have covered all cases of string comparisons a la OIDC.
- Discuss whether to add signed configuration data bundles a la OAuth.