Yep, exactly. Informed consent and all that... J. On 23 January 2017 at 19:02, Eve Maler <eve@xmlgrrl.com> wrote:
So, just checking, you see less value in a resource long-form description field, but see more value in a scope long-form description field? ("option
*3<<* or 4")
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Mon, Jan 23, 2017 at 2:00 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:
I'd go for either option 3 or 4.
i18n for scope descriptions should be handled by the request to the scope description document, so there shouldn't be any need to have arrays for name/description fields in my opinion.
J.
On 22 January 2017 at 22:55, Eve Maler <eve@xmlgrrl.com> 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> :
==== *271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: Add description fields to resource description doc and scope description doc:* ... Resource description docs don't need I18N/L10N, but scope description documents might, for both a friendly name field and a description field. If we added a description field to scopes, then, do we want to make a breaking change and make this an array? Or leave the name as a default name that never changes and add an intl_name field or something like that? Or not care at all about I18N/L10N, but then possibly break things in future? ====
Here are the options I can think of. (Let me know if I missed any.)
1. Do nothing. Others can always add their own extension for this. 2. Add a "description" property for the resource description document only. 3. Add a "description" property for the scope description document only. 4. Add a "description" property for both the resource description document and the scope description document. 5. (Not mutually exclusive with options 2, 3, or 4:) Add an internationalization/localization way for description values, likely modeled on the OIDC "claim request hash trick".
====
Here is my proposal: *Option 1*. Rationale:
- A description field is pretty much a natural adjunct to a short name string. However, the interop cost is low if others add their own description fields. They might need multiple descriptions for different purposes. A display name seems like minimal bootstrapping, whereas descriptions may be gilding the lily. - I don't feel that strongly about it, however, and could be convinced by *Option 2 or 4* (but I'm not crazy about Option 5, as detailed in the issue 269 email).
*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