Here is how *OIDC* refers to all of this. The relevant spec is called OpenID Connect *Discovery* <http://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. The relevant spec is called OAuth Authorization Server *Metadata* <https://tools.ietf.org/html/draft-ietf-oauth-discovery-04>, but note that the IETF I-D is ietf-oauth-discovery. The spec postdates and is attempting to align with OIDC. 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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Nov 1, 2016 at 6:06 PM, Eve Maler <eve@xmlgrrl.com> wrote:
https://github.com/KantaraInitiative/wg-uma/issues/256
This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates *configuration/discovery* terms from the GitHub issue:
- configuration data (original) - discovery document (proposed; might change the name of the directory -- or should it be file? -- where the metadata resides)
For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl