Add optional name to the Field object in a Presentation Definition

[andorsk]

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:

TBD54566975/ssi-sdk#159

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.

[nklomp]

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

[andorsk]

@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.

[decentralgabe]

@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",
  ...
}

[andorsk]

@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

[decentralgabe]

Gotcha, clearer now. I do think it's a valid property to add.

[nklomp]

Okay that certainly makes it more clear. Not sure whether the proposed name property should mention anything about the schema though.

[andorsk]

I've created a PR with a proposed addition to the spec. I welcome any suggestions/feedback.

[andorsk]

Closing: #360 was merged.