Dette gjelder i sandkassen
Når samme aktør både lager forespørselen, mottar callbacken og henter dokumenter etterpå, er det lett å blande identitetsbindingene. I praksis må du skille mellom hvilke sertifikater som identifiserer deg, hvilke som brukes i transport, og hvilke som inngår i selve tillitsvurderingen.
Tre sertifikatroller som ofte blandes
- Sertifikatet som identifiserer verifier eller relying party i requesten.
- Sertifikatet som brukes til mTLS når signerte dokumenter hentes etter fullført flyt.
- Eventuelle sertifikater som må inkluderes i eller ved siden av request object for at walleten skal kunne validere tillitsgrunnlaget.
Slik gjør du det i Symfoni
I Symfoni blir bindingen eksplisitt i requesten og i uthentingen etterpå.
Hvor bindingen blir synlig
I signeringscaser skal client_id være på formen x509_hash:<base64url-sha256-av-RP-access-certificate>. Det er dette Symfoni bruker som grunnlag for å binde verifier til nonce og signaturuthenting senere.
Hva du må holde hemmelig
- Private nokler til access certificates og mTLS-klientsertifikater.
- API-nokler for issuer-gatewayen.
- Eventuelle interne proxy-headerkontrakter. Disse skal aldri kunne spoofes direkte fra internett.
Hva som ofte feiler først
- Feil hash i
client_id. - Ugyldig eller manglende
nonce. - Klientsertifikat som ikke matcher bindingen som ble lagret da bruker fullførte signeringen.
- Ingress som stopper mTLS eller trust chain for requesten når appen ser den.