Add display texts for credential status values to credential_metadata
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 125
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
The current specification allows to provide user displayable texts (labels) for the credential at the level of the credential itself and individual claims.
One important part, that is missing, is a way to provide displayable texts for credential status values.
This can be important for example in the following case:
A driving license can be valid or revoked. The revocation can be permanent or temporary. In addition, a reiussance may be necessary, when the data in the register has been updated. Simply revoking the driving license using a valid/invalid status is not enough in this case, but it is necessary to provide this information to the verifier. Thus three status values 0,1,2,3 can be used in a Token Status List.
If this is done the wallet has no way to know or indicate to the user, why the credential is revoked and thus in addition, not know which status means, that the credential is in fact invalid. The user will just see the value valid or invalid or the status 0,1,2,3, depending on the wallet implementation.
It is thus necessary to add display texts for the individual status values. Because the Token Status List does not handle any UI related parts, this information should be provided as part of OpenID for VCI or as part of credential format specific metadata. Because VCI defines default metadata, that can be used for all credentials, this should be added at least here in this standard.
Exact requirements:
The specification should allow to specify a display text for each of the status values that can be used by the status lists referenced in a credential in multiple languages. This value can be used by the wallet to display the credential status to the user.
Suggestion:
The regular claims object inside the credential_metadata is not suitable, because the status values are not referencable by a path. Only the status claim itself can be referenced. Thus, a new structure is needed.
The following should be added as an object inside of credential_metadata.display:
status: OPTIONAL. The status parameter specifies a JSON Object that contains display texts for the status mechanism used by the credential. The name of the properties in this object MUST match the names of the status mechanism value used to transport the status information inside of a credential as registered in the IANA "JWT Status Mechanisms registry established by Token Status List. This specification defines a mechanism to provide display properties for the Token Status List. Additional mechanisms can be added by other specifications.status_list: OPTIONAL. The status_list parameter specifies a JSON Array that contains display texts for the status values used by the Token Status Lists that are referenced in the credential. Each element of the JSON Array is a JSON Object with the following properties:status_value: REQUIRED. A JSON Number with the value of the status this object applies to. There MUST be only one object for each combination of language identifier and status_value.name: REQUIRED: A JSON String with the displayable name for the combination of language identifier and status_value.locale: OPTIONAL. A JSON String value that identifies the language this object applies to, represented as a language tag taken from values defined in BCP47 [RFC5646]. There MUST be only one object for each combination of language identifier and status_value.description: OPTIONAL: A longer description for the combination of language identifier and status_value. This can be used to provide the user with additional information on what the status means and what to do.
Adding this below credential_metadata directly, maybe named status_display could be suitable as well.
Example:
With the scenario above the following credential_metadata.display object could be defined by the issuer:
{
"display": {
"status": {
"status_list": [
{
"status_value": 0,
"name": "Gültig"
},
{
"status_value": 1,
"name": "Eingezogen (Permanent)",
"description": "Das Dokument wurde dauerhaft eingezogen."
},
{
"status_value": 2,
"name": "Eingezogen (Temporär)",
"description": "Das Dokument wurde temporär Eingezogen."
},
{
"status_value": 3,
"name": "Ungültig (Datenänderung)",
"description": "Bitte stellen Sie sich unter https://behorde.example.com/issue-driving-license eine neue Kopie aus"
},
{
"status_value": 0,
"name": "Valid",
"locale": "EN-US"
},
{
"status_value": 1,
"name": "Revoked (permanently)",
"locale": "EN-US",
"description": "The document has been revoked permanently."
},
{
"status_value": 2,
"name": "Revoked (temporarily)",
"locale": "EN-US",
"description": "The document is temporarily revoked."
},
{
"status_value": 3,
"name": "Invalid (Data changed)",
"locale": "EN-US",
"description": "Please request a new copy at https://behorde.example.com/issue-driving-license"
}
]
}
}
}
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the credential_metadata.display requirements and the Token Status List status mechanisms referenced in the issue. Review how OpenID for VCI defines default metadata and determine how status values and language identifiers should be represented. Done means the specification defines display names and optional descriptions for each status value across supported locales.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100