Local signing with wallet

[ThierryThevenet]

local_signature_light.md

[hawkbee1]

Wallet-Local Document Signing over OID4VP

Draft 0.2
8th of July 2026

1. Introduction

This document describes a simplified document signing flow using OpenID for Verifiable Presentations (OID4VP) where the wallet itself produces the document signature.

The design is inspired by the pattern described in CSC Data Model Bindings v1.0.0 – Section 6.2, where a signature request is transported inside an OpenID interaction.
However, unlike the CSC model, this document describes a scenario where the wallet creates the signature locally, instead of delegating signature creation to a remote Qualified Trust Service Provider (QTSP).

This specification defines a technical profile that can be used to produce wallet-based signatures that may qualify as Advanced Electronic Signatures depending on the applicable legal framework.

This specification uses the following standards:

CSC Data Model v1.0.0
OIDC4VP Draft 23
SD-JWT VC Draft 15
RFC 9901

2. Architecture Overview

The signature flow follows the pattern:

Relying Party
│
OID4VP Authorization Request
(transaction_data = signature request)
│
Wallet
│
User consent
│
Wallet signs document digest locally
│
OID4VP Authorization Response
(vp_token containing KB-JWT binding)
│
Relying Party verifies signature

3. Signature Request

The RP sends a signature request through the transaction_data parameter of the OID4VP authorization request.

The request contains the document hash and metadata.

Fields

Field	Description
type	Identifier for wallet signing
documentDigest	Hash of the document
documentInfo	Human-readable document information
signatureFormat	Requested signature format

4. Signature Request Example

localSignRequest

{
  "type": "urn:wallet:local:signature",
  "credential_ids": [
    "proof_of_email"
  ],
  "signatureRequests": [
    {
      "label": "Terms abd Conditions",
      "access": { 
        "type": "public" 
      },
      "href": "https://public.rp-cdn.example/terms-and-conditions.txt",
      "documentDigest": "sha256-HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
      "signature_format": "jws-detached",
      "signAlgo": "1.2.840.10045.4.3.2"
    }
  ]
}

NB : 1.2.840.10045.4.3.2 is for ES256 signature

5. OID4VP Authorization Request Example

PEX format

{
  "client_id": "https://rp.example/verifier",
  "response_uri": "https://rp.example/callback",
  "response_type": "vp_token",
  "response_mode": "direct_post",
  "nonce": "n-0S6_WzA2Mj",
  "presentation_definition": {
    "id": "proof_of_email",
    "input_descriptors": [
      {
        "id": "proof_of_email_request",
        "format": {
          "vc+sd-jwt": {
            "sd-jwt_alg_values": [
                "ES256",
            ],
            "kb-jwt_alg_values": [
                "ES256",
            ]
          }
        },
        "constraints": {
          "limit_disclosure": "required",
          "fields": [
            {
              "path": [
                  "$.email"
              ]
            }
          ]
        }
      }
    ]
  },
  "transaction_data": [
    "BASE64URL_ENCODED_localSignRequest"
  ]
}

6. Wallet Processing

When the wallet receives the request it must:

1. Decode transaction_data
2. Verify the request type
3. Display document information
4. Ask the user for approval
5. Optionally present credentials
6. Sign the document digest
7. Return the signature in the response

7. Wallet Rendering

For text/plain documents, the wallet SHOULD render the signing request in a human-readable form and require an explicit user action before generating the signature.

The wallet rendering SHOULD include:

• the identity of the relying party
• the document title
• the document MIME type
• a readable preview of the document content, when available
• the document digest algorithm
• the document digest value, or at least a truncated representation
• the signature format to be produced

If the full document content is available to the wallet, the wallet SHOULD display a preview of the text before the user confirms the operation.

The wallet may render the request as follows:

Sign document

Relying Party: rp.example
Document: Terms and Conditions
Format: text/plain
Signature format: jws-detached

Preview:

This employment contract is entered into between ...
The employee agrees to ...
The employer agrees to ...

8. Document Signature

In this profile the wallet produces a reusable signature of the document.

The signature is generated directly over the document digest and is independent of the OID4VP interaction.
This allows the document signature to be stored or reused outside the OID4VP flow.

The wallet uses the wallet key to produce a detached JWS signature based on the documentdDigest.

9. Binding the Signature to the OID4VP Transaction

To bind the document signature to the OID4VP presentation, the wallet includes the signature in the Key Binding JWT (KB-JWT).

The KB-JWT payload follows the SD-JWT specification and includes the required fields:

• nonce
• aud
• iat
• sd_hash

An additional claim document_signature is included to bind the document signature to the transaction.

Example KB-JWT payload:

{
  "nonce": "n-0S6_WzA2Mj",
  "aud": "https://verifier.example.org",
  "iat": 1748537244,
  "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY",
  "document_signature": {
    "format": "jws-detached",
    "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6IndhbGxldC1rZXktMSJ9..MEYCIQDexample",
    "documentDigest": "sha256-HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0="
  }
}

The KB-JWT is then signed by the wallet using its P-256 key (ES256), producing the final Key Binding JWT.

This provides a cryptographic binding between:

• the wallet presentation
• the verifier request
• the document signature.

10. Wallet Response

The wallet returns a standard OID4VP response.

Example response:

{
  "vp_token": "<SD-JWT~disclosures~kb-jwt>",
  "presentation_submission": {...}
}

The vp_token structure is:

SD-JWT ~ disclosures ~ KB-JWT

The KB-JWT payload includes the document_signature object described above.

11. Verification by the RP

The relying party performs the following checks:

1. Verify the OID4VP response structure.
2. Validate the SD-JWT presentation.
3. Verify the KB-JWT signature using the wallet public key.
4. Extract the document_signature object from the KB-JWT payload.
5. Verify that the document_digest matches the document to be signed.
6. Verify the detached JWS document signature.
7. Validate the nonce and aud values.

If all checks succeed, the RP obtains:

• a verified user identity (via the credential presentation)
• a reusable document signature
• a cryptographic binding between the signature and the OID4VP transaction.

[ThierryThevenet]

For test

1. get the ASCS profile https://wallet-provider.com/distribution/guest/5
2. get an email VC
3. got tos test 6 : https://talao.co/sandbox/verifier/test_6