Given the rev 05 text, I'm not sure how to "resolve to a scope description document" (section 2.1) if the string in the scope array is a URN (Mike's point from the discussion). Is there another way for the AS to get the scope description document? Also the scope description document is defined as representing a single scope rather than a set of scopes (which would make more sense if the scope string is a URN). This also applies if the scope string is a "plain text" string like "view". Also, given that "name" MAY be used in user interfaces, should this value be an array and use the OpenID mechanism to support localization? Thanks, George On Wed, Jan 25, 2017 at 12:03 AM Eve Maler wrote:

In the forthcoming rev 05, I have tried defining the "scopes" property now as "REQUIRED. An array of strings, *serving as scope identifiers,* indicating the available scopes for this resource. Any of the strings MAY be either a plain string or ...." Let's see how that flies.

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

On Mon, Jan 23, 2017 at 1:03 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

+1 Option 1 and +1 saying so in the spec.

On 23 January 2017 at 00:49, Eve Maler wrote:

This message discusses an issue not brought up yet in our meetings. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!)

276 https://github.com/KantaraInitiative/wg-uma/issues/276: Scope string: "friendly name" and "identifier" the same: do they need to be split?

====

In the ad hoc discussion post-UMA telecon 2017-01-19 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19, we had a discussion that I don't think I captured in the notes: While the "name" property for a scope description defines itself (Sec 2.1.1 https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html#act... in RReg 2.0 rev 04) as being a human-readable string, that leaves it without a separate (if desired) machine-readable scope string. In implementations it's been treated primarily as the latter and displayed also as the former, so effectively serving as both.

In the case of resources, these two concepts are naturally split because the AS gives back an identifier. ====

Note that the current "name" property is OPTIONAL, and that this is part of the scope description document that the AS resolves if it's gotten a URI from the RS (keep in mind the email sent earlier today about issue 269!). In this case, the URI could simply have served as the machine-readable name.

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

1. Do nothing. 2. Add a new bit of description to the existing "name" property to say that it's meant to serve as the machine-readable name as well. 3. Add a "scope_id" property of some kind. 4. Change the "name" property to have the machine-readable name semantic, and add a "friendly_name" property of some kind.

====

Here is my proposal: *Option 1*. Rationale:

- I believe it's correct to interpret the URI as the "scope identifier". If we need to say so in the spec, then we can. - The "name" property for a scope has, and should have, the same role as the "name" property for a resource.

*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

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

-- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544