A few thoughts about the option "separate DidComm"

[rkxx]

OID4VCI uses OAUTH2 to authorize the wallet (oauth2 client) to request and receive an credential. Why not using the same mechanism to authorize the wallet to establish the separate didcomm connection to the credential issuer for future communication?

The credential for which the wallet requests authorization is specified either by

• an authorization_details object (according to OAuth 2.0 Rich Authorization Requests):

  [
   {
      "type": "openid_credential",
      "format": "jwt_vc_json",
      "credential_definition": {
         "type": [
            "VerifiableCredential",
            "UniversityDegreeCredential"
         ]
      }
   }
]

• or a scope value (according to The OAuth 2.0 Authorization Framework):

scope=UniversityDegreeCredential 

Authorizing the establishing of the didcomm connection would only require to add a authorization_detail or scope value, respectively:

• authorization_details object:

  [
   {
      "type": "openid_credential",
      "format": "jwt_vc_json",
      "credential_definition": {
         "type": [
            "VerifiableCredential",
            "UniversityDegreeCredential"
         ]
      }
   },
   {
      "type": "didcomm"
   }
]

• scope:

scope=UniversityDegreeCredential DidComm 

The resulting message flow to establish a separate DIDComm connection would be:

sequenceDiagram
    autonumber
rect rgba(0, 0, 0, .1)
Note right of User: Oauth2 authorization of didcomm connection establishment and credential exchange 
    User->>Wallet: interacts
    Wallet->>Credential Issuer: Obtains Issuer's Credential Issuer metadata
    Wallet->>Credential Issuer: Authorization Request(scope = UniversityDegreeCredential DidComm) 
Credential Issuer->User: Authentication/Consent
    Note over User, Credential Issuer: The Credential issuer acting as Authorization server authenticates the users and <br/>retrieves user consent to authorize the wallet:<br/>* to establish a didcomm connection to the credential issuer and<br/>* to request and retrieve a specific credential from the credential issuer
Credential Issuer->>Wallet: Authorization Response (code)
Wallet->>Credential Issuer: Token Request(code)
Credential Issuer->>Wallet: Token Response(access_token)
end
rect rgba(0, 0, 0, .1)
Note right of Wallet: didcomm connection establishment 
Wallet->>Credential Issuer: didcomm ping(access_token)
Credential Issuer->>Wallet: didcomm ackn()
end
rect rgba(0, 0, 0, .1)
Note right of Wallet: Credential exchange 
Wallet->>Credential Issuer: Credential Request (access_token, proof(s))
Credential Issuer->>Wallet: Credential Response (credential(s) OR transaction_id)
end

Loading

Please note that there are only minor extensions to the original OID4VCI flow:

• step 4 extends the scope of the access_token by adding the additonal scope value DidComm
• step 8 and 9 are added to establish the didcomm connection

The OIDC4VCI protocol is not affected at all.
In step 10 the issuer can correlate the credential request to the established didcomm connection by the access_token.

A few additional thoughts: If we establish the didcomm connection to the credential issuer for future communication (e.g. revocation notice, re-issuing of credential, ...) why not allow to use the established connection for the initial credential exchange? This would simplify the message flow even further:

sequenceDiagram
    autonumber
rect rgba(0, 0, 0, .1)
Note right of User: Oauth2 authorization of didcomm connection establishment and credential exchange 
    User->>Wallet: interacts
    Wallet->>Credential Issuer: Obtains Issuer's Credential Issuer metadata
    Wallet->>Credential Issuer: Authorization Request(scope = UniversityDegreeCredential DidComm) 
Credential Issuer->User: Authentication/Consent
    Note over User, Credential Issuer: The Credential issuer acting as Authorization server authenticates the users and <br/>retrieves user consent to authorize the wallet:<br/>* to establish a didcomm connection to the credential issuer and<br/>* to request and retrieve a specific credential from the credential issuer
Credential Issuer->>Wallet: Authorization Response (code)
Wallet->>Credential Issuer: Token Request(code)
Credential Issuer->>Wallet: Token Response(access_token)
end
rect rgba(0, 0, 0, .1)
Note right of Wallet: didcomm connection establishment and credential exchange
Wallet->>Credential Issuer: didcomm (Credential Request (access_token, proof(s)))
Credential Issuer->>Wallet: Credential Response (credential(s))
end

Loading

In case HTTPS or Websockets are used as didcomm transport the authorization header of the initial POST Request could carry the access_token authorizing the establishing of the DidComm connection and the request of the credential.

POST /didcomm HTTP/1.1
Host: credentialissuer.com
Authorization: Bearer ENDHDZTRC