PID Credential Configuration Lifecycle
Credential Configurations and Credential Configuration Identifiers
The credential configuration identifier is defined inside the metadata PID Issuer metadata.
Under credential_configurations_supported, there are credential configurations which informs wallets
which credentials are offered by the PID-Provider. Wallets need to pick a credential configuration identifier for which
they want to get their PID-credential issued.
{ /* .. */
"credential_configurations_supported": {
/* .. */
"pid-sd-jwt_2": {
"scope": "pid",
/* ... */
"vct": "urn:eudi:pid:de:1",
"format": "dc+sd-jwt"
},
/* ...* /
}
}
New credential configurations will be added alongside the existing ones, old ones will be removed.
Upcoming new credential configurations which change the PID-credential are added alongside existing ones and the
older ones get deprecated. The version is indicated by an appendix _2 , _3 , etc.
After a grace period, deprecated credential configurations will be removed. The version number itself is technical
and has no particular meaning.
{ /* future credential issuer metadata */
/* ... */
"credential_configurations_supported": {
"pid-sd-jwt_2": { /* ... */ }, /* deprecated configuration, to be removed */
"pid-sd-jwt_3": { /* ... */ }, /* latest configuration of SD JWT VC credential configuration */
"pid-mso-mdoc_2": { /* ... */ }, /* deprecated configuration, to be removed */
"pid-mso-mdoc_3": { /* ... */ } /* latest configuration mso mdoc credential configuration */
}
}
-
These configurations are stable and the PID-credential issued under them does not change, neither technically nor semantically, once they are deployed.
-
There will be at most two stable configurations of each credential type present at the same time. Before a new stable configuration is added, any previous configuration will be removed.
-
Once a new credential configuration is deployed, the previous one is deprecated and will be removed after at a grace period. We can remove credential configuration earlier if needed.
Wallets need to opt in to new credential configurations
Wallets need to pin the credential_configuration_id they support. If they want to use a newer credential
configuration, they need to change their pin to the newer configuration and no longer request the old configuration.
On the development version we will provide previews. They get a version numbers like pid-mso-mdoc_2-beta.
These credential configurations can change any time and must not be relied upon for anything except testing the changes.
After coordination and successful tests, we promote a preview credential configuration to the next stable configuration,
e.g. pid-mso-mdoc_2. This automatically deprecates the previous credential configuration. That configuration
will then be removed according to schedule.
Further information
We do this to decouple PID-Provider development from Wallet development and remove the requirement to do synced rollouts. This means for Wallets:
-
Wallets need to pin the credentials configurations they rely upon.
-
Wallets can opt in when they want to use the new credential configuration. This takes the decision when RPs see the credential from the PID-Provider side to the Wallet side, as Wallets are closer to RPs.
-
There is a grace period to move away from old configurations before they become unavailable. This is needed to limit support effort.
-
Note that usually the vct/doctype values do not change from older to newer credential configurations. These are fixed by the rulebooks, even though the rulebooks are still changing. (But they might change in the future.)
-
Note that also that the semantics of the PID-credential might change between versions: We might change the rules how conversions from the eID to the PID-credential happens.
We expect only a limited number of credentials configurations until the public launch phase of the ecosystem. We expect to have only one credential configuration for each credential type at public launch.