269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document":  Resource description documents are "private" and specific, but scope description documents are public and meant to be possible to standardize (e.g. pointing to third-party scope description documents), and thus, things like internationalization and localization of strings could be tricky. So a MUST is a big problem. At best, we can say that it's all down to developer documentation, not anything run-time. And as Mike pointed out, a URN isn't run-time resolvable in practical terms.

Since we rely on dynamic registration of resources and scopes, how ideally should this work? Eve wonders if we should add a new option: the string-based scope in a resource description is fine, a URI-based one that doesn't resolve is fine, but the RS could also resolve the scope description and stuff it into the resource description by value during registration. George notes that OIDC's "claim request hash" mechanism for handling localization could work. Mike asks if we're overdesigning.  We're generally not crazy about playing I18N and L10N games with scope strings, either.

At the very least, we have to qualify that if the scope is a URN they don't have to resolve. And at the very least, the AS has to be prepared for failure to access any required scope description information.

1. Do nothing.
2. Change minimally to say the URI MUST resolve scope references to a scope description document only if they're URLs and add failure logic.
3. Change more to say that the AS SHOULD attempt to resolve the reference URL, but soften the language generally and acknowledge that it's more in the realm of developer documentation.
4. Change even more to say that scope description metadata is possible to standardize, publicize, and reference through a URI, but there is no expectation of run-time resolution by the AS; rather any customization of policy condition setting interfaces with respect to scopes is, um, out of scope.
5. (Not mutually exclusive with any of the above:) Add an internationalization/localization way for handling user-exposed strings in the scope description document, likely modeled on the OIDC "claim request hash trick".

• Most scopes are still firmly in simple-string territory.
• Especially given that clients have the option of pre-registering for scopes, and that scopes are generally the "public-safe" part of any API, there's a lot about scope semantics that's beneficial if it's documented ahead of time.
  
• The less dependency on run-time calls to potential third parties for UX elements, the better.
• I can see the argument for the "claim request hash trick" if we're concerned about I18N/L10N, but given my first rationale and the fact that even OIDC puts this trick into the MAY and SHOULD category, I think it's a nice-to-have that could easily just become an optional practice among those who need it that gets absorbed much later.