Session transcript definition

[c2bo]

Somewhat related to #8

We need an agreement on and common description of what data should be signed over by the device and what protection guarantees we need.

Historically in OpenID4VP, there was a bit of divergence, where the data being signed over by the Wallet was slightly different between the formats. We should align on a generic definition what exactly we sign over and how that is constructed. SessionTranscript is reconstructed, whereas KB-JWT contained the values and both contain different values (e.g., JwkTumbprint)

SessionTranscript for mDoc (vanilla OpenID4VP):

OpenID4VPHandover = [
"OpenID4VPHandover", ; A fixed identifier for this handover type
OpenID4VPHandoverInfoHash ; A cryptographic hash of OpenID4VPHandoverInfo
]

; Contains the sha-256 hash of OpenID4VPHandoverInfoBytes
OpenID4VPHandoverInfoHash = bstr

; Contains the bytes of OpenID4VPHandoverInfo encoded as CBOR
OpenID4VPHandoverInfoBytes = bstr .cbor OpenID4VPHandoverInfo

OpenID4VPHandoverInfo = [
clientId,
nonce,
jwkThumbprint,
responseUri
] ; Array containing handover parameters

clientId = tstr

nonce = tstr

jwkThumbprint = bstr

responseUri = tstr

This is kb-jwt for SD-JWT VC (vanilla OpenID4VP)

The following is a non-normative example of the unsecured payload of the Key Binding JWT of a Verifiable Presentation.

{
  "nonce": "n-0S6_WzA2Mj",
  "aud": "x509_san_dns:client.example.org",
  "iat": 1709838604,
  "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4"
}

[GarethCOliver]

We also need to decide how to include channel binding. The channel definition is outside the scope of this spec but ideally there would be a simple, encapsulated way to plug this in

[c2bo]

We also need to decide how to include channel binding. The channel definition is outside the scope of this spec but ideally there would be a simple, encapsulated way to plug this in

Agreed, in my mind I'd like to define a common set of values we bind to the device signature and then basically for each format simply describe how exactly that happens.
The decision we probably have to make is if we simply define 1 sessiontranscript for everything and just add that to every credential format into the device signed part, or if the formats define their own data structs.

[leifj]

also agree on some pluggability for channel binding. We already know that dchp will run over at least two transports (nfc+http) and there will probably be more bindings down the line.