Enable automatic update of Verifiable Credentials

[Daniel McGrogan]

A definition of how the wallet should automatically get refreshed or updated Verifiable Credentials would be useful for many business processes. For example an office access credentials which need to be refreshed on a daily basis. In this case we don't want the end user to need to scan the same QR code every day or multiple QR codes multiple times a day. Once the relationship has been established the wallet would continue to receive the latest VC without demanding any interaction.

This could be accomplished by pushing the credentials from the issuer to the wallet or having the wallet call directly to the issuer for the latest credential. They are not mutually exclusive options. The former can provide lower latency horizontally scalable solution as well as better user experience and the latter drives no additional availability requirements to the wallet client.

This handling has already been defined in other openid.net specs, see: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.5

An inclusion like of the ‘Poll, Ping, and Push Modes’ style addition would unlock rich issuance use cases.

[Daniel McGrogan]

For an asynchronous push model the wallet DID has a highly available resource (see diddoc service) which can be reached by the resource server. The protocol for interacting with the service should be defined as part of that service interface e.g. VC over webhooks, ftp, decentralised web nodes, smtp etc.

[Daniel McGrogan]

For wallet triggered refresh (scheduled/poll based). This may or may not want to be related to the Auth Token -> Refresh Token lifecycle, e.g. the wallet continues to seek refresh tokens for an AS, when a credential in its wallet is expired or revoked it invokes the credential endpoint with the current refresh token. It could also be related to the http response types of the credential endpoint e.g. http 206

[Kristina Yasuda]

I think this is a complimentary discussion with Issue #1563, where we agreed to add an optional id claim for facilitate credential version tracking for the issuer. I think this issue is asking for a compliementary mechanism how does the issuer communicate to the wallet that it needs to keep sending credential request to the issuer (with id claim). cc: @Tobias Looker

[Kristina Yasuda]

editors agree to add implementation considerations on credential refresh: 1/ use Access/Refresh token; 2/ reissue credential entirely (let’s say refresh token has a set lifetime, while wallet want to be able to refresh anytime)

[Kristina Yasuda]

SIOP call 2023-04-07 First step to address this is to write an implementation considerations around how wallet can use access/refresh tokens to automatically refresh credentials

security considerations - access tokens are powerful and should be sender constrained. (needs new issue)

[Kristina Yasuda]

PR #533

[Kristina Yasuda]

PR merged