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 | Skype: xmlgrrl | Twitter: @xmlgrrl