[Openid-specs-ab] Issue #1563: Managing Credentials with changing claim values (openid/connect)

[Tobias Looker]

New issue 1563: Managing Credentials with changing claim values
https://bitbucket.org/openid/connect/issues/1563/managing-credentials-with-changing-claim

Tobias Looker:

With some of the credential formats supported by this protocol and how they are presented downstream to relying parties  
there is the situation where the client \(wallet\) may wish to request multiple "copies" of the same credential so that presentation of them can be managed in a way to limit the possibility of correlation due to elements of the credential that always have to be revealed e.g the issuers signature. mDoc \(or mDL\) is one such example format.

However over time the claims that are contained within a credential may change, e.g a person gets married and chooses to change their last name on their drivers license.

Given the above, the question then becomes how these requirements are solution for within the protocol

One possible solution is that every time a credential is requested via the credential endpoint, the issuer simply issues the credential containing the latest claim values available to it. A client \(or wallet\) then managing multiple copies of the same credential because of the scenario described above would then need to effectively diff or check each credential it receives from the issuer and compare to other copies it has and decide what to do, including potentially informing the user of such a change. The downside of such a solution is that most of the complexity is imposed upon the client and arguably when the client is informed of the change it is too late \(e.g a new credential with new claim values has already been issued\).

Another possible solution is that every time a credential is issued an ID is returned alongside the issued credential in the credential response. This ID's value would only change when information within the credential has changed \(e.g claims, note its to be defined exactly what this information set would be\). How this value is generated and or maintained by the issuer would be entirely at their purview. The client would then be able to use this ID to detect when change in a credential has occured. To ensure the wallet is never sent a credential that contains claims that have changed without its prior knowledge, the credential request could also be extended to support the client \(wallet\) submitting the ID of the credential they are after in their request whereby the server could respond with an error when the credential has changed.

An example credential response \(featuring a credential ID\)

```
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
"id": "9d389vc3u4948vj4",
"format": "jwt_vc"
"credential" : "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
"c_nonce": "fGFF7UkhLa",
"c_nonce_expires_in": 86400
}
```

An example credential request \(featuring a credential ID\)

```
POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

type=https%3A%2F%2Fdid%2Eexample%2Eorg%2FhealthCard
format=ldp%5Fvc
id=9d389vc3u4948vj4
did=did%3Aexample%3Aebfeb1f712ebc6f1c276e12ec21
proof=%7B%22type%22:%22...-ace0-9c5210e16c32%22%7D
```

An example error response when the credential has changed

```
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
"error": "credential_changed"
"error_description":
"The credential requested with ID: 9d389vc3u4948vj4 has changed, to update please re-submit a request without the quoted ID value"
"c_nonce": "8YE9hCnyV2",
"c_nonce_expires_in": 86400
}
```

‌