@bparees a few questions:

1. where do you see the random password being generated?
2. why do you think it is important for the user to know that a random password will be generated?

@avade we have a broker which, among other services it offers, can provision databases for users. The password is generated(if necessary), effectively, by the broker (really it happens a bit downstream from the broker).

As part of that, we have a password parameter that will be used as the password for the created database.

We want to allow users to supply their own password if they want, but we also want to generate one for them if they don't care what the password is. So it's useful for our service catalog UI to be able to present to the user "here's a password parameter, you can supply a value but if you don't, one will be generated for you." It's important for the user to know because it allows them to understand the implications of leaving the password field blank (otherwise they might assume leaving it blank means their DB will be unprotected).

You could just add the password field to the schema, do not set required to be true, and then use the "description" key to explain that?

There are nicer things the UI can do w/ the field(in terms of displaying+validating it) if it knows the parameter is generated, rather than relying on the parameter description to mention that the field is generated. It also requires template authors(our serviceclasses are defined by openshift templates) to explicitly mention that, vs automatically getting the behavior when they write templates. Here's an example of what is feeding the parameters in our serviceclasses:
https://github.com/openshift/library/blob/master/official/django/templates/django-psql-example.json#L459-L464

so everyone who writes one of these templates w/ a generated parameter would have to mention in the description that the parameter is/can be generated. Or we'd have to tack our own message onto the author provided description which may or may not end up being redundant to what the template author already put in the description.

So yeah, it's an option, but realistically we're going to do something better in terms of what our broker sends back, so our UI can consume it (since the format of the broker parameter definition is just jsonschema so my understanding is we can extend it in whatever way we choose). This is more a question of whether that "something better" is interesting enough to the community to try to agree on a common mechanism.

We have definitely heard of multiple use cases for adding additional keywords to the spec (for example, adding "sensitive": true for password fields).

JSON schema allows for these arbitrary keywords, but we would definitely like to add any common and consistent use cases to a future version of the specification. In CF, we will be using JSON schema core to generate UIs for now and using the description fields to detail any important contextual information.

It would be great if we could keep this thread open and if everyone in the community could add their use cases to this, and +1 any use cases that have already been listed that you have come across. I'd like to find out how many people are encountering these issues so we can prioritise accordingly.

Outstanding issues:

• Sensitive fields: UIs will want to show that fields containing sensitive values (ie. passwords) may be set, although brokers will never return the values for these (see Fetching current input parameters values (for a service or a binding) #159).
• Auto-generated fields: UIs will want to show that some fields, if left blank, will be automatically generated by the platform.

Nobody added use cases to this, so closing due to inactivity. Please reopen if this is still a problem for anyone!