Could I suggest a different option: If the scope is a URI, the RS MUST ensure that the AS is able to resolve

the URI to an internationalized scope description document. For example, if the URI is an HTTP-based URI, the RS should ensure that URI is accessible to the AS and returns scope description documents for the locale in the HTTP request, or if the URI is a URN, the RS must ensure that the AS maintains a registry of scope description documents for the URN(s) being used.

As an optional extension, a new optional field scope_descriptions could be added: An object where the keys are scope values listed in the scope field, and

the values are URLs that the AS is able to resolve to scope description documents. For example, if the scope value is a machine-readable value, URN, or non-standard scheme-based URL, for which the AS does not maintain a description for, the RS would provide a URL for the description it wants to be used.

So where the scope value is fixed but not explicitly supported by the AS, the RS can enable it to support it. So if you have some sort of standard that fixes your scope values, in a closed ecosystem you might have a standard-compliant AS, which maintains its own registry of all the standard scopes with appropriate i18n descriptions, but in a wide ecosystem you'd be more likely to have a non-compliant AS but which can be made to support the standard by providing description mappings for the standard values, perhaps hosted by the RS, or the standards body. Thoughts? Cheers James On 22 January 2017 at 22:31, Eve Maler wrote:

In this message, I want to share the results of the ad hoc discussion we had after Thursday's formal call ended, and present options for going forward, along with a proposal. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!)

Here's the relevant part of the notes http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19 :

====

*269 https://github.com/KantaraInitiative/wg-uma/issues/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 http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsLanguag..." mechanism for handling localization could work. Mike asks if we're overdesigning. [image: (smile)] 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. ====

Here are the options I can think of. (Let me know if I missed any.)

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".

====

Here is my proposal: *Option 4 alone, not with the option 5 rider*. Rationale:

- 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.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma