Managing Credentials with changing claim values

[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 solutioned 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
}

‌

[David W Chadwick]

@Tobias Looker There is an alternative solution which has already been proposed in PR#232 (informed consent). Specifically, the issuer does assign an ID to each credential (as in your proposal). This difference is in the request for the credential. The wallet provides the ID (as in your proposal) along with the set of properties that it wants, and the Issuer will issue the credential as requested if it has not changed, but if the properties have changed, the issuer will return an error message (as in your proposal). This protocol has several advantages over yours

i) it prevents correlation because the wallet can ask for a different subset of properties each time, and then the issuer’s signature will be different each time

ii) it can be used to support selective disclosure using existing standard JWT algorithms.

iii) if the credential validity period is short it means that revocation of the credential is not needed

[Tobias Looker]

While I agree there is some overlap I dont think the intent is entirely the same, your PR appears to be more focused on supplying the claims in an un-signed form to the wallet to facilitate some form of consent. Whereas my proposal is really just focused on trying to provide some signal from an AS/OP to a client/wallet for when a credentials contents has changed.

[David W Chadwick]

I think you proposal is a subset of mine. I am proposing

i) the AS/OP tells the wallet what credential it is willing to issue

ii) the wallet tells the AS/OP what subset of properties it wants issuing

iii) if the subset is good, the credential is issued, if the subset is not, then the AS/OP tells the wallet the credential contents have changed.

[Tobias Looker]

Yes I think you’re right and I agree on the subset, but the broader scope of your PR I think is still to complex. Can you clarify further why returning a set of unsigned claims to the wallet is important, the wallet is free to scope the contents of the credential during the credential request, so that can be used to ensure the wallet only gets a credential with the right set of claims in it (as per user consent), the only situation this leaves is that the credential is issued where one of the claim values is different to what the user is expecting (and therefore they dont want it), at that point why can they not just delete the credential? That would to me appear to be a simpler way to solution it?

[David W Chadwick]

There are three issues you raise:

i) the issuer returning a set

ii) the issuer returning an unsigned claim.

iii) the wallet getting a credential with a claim different to what the user was expecting

The answer to i) is related to requesting multiple credentials and is being discussed as a separate issue. So can we not address this one here, since the protocol flow I mentioned above is conceptually independent of whether we are talking about one or several credentials.

The answer to ii) is to address what you wrote “the wallet is free to scope the contents of the credential during the credential request”. Whilst I agree with your statement, upon what basis does the wallet know what the maximum scope is, if the protocol exchange has never had the issuer inform the wallet what this is? So the first message in the exchange allows the issuer to inform the wallet of the maximum scope. There is no other message flow that explicitly defines this in the current spec.

The answer to iii) is more nuanced. If the wallet (acting on behalf of the user) says I want an apple, and the issuer only has an orange, is it more sensible for the issuer to return OK here you are and return an orange or to say sorry, I only have an orange, does the user want that? The user is then consulted by the wallet, and if the user does not want the orange the session completes. If the user does want the orange, a request is now made for the orange. In SSI, where the user is in control, I prefer the latter option. Whilst your proposal has a reduced set of protocol exchanges, the difference is between explicit and implicit user consent. In my protocol the issuer receives explicit consent because the request equals the response. In your proposal the issuer recieves implicit consent for an orange because the user either keeps or throws away the orange, but the issuer does not know which.

[Mark Haine]

This has some commonality with something we are calling “pending verification” in the eKYC & IDA Working Group. We are in the early stage of investigating some sort of implementation that uses some of the Shared Signals and Events specs to send a notification to the RP when claims have been updated by some workflow.

[David W Chadwick]

@Mark There is an existing working solution to your problem which I have already discussed with some banking people, and that is issuing short lived credentials on demand. In this way the wallet only holds the latest information. The time to live is set by the issuer from knowledge it has about the frequency of change and other factors.

[Kristina Yasuda]

suggested to differentiate two points “update data in a credential + getting multiple copies of the credential”

(This comment might be helpful: openid / connect / issues / #1544 - Requesting multiple credentials — Bitbucket)

[Torsten Lodderstedt]

I think we should differentiate in the discussion credential claims update and management of multiple instances of the same credential type.

[Torsten Lodderstedt]

Recap from today’s WG call:

• the issuer provides the wallet with an identifier of the “version” of a certain credential in the issuance response
• if the wallet has previously obtained a credential of the same type and the version identifier in the response is the same, this means both credentials are equivalent content wise.
• this could be further optimised by letting the wallet send the version identifier of its last credential of the same type with the credential request. In this case, the issuer would compare and directly refuse to issue a new copy of the credential if there was no change.

I believe an issuance request binding a credential to fresh key material can never result in an old version identifier.

This use of refresh tokens for refreshing credentials is orthogonal to this idea as it is “just” a mechanism to get a fresh access token to request credentials from the credential endpoint. The wallet could certainly send a version identifier along with such a new access token in the issuance request.

Alternative approach could be to offer another endpoint to query the status of a certain credential (using some sort of id) - feels like OCSP

[Michael Jones]

I observed during the 28-Jul-22 call that for standard OpenID Connect, things are always fresh because you always go to the issuer, whereas when there’s a holder, things can get stale while being held. So this matters more for OpenID4VC than it did for Connect.

[Kristina Yasuda]

Introducing id (or whatever it’s called) would be a good idea because I think it is simpler than other alternatives 1/ the Wallet sending the entire credential when it is unsure whether it has the latest version - where the Issuer will have to do process the entire credential, or 2/ adding version property to the credentials, which is super hard to enforce across all credential formats/types.

[Kristina Yasuda]

I think a complimentary mechanims is requested in the issue #1639, where the issuer can communicate to the wallet that the wallet needs to keep sending credential request to the issuer (with the id claim introduced in this issue).

[Kristina Yasuda]

might make sense if the issuer has a way to tell id to the wallet out of band, so that the wallet can check if it is the version it has and ask for reissuance if it does not match to the id value that the wallet already has

[Tobias Looker]

Revisiting this issue with more context, I believe some key requirements/observations for the protocol are

1. The wallet should be able to determine whether two issued credentials of the same type for the same user from the same issuer are equivalent in terms of the information represented within them (e.g the claims)
2. The issuer is the best party to determine whether two issued credentials meeting the criteria above are equivalent

What remains yet to be defined more precisely is what constitutes different between two issued credentials OR would we take the approach that it is entirely under the issuers per view to decide this, personally I’m leaning to this model.

Given the observations above there are a couple of other possible requirements I believe we need to decide whether the protocol needs

1. The wallet must be able to query the issuer about whether there are any updates or a new version available for a credential that has been issued
2. The wallet must be able to request issuance of a credential for a particular version, this doesn’t however mean the issuer would honour this request, but it would provide the wallet with the ability to manage credentials with changing versions, e.g not be forced to receive a credential with a new version.

‌

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI