Wallet-sandkassen

Dokumentasjonen som forklarer sandkassen før produktet

Start med roller, tjenester, tillitskjeder og scenarier i sandboxen. Fortsett derfra inn i Symfoni når du skal implementere utstedelse, verifikasjon eller signering.

Roller og tjenester Tillit og sertifikater Scenarier og Symfoni-spor

Okosystem Dybde 2 Kanonisk Plattform Virksomhetslommebok Issuer Verifikasjon /docs/okosystem/roller-og-flyter

Roller og flyter

Issuer, wallet, verifier og tillitstjenester spiller ulike roller, og det er avgjørende å vite hvem som eier hvilke artefakter, sertifikater og callbacker i hver flyt.

På denne siden

4 seksjoner

Overskrifter og ankerlenker er klare for dypdykk.

Relaterte

2 sider

Bruk koblingene for nærliggende flyter og konsepter.

Seksjonen

3 dokumenter

Nyttig hvis du jobber gjennom en hel del av docs-stien.

Seksjon: Okosystem
Dybde: 2
Status: Kanonisk
Sist gjennomgått: 2026-03-20
Lesetid: 2 min

Plattform Virksomhetslommebok Issuer Verifikasjon

Dette gjelder i sandkassen

Rolleforståelsen er viktigere enn produktnavnene. Hver rolle eier ulike artefakter og ulike feilbilder:

Rolle	Eierskap i flyten	Hva som typisk feiler først
Issuer	`credential_offer_uri`, issuer-metadata, credential-utstedelse, status og revokasjon	feil template, feil attributter, manglende API-nøkkel
Wallet	credential-lagring, presentasjonsvalg, samtykke og signeringsmediering	feil match mellom request og tilgjengelige credentials
Verifier / relying party	`request_uri`, `response_uri`, `nonce`, `state`, validering av svaret	feil callback, feil `state`, utilstrekkelig validering
Tillitstjenester	sertifikatkjeder, rollepåstander, trust anchors og registreringer	feil binding mellom identitet og tillitsgrunnlag

Hva som må være entydig mellom rollene

hvem som oppretter og hoster offer eller request
hvem som mottar callbacken tilbake
hvem som må presentere klientsertifikat
hvem som må lagre issuanceId, state eller nonce
hvem som kan tolke en 404 som manglende data, og hvem som må tolke den som mulig tillits- eller bindingsfeil

Slik gjør du det i Symfoni

I Symfoni blir rollefordelingen synlig i de operative inngangene:

issuer bruker gatewayen under /api/issuers/{issuerSlug}/... eller sender brukeren til /app/credential/offer
walletens brukerflate ligger på /app/credential/offer og /app/credential/verify
verifier sender brukeren til /app/credential/verify med request_uri eller authorization_request
signeringsverifier må etterpå hente dokumenter fra /api/signatures/{nonce} med riktig klientsertifikat over mTLS

Feilbilder fordelt på ansvar

Hvis request_uri eller credential_offer_uri er ugyldig, ligger feilen normalt hos issuer eller verifier.
Hvis callbacken ikke godtar form-post eller ikke kjenner igjen state, ligger feilen hos relying party.
Hvis signerte dokumenter ikke kan hentes ut, må verifier sjekke både mTLS, ingress og bindingen mellom client_id og nonce.
Hvis tillitskjeden ikke godtas, ligger feilen i sertifikater, registrering eller forventet binding, ikke i wallet-GUI-en.

Krysskoblinger

Relaterte sider

Bruk disse koblingene når du trenger nærliggende begreper, protokoller eller implementasjonssteg.

Virksomhetslommebok

Issuer: kom i gang

Issuer-guiden viser hvordan du setter opp template og API-nøkkel, oppretter et offer i Symfoni og bruker `issuanceId` til å følge flyten videre.

Åpne side

Virksomhetslommebok

Verifikasjon: kom i gang

Guiden viser hvilke query-parametre Symfoni forventer, hvordan callbacken må oppføre seg, og hvordan suksess og feil returneres.

Åpne side