Skip to content

Session transcript definition #10

Description

@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"
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions