Add optional `name` to the `Field` object in a Presentation Definition
andorsk opened this issue ยท 8 comments
According to https://identity.foundation/presentation-exchange/#input-descriptor, a constraint field may contain the following properties; path, id, purpose, and filter
with the path
being the only required property. I would like to propose an additional property name
to be added into the fields
description.
A proposal of a complete description would be:
The Field MAY contain a name property. if present, its value SHOULD be a human-friendly name that describes what the target schema represents.
I have added an example of the update to TBD's ssi-sdk here:
Rationale: The use of this is that field provides a human friendly name of the field, which is not available via. purpose or id
. This may provide better context for various interactions with the exchange layer.
If this is agreed upon as a valid additional field, I would be happy to add a PR with the changes included.
You mean that it describes the optional 'filter' property?
I think it is a bit confusing. It might make more sense to move the current field into an object with a name and schema then.
That does bring work for any current implementation though
@nklomp thanks for the response. I'm not sure though why Purpose
and ID
be reasonable to put at the same level as Filter
, to describe the Field
object, but Name
would add complications? Adding name at an equal level to Purpose
and ID
seems to be more consistent with the current spec.
That being said: My specific use case is I need an easier human readable name for field within a Presentation Definition. As long as it accomplishes this, I am fine with it landing in some object instead.
@andorsk would it be possible to use either the id
or purpose
fields as your human readable names? like..
{
"id": "person-credential-1",
"purpose": "Credential for a Person",
...
}
@decentralgabe that relies on you having control over the Presentation Request's definitions, which may not always be the case. In my use case, I am rendering PR's, which I do not expect to control all the time. I need the name
field to make the render human readable.
Also, id
by definition needs to be unique, whereas name could be non-unique. An example could be where you ask for the first name and last name of multiple people in the same PR. I may want to have a human readable field that's consitent First Name
but 2 different ids first-name-person-1
and first-name-person-2
. Purpose could in theory work, but it's specified to be purpose of the field, which is different than a friendly name and so implementing purpose
as name
is a workaround, not a solution IMO
toy example:
id: first-name-person-1
name: First Name
purpose: the first name is required to register you with the organization
--------------
id: first-name-person-2
name: First Name
purpose: the first name is required to register your partner with the organization
Gotcha, clearer now. I do think it's a valid property to add.
Okay that certainly makes it more clear. Not sure whether the proposed name property should mention anything about the schema though.
I've created a PR with a proposed addition to the spec. I welcome any suggestions/feedback.