Kort forklart
Et sertifikat binder en offentlig nøkkel til en identitet eller bestemte attributter. En signatur eller et proof-of-possession viser kontroll over den tilhørende privatnøkkelen. En validert tillitskjede og en godkjent rolle avgjør om aktøren kan opptre som utsteder eller mottaker i den aktuelle flyten.
Bindinger Symfoni bruker
| Flyt | Viktige bindinger |
|---|---|
| Motta bevis | utsteders signatur, sertifikatkjede, metadata, gyldighet og status |
| Dele bevis | client_id, request object, nonce, state og response_uri |
| Forsegle dokument | de samme OpenID4VP-bindingene, dokumenthash, transaction_id, tillatt dispatch.url og kortlivet Bearer-token |
I Symfonis transaction_data-flyt skal client_id bruke formen x509_hash:<base64url-sha256-av-RP-access-sertifikatet>. Vanlige presentasjonsflyter kan bruke andre støttede bindinger. Mottakeren må uansett validere hele responsen; hashen alene er ikke en komplett tillitsmodell.
Hold dette hemmelig
- private nøkler
- Symfoni-API-nøkler for utstedelse
- Signant-konfigurasjon og tjenestelegitimasjon
- engangstokenet til
dispatch.url
Sertifikater og offentlige nøkler er normalt ikke hemmelige. De må derimot distribueres og roteres kontrollert.
Vanlige feil
client_idinneholder feil sertifikathash.- Sertifikatkjeden ender ikke i et tillitsanker miljøet kjenner.
nonceellerstateer utløpt, ukjent eller gjenbrukt.dispatch.urlhar en origin som ikke er knyttet til forespørselen eller godkjent i miljøet.- dokumenthashen stemmer ikke med PDF-en som skal forsegles.
- Bearer-tokenet mangler eller er feil på mottakersiden.
Avklar alltid hvem som forvalter nøkler, sertifikater, status og rotasjon før en pilot går videre til drift.