Credential update User Flow
# Credential updates
## Triggering a credential update from the issuer / server side
Example features / cases
1. The user holds a health insurance card credential. This credential lists their current address. After the user has moved (and informed their health insurance provider), they would like to receive a new Credential of the exact same type and structure, with one updated field.
2. A freshman in university receives a set of credentials at the start of each year allowing them to open various doors on campus. After one year has passed (and a bunch of doors were moved around, removed or added), the UNI administration would like to issue a new set of credentials, and revoke the old authorizations. In this case the new credential set might be different (e.g. in structure) from the original offer.
3. An issuer has rotated their signing keys, and they need to issue updated versions of all creds they issued (but signed with the new keys).
## First issuance
```plantuml
@startuml
autonumber
participant "User"
participant "SmartWallet"
participant "SSI Issuer"
participant "Trust Anchor (VDR)"
"SSI Issuer" -> "SSI Issuer":** Define / assemble offer (settle on credentials, replacement ID, formats.)**
"SSI Issuer" -> "SmartWallet": Generate and present "Issuance Invitation" QR code
"SmartWallet" <-> "Trust Anchor (VDR)": Resolve issuer DID, retrieve key material, additional metadata
group Invitation phase
"SmartWallet" -> "SSI Issuer": Send //Propose Credential// message
"SSI Issuer" -> "SmartWallet": **Respond with //Offer Credentials// message, including replacement identifier**
end
"SmartWallet" -> "SmartWallet": **Query the SDK for existing credentials with associated replacement identifier (none returned)**
"SmartWallet" -> "User": Present a summary of the credential offer
"User" -> "SmartWallet": Accept the offered credentials
"SmartWallet" -> "SSI Issuer": //Send Credential Application// message
"SSI Issuer" -> "SmartWallet": Respond with //Issue Credentials// message. Includes issued Verifiable Credentials.
"SmartWallet" -> "SmartWallet": Store the issued credentials, as well as the associated replacement ID
"SmartWallet" -> "SSI Issuer": Send //Acknowledgement// message accepting the credentials.
@enduml
```
Some notes:
1. The `replacement_id` property is defined by the issuer, and assumed to be static / human readable, examples including: "*onboarding_credentials*", "def_auth_l0_ro", "CCNA_cert_22", etc.
2. The repacement ID would be specified / defined when creating a credential template.
3. If the issuer wants to update the contents of the issued credentials, they can reuse the same template, with different claims.
4. If the issuer wants to replace the issued VCs with a new set of (perhaps entirely different) VCs, they can define a new credential template with the same replacement ID.
## Subsequent update issuance
```plantuml
@startuml
autonumber
participant "User"
participant "SmartWallet"
participant "SSI Issuer"
participant "Trust Anchor (VDR)"
"SSI Issuer" --> "SSI Issuer": **(Optional) Modify the issuance template**
"SSI Issuer" -> "SmartWallet": Generate and present "Issuance Invitation" QR code
"SmartWallet" <-> "Trust Anchor (VDR)": Resolve issuer DID, retrieve key material, additional metadata
group Invitation phase
"SmartWallet" -> "SSI Issuer": Send //Propose Credential// message
"SSI Issuer" -> "SmartWallet": **Respond with //Offer Credentials// message, including replacement identifier**
end
"SmartWallet" -> "SmartWallet": **Query the SDK for existing credentials with associated replacement identifier** (returns interaction summary, including a set of credential identifiers)
"SmartWallet" -> "User": **Present a summary of the credential offer, listing the credentials which would be updated as part of the process**
"User" -> "SmartWallet": Accept the offered credentials
"SmartWallet" -> "SSI Issuer": //Send Credential Application// message
"SSI Issuer" -> "SmartWallet": Respond with //Issue Credentials// message. Includes issued Verifiable Credentials.
"SSI Issuer" -> "SSI Issuer": **Revoke the old / outdated credentials**
"SmartWallet" -> "SmartWallet": Store the issued credentials, as well as the associated replacement ID
"SmartWallet" -> "SmartWallet": **Remove the old / outdated credentials**
"SmartWallet" -> "SSI Issuer": Send //Acknowledgement// message accepting the credentials.
@enduml
```
### Areas of work on the SDK side
1. Expose the `replacement_id` property as an argument to create_offer
2. Method to query issuance state by replacement_id
3. Update issuance flow implementation to automatically handle deletion (holder side) and revocation (issuer side) of updated credentials upon offer acceptance.
# Selective disclosure
Context from presentation exchange:
General make-out of the request message is defined [here](https://identity.foundation/presentation-exchange/spec/v1.0.0/#term:presentation-definitions) and illustrated (on a very high level), [here](https://excalidraw.com/#json=o_Tm5u_x-xZUZdrysPeEi,PNid02m3n4LfUcAk7AGtLg).
> The constraints object MAY contain a `limit_disclosure` property. If present, its value MUST be one the following strings:
>
> required - This indicates that the processing entity MUST limit submitted fields to those listed in the fields array (if present).
>
> preferred - This indicates that the processing entity SHOULD limit submitted fields to those listed in the fields array (if present).
>
> omission of the limit_disclosure property indicates the processing entity MAY submit a response that contains more than the data described in the fields array.
In case the verifier requests full credentials (no selective disclosure):
1. SDK processess the request, and provides the wallet with a set of credential identifiers which satisfy the requirements
2. The Wallet prompts the user to select one of the matching credentials for presentation.
3. The wallet assembles a presentation message and sends it to the verifier
In case the verifier sets `limit_disclosure` to `required`:
1. SDK processess the request, and provides the wallet with a set of credential identifiers which satisfy the requirements and support selective disclosure
2. The Wallet prompts the user to select one of the matching credentials for presentation.
3. A selective disclosure presentation is automatically generated based on the selected credential.
4. The wallet assembles a presentation message and sends it to the verifier
In case the verifier sets `limit_disclosure` to `preferred`:
1. SDK processess the request, and provides the wallet with a set of credential identifiers which satisfy the requirements and support selective disclosure
1. If credentials are found they are returned for user selection
2. If no matching credentials are found, the SDK will attempt to find credentials which satisfy the constraints but do not support selective disclosure, and return them for user selection
2. The Wallet prompts the user to select one of the matching credentials for presentation.
3. A selective disclosure presentation is automatically generated based on the selected credential.
4. The wallet assembles a presentation message and sends it to the verifier
**Assumption / imposed constraints:**
1. A request for credentials can combine a selective disclosure request, as well as a regular request. E.g. a verifier could ask for our full `Library Card` credential, as well as a seletive disclosure presentation of our `Name` from our ID Card credential. All as part of one request (QR Code).
2. A selective disclosure presentation is created from one credential only
1. Specifically, providing one field from one credential and another field from a different credential is **out of scope at this stage**. Potential UB can occur in case the issuers are different, the credentials are bound to different personas (or DIDs).
**Open questions:**
1. Do we want to allow the user to submit more data than requested (e.g. in case the `limit_disclosure` is missing or set to `preferred`)?
1. provisional answer -- no (?)
Sign in with Wallet
Connect another wallet