During our work we came up with various solutions which are not suitable any longer. This file contains all deprecated ideas and solutions for others to read about.
The DIDComm Token solution is the currently prefered solution. Others can be found in the deprecated Versions.
| DID JWT (without Deferred Credential Endpoint) |
DID JWT with Deferred Credential Endpoint | DID JWT with Deferred Credential Endpoint as fallback (mixed) | Separate DIDComm | DIDComm Token | |
|---|---|---|---|---|---|
| Support of both flows (Authorization and Pre-Authorized) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Enforced DIDComm Channel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Optional DIDComm Channel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| No DIDComm Channel (plain OpenID4VC) |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| DIDComm channel creation | Between Credential Request and Credential Response | After Credential Response (deferral) | Between Credential Request and Credential Response OR after Credential Response (deferral) | After Token Response and before Credential Request | After Token Response and before Credential Request |
| DIDComm Delay/Timeout handling | ❌ - delay Credential Response or abort with Credential Response Error | ✔️ - Credential Response (deferral) is sent immediately | ✔️ - Credential Response (deferral) is sent immediately | ✔️ - DIDComm is separate | ✔️ - DIDComm is separate |
| DIDComm Initiator | Issuer | Issuer | Issuer | Holder | Holder |
| Message modification | Credential Request: Body (Header possible) | Credential Request: Body (Header possible) | Credential Request: Body (Header possible) | Credential Request: Header | Access Token: Scope extended |
| Session correlation | DID JWT in Credential Request + DIDComm Ping with Nonce |
DID JWT in Credential Request + DIDComm Ping with Nonce |
DID JWT in Credential Request + DIDComm Ping with Nonce |
DIDComm Ping with Correlation ID + DIDComm Acknowledge and Credential Request with one-time-code |
DIDComm Ping with Access Token |
This solution utilizes "Self Issued Identity Providers" (SIOP) to pass the Wallet's DID to the Issuer.
Required:
- Solution established additional DIDComm channel
- Solution supports both flows
- Solution enforces DIDComm channel
- Solution doesn't modify existing OID specs
Optional:
- Solution supports usage of different DIDs
Reasons for deprecation:
- usage of two distinct OpenID-flows resulting in an overhead
- more synchronisation of states needed
DID JWT with or without Deferred Credential Endpoint/DID JWT with Deferred Credential Endpoint as fallback (mixed)
Each of these solutions utilizes "JSON Web Tokens" to pass a DID in the credential request and at the same time proving possession of the key material.
Required:
- Solution established additional DIDComm channel
- Solution supports both flows
- Solution enforces DIDComm channel
- Solution doesn't modify existing OID specs
Optional:
- Solution supports usage of different DIDs
In order to prevent timeout related problems it is possible to use the Deferred Credential Endpoint preferred as a fallback solution.
These solutions could also be applied to OID4VP.
Reasons for deprecation:
- usage of tokes preferred
- need to pass a DIDComm proof manually
It is also possible to create a separate DIDComm connection parallel to the usual (pre-)authorized flow. This solution uses one-time-codes or pseudorandom numbers in order to synchronize the DIDComm Connection.
Reasons for deprecation:
- overhead due to usage of a one time code
- security concerns