Signering med transaction_data

Hva som kommer i tillegg til vanlig OpenID4VP

Signeringsforespørselen må ikke bare be om et bevis. Den må også beskrive dokumentet som skal signeres, hash-algoritmen som ble brukt, og hvilket credential query-id som gir autorisasjon til å signere.

I den nye BR-flyten er dette query-id-et business-identity. Walleten viser dette som Virksomhetsbevis, mens det konkrete credentialet fra BR heter EBWOID.

Kritiske felt

• transaction_data
• credential_ids
• nonce
• client_id på x509_hash:-format
• dokumentets hash og tilhørende hashAlgorithmOID

Angreps- og feilscenarier

• credential_ids peker ikke til et gyldig DCQL-query-id.
• Verifier ber ikke om toppnivafeltet id fra EBWOID, selv om det er feltet som bærer virksomhets-ID-en.
• Dokumentets hash stemmer ikke med dokumentet som senere hentes eller vises.
• nonce brukes på nytt for en annen transaksjon.
• Verifier prøver å hente signaturen med et annet klientsertifikat enn det som ble brukt til bindingen.

Hva som beviser korrekt oppførsel

• Walleten avviser eller feiler tydelig hvis nonce mangler.
• Signaturuthenting returnerer 404 ved binding-mismatch og 410 for utløpte signaturer.
• Kun betrodd intern ingress får lov til å forwarde verifisert klientsertifikat til appen.