276: Scope string: "friendly name" and "identifier" the same: do they need to be split?
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#action-desc> 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
+1 Option 1 and +1 saying so in the spec. On 23 January 2017 at 00:49, Eve Maler <eve@xmlgrrl.com> 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#action-desc> 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
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 | 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 <eve@xmlgrrl.com> 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#action-desc> 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
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 <eve@xmlgrrl.com> 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 <eve@xmlgrrl.com> 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#action-desc> 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
participants (3)
-
Eve Maler -
George Fletcher -
James Phillpotts