Yep, exactly. Informed consent and all that... J. On 23 January 2017 at 19:02, Eve Maler 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 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