Add boolean isSecret metadata attribute?

[chrisdostert]

It would be fantastic to have an optional "isSecret" metadata attribute similar to "description" and "title", which was a boolean.

The intent for the instance of that schema would then be captured by the schema and consumers of said schema could then handle this in their own way.

[chrisdostert]

just had an interesting thought; this attribute along with "default" are somewhat useless depending on use case.

If the schema is being used for object validation they don't apply; if the schema is being used for object creation or presentation (such as form display) they do apply.

[awwright]

Can you please provide a description and use case?

…

On Feb 11, 2017 14:18, "Chris Dostert" ***@***.***> wrote: just had an interesting though; this attribute along with "default" are somewhat useless depending on use case. If the schema is being used for object validation they don't apply; if the schema is being used for object creation or presentation (such as form display) they do apply. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatDWAn4BX5VyFHKN82AZNq2q7lAaY4ks5rbiWLgaJpZM4L-Rgv> .

[chrisdostert]

One example use case is in the swagger spec.
They have defined a custom type "password" to "Hint UIs the input needs to be obscured".

possible description:
This keyword can be used to indicate instances of the schema are secret. It is RECOMMENDED that implementations keep the instance secret, the meaning of which will be application specific. As a common example, a UI may hide characters of a string as a user types it.

[handrews]

@chrisdostert if this is primarily presentation-oriented (hiding the characters of the string) then I think it would belong with #67 JSON UI Schema.

Another possible use would be in hyper-schema to indicate that an "isSecret": true field should only be transmitted via a secure protocol. But then, the URI scheme usually handles that so it's not clear to me that it's really useful in hyper-schema.

I'd probably lean towards putting this in the proposed UI Schema vocabulary.

As for "default", see #204.

[handrews]

I've warmed to this proposal given how we've reorganized the annotation keywords during this draft.

I'd probably call it secret to match readOnly (because it's not isReadOnly)

This keyword, in a hyper-schema context, would generally mean that while it is usable in requests, it would never be present in responses. That, plus the UI usage, provides use cases in two separate vocabularies, which I think is a good way to answer the question, "is this useful?"

[handrews]

Merged #433 adding writeOnly, and json-schema-org/json-schema-vocabularies#6 tracks the remainder of the secret proposal.