Hopp til hovedinnhold
Symfoni docs Virksomhetslommebok
Innhold

Virksomhetsforsegling: kom i gang

Send en OpenID4VP-forespørsel med PDF-er og leveringsinformasjon, og motta forseglede dokumenter som en autentisert multipart POST.

Kjerneside Oppdatert 20. august 2026 · 3 min lesetid

Flyt for virksomhetsforsegling i Symfoni

Åpne diagrammet i full størrelse.

Målet

Målet er at mottakeren får både en verifiserbar presentasjon og én eller flere PDF-er som er forseglet med Signant eSeal. Dokumentlevering og OpenID4VP-callback er to separate nettverkskall og må kontrolleres hver for seg.

1. Bygg OpenID4VP-forespørselen

Bruk walletinngangen:

https://www.symfoni.dev/app/credential/verify?request_uri=<url-enkodet-request_uri>

Forespørselen må ha en unik nonce. client_id skal være x509_hash:<base64url-sha256-av-RP-access-sertifikatet>. I nye forespørsler viser credential_ids til id-er i DCQL. Symfoni kan også behandle Presentation Exchange-id-er for kompatibilitet med eldre OpenID4VP-utkast. I EBWOID-flyten brukes normalt business-identity.

2. Beskriv dokumenter og levering

På wire er hvert element i transaction_data base64url-enkodet JSON. OpenID4VP standardiserer den generelle mekanismen og feltene type og credential_ids. Feltene for PDF, transaksjonsid og dispatch under er Symfonis integrasjonsprofil; de er ikke en generell OpenID4VP-kontrakt.

Det dekodede innholdet kan se slik ut:

{
  "type": "qes_authorization",
  "credential_ids": ["business-identity"],
  "transaction_id": "contract-2026-001",
  "transaction_data_hashes_alg": ["sha-256"],
  "documentDigests": [
    {
      "id": "contract",
      "label": "Kontrakt.pdf",
      "hash": "<base64-sha256-av-pdf>",
      "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1",
      "documentLocation_uri": "https://verifier.example.com/documents/contract.pdf"
    }
  ],
  "dispatch": {
    "url": "https://verifier.example.com/signing-results/contract-2026-001",
    "authorization": {
      "scheme": "bearer",
      "token": "<engangstoken>"
    },
    "multipart": {
      "manifest_part": "manifest",
      "file_part_prefix": "document_"
    }
  }
}

qes_authorization er typeverdien i Symfonis nåværende profil. Navnet betyr ikke at resultatet er en kvalifisert elektronisk signatur eller et kvalifisert elektronisk segl. En framtidig offentlig profil bør bruke en versjonert, kollisjonsresistent URI eller URN.

Symfoni støtter flere documentDigests i samme element. Hvert dokument må ha en ikke-tom id, være PDF, bruke SHA-256 og oppgi nøyaktig én innholdskilde: contentBase64 eller dokument-URL. Send unike dokument-id-er: duplikater kan gi tvetydig manifest eller overskrevne multipart-deler.

Ved SD-JWT VC binder lommeboken de kodede transaction_data-verdiene til presentasjonen gjennom transaction_data_hashes i Key Binding JWT. Mottakeren må kontrollere disse hashene mot den opprinnelige forespørselen.

3. Motta resultatet

Symfoni sender POST til dispatch.url med engangstokenet som Bearer-token. Body er multipart/form-data:

  • manifest inneholder transaction_id og en liste over dokumentdelene
  • hver PDF ligger i en del som normalt heter document_<id>

Svar med en vellykket 2xx-status når både manifest og alle dokumenter er lagret. Symfoni følger ikke redirects. Leveringsorigin må være knyttet til den verifiserte forespørselen eller eksplisitt godkjent i miljøet.

Dokumentene leveres før Symfoni sender OpenID4VP-responsen. Dokumentleveringen kan derfor lykkes selv om callbacken senere feiler. Mottakeren bør først markere saken som fullført når både multipart-leveransen og den validerte presentasjonen er knyttet til samme transaksjon.

Vanlige feil

  • Manglende eller gjenbrukt nonce stopper flyten.
  • Feil eller manglende x509_hash-binding stopper flyten.
  • Hashen må stemme med den hentede PDF-en.
  • Privat eller lokal dokument-URL avvises utenfor intern test.
  • Manglende dispatch.url, token eller transaction_id avvises før forsegling.
  • Dupliserte dokument-id-er kan overskrive en multipart-del hos mottakeren.
  • Et ikke-2xx svar gjør kallet mislykket. Prototypen har ingen varig dispatch-feilstatus eller automatisk retry; start en ny kontrollert forespørsel etter feilsøking.

Lagre transaction_id, mottatt manifest og kontrollresultat. Ikke logg Bearer-tokenet eller dokumentinnholdet.

Symfoni lagrer i dag også den forseglede PDF-en i app.db som del av prototypens signaturrecord. Automatisk opprydding og håndhevet nedlastingsutløp er ikke ferdig. Bruk derfor ikke produksjonsdokumenter før lagrings- og slettereglene er avklart. Se Data, nøkler og lagring.