# Symfoni public documentation Canonical source: https://www.symfoni.dev/docs Source: https://www.symfoni.dev/docs # Virksomhetslommebok, forklart enkelt Lær hvordan offentlige tjenester kan motta, kontrollere og gjenbruke pålitelig virksomhetsinformasjon – og hvordan du prøver det med Symfoni. ## Start med behovet, ikke teknologien En virksomhetslommebok lar en organisasjon motta, oppbevare og dele digitale bevis. Et bevis kan for eksempel bekrefte virksomhetens identitet, en tillatelse eller at et krav er oppfylt. For en offentlig tjeneste er gevinsten enkel: Du kan motta strukturerte opplysninger fra en kjent utsteder og kontrollere dem maskinelt. Det kan erstatte opplasting, manuell dokumentkontroll og telefoner til datakilden. Velg [Start her](/docs/kom-i-gang) hvis temaet er nytt. Gå til [bruksområdene](/docs/bruksomrader) hvis du vurderer en konkret tjeneste. Gå til [Bruk Symfoni](/docs/virksomhetslommebok) når du vil prøve en flyt. ## Dette må du skille mellom - **Virksomhetsidentitet** forteller hvilken organisasjon beviset identifiserer. Lommeboken brukes på vegne av virksomheten. - **Rolle og fullmakt** forteller hvem som kan handle for organisasjonen, og hva de kan gjøre. - **Digitalt bevis** er en signert påstand fra en utsteder. - **Elektronisk segl** knytter et dokument til en juridisk person. Det er ikke det samme som en persons elektroniske signatur. ## Status i august 2026 > European Business Wallet er fortsatt et EU-lovforslag. Symfoni er en norsk virksomhetslommebok og pilotplattform som bruker europeiske standarder og den nasjonale sandkassen. Den har ingen EUDI-sertifisering eller framtidig EBW-leverandørautorisasjon. Se [EUDI Wallet, Business Wallet og Symfoni](/docs/kom-i-gang/eudi-business-wallet-og-symfoni) for skillet. [Kilder og status](/docs/kilder-og-status) viser hva som er gjeldende rett, forslag, standard og produktfunksjon. --- Source: https://www.symfoni.dev/docs/planlegg-og-forvalt/ansvar-personvern-og-arkiv # Ansvar, personvern og arkiv Avklar formål, behandlingsansvar, dataminimering, innsyn og arkiv før digitale bevis blir en del av saksbehandlingen. ## Teknologien fordeler ikke ansvaret At virksomheten deler et bevis fra egen lommebok, avgjør ikke alene hvem som er behandlingsansvarlig, hvilket rettsgrunnlag som gjelder, eller hva som skal arkiveres. Fordel ansvaret ut fra formålet og den faktiske behandlingen. Et virksomhetsbevis kan også inneholde personopplysninger, særlig når en navngitt person representerer organisasjonen. ## Avklar for hvert bevis - formålet med å utstede, oppbevare og kontrollere opplysningene - minste nødvendige felter og hvor ferske de må være - autentisk kilde og ansvarlig utsteder - hvem som kan dele på vegne av virksomheten - hvem som får se kontrollresultat og hendelseslogg - retting, tilbakekalling, innsyn og klage - hva som er arkivpliktig, og hva som skal slettes Selektiv deling reduserer datamengden, men erstatter ikke vurderingen av formål og behandlingsgrunnlag. ## Dokumenter mottakerens kontroll Mottakeren bør kunne vise hva som ble bedt om, hvorfor det var nødvendig, hvilken utsteder som ble godtatt, hvilke kontroller som ble utført og hvilket resultat saken bygget på. Unngå å lagre hele beviset dersom et datert kontrollresultat er tilstrekkelig. ## Når dere bør gjøre en grundigere vurdering Vurder personvernkonsekvenser og sikkerhetsrisiko særskilt når løsningen kombinerer flere kilder, omfatter sårbare personer, brukes til automatiserte avgjørelser, gir omfattende sporing eller håndterer sensitive opplysninger. Avklar også en forståelig reserveflyt for virksomheter eller representanter som ikke kan bruke lommeboken. ## Norske veiledere - [Datatilsynet: behandlingsansvarlig og databehandler](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/behandlingsansvarlig-og-databehandler/) - [Datatilsynet: grunnleggende personvernprinsipper](https://www.datatilsynet.no/rettigheter-og-plikter/personvernprinsippene/grunnleggende-personvernprinsipper/ansvarlighet/) - [Datatilsynet: vurdering av personvernkonsekvenser (DPIA)](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/) - [Arkivverket: arkivpliktig informasjon i felles saksbehandlingssystem](https://www.arkivverket.no/veiledere-for-offentlig-sektor/arkivpliktig-informasjon-i-felles-saksbehandlingssystem) --- Source: https://www.symfoni.dev/docs/bruksomrader/skjemafri-saksbehandling # Skjemafri saksbehandling La søkeren dele kontrollerbare opplysninger fra lommeboken, slik at tjenesten kan fylle ut data og kontrollere dokumentasjon uten nye vedlegg. ## Problemet i dag En virksomhet må ofte skrive inn registerdata og laste opp dokumentasjon som det offentlige allerede kjenner. Saksbehandleren må lese vedlegg, sammenligne kilder og be om mangler. ## Når lommebok gir verdi Tjenesten ber om akkurat de opplysningene saken trenger. Virksomheten godkjenner delingen. Systemet kontrollerer utsteder, integritet, binding, gyldighet og status før dataene brukes. Mønsteret passer når flere bevis må settes sammen, for eksempel virksomhetsidentitet, eierskap og en tillatelse. ## Aktører og ansvar - Registeret eller fagsystemet er kilde til opplysningen. - Utstederen lager og signerer beviset. - Virksomheten deler fra lommeboken. - Den offentlige tjenesten ber om og kontrollerer dataene. Mottakeren har fortsatt ansvar for behandlingsgrunnlag, dataminimering og selve vedtaket. ## Mål i en pilot Mål antall felter og vedlegg, tid brukt på dokumentkontroll, mangler per søknad og andel saker som kan gå videre uten manuell oppfølging. Oslo kommunes «Enkel Servering» er et norsk pilotmønster for denne reisen. Bruk piloten som inspirasjon, ikke som bevis på hvilken gevinst deres tjeneste vil få. ## Prøv i Symfoni Start med ett virksomhetsbevis og én verifikasjonsforespørsel. [Verifikasjonsguiden](/docs/virksomhetslommebok/verifikasjon/kom-i-gang) viser den tekniske flyten som er tilgjengelig i sandkassen. --- Source: https://www.symfoni.dev/docs/kom-i-gang/virksomhetslommebok-pa-fem-minutter # Virksomhetslommebok på fem minutter En virksomhetslommebok lar en organisasjon motta, oppbevare og dele kontrollerbare digitale bevis med offentlige og private tjenester. ## Kort forklart En virksomhetslommebok er et verktøy for å bruke pålitelig informasjon på tvers av tjenester. Den brukes på vegne av en virksomhet, mens én eller flere personer kan utføre handlingene. Informasjonen kommer som **digitale bevis**. Et bevis er data som en utsteder har signert. Mottakeren kan kontrollere hvem som utstedte det, om innholdet er endret, hvilken virksomhet beviset gjelder, og om det fortsatt er gyldig. Holder-binding og representasjonsrett må kontrolleres separat. ## Slik går en vanlig flyt 1. En datakilde har en opplysning, for eksempel organisasjonsnavn eller en bevilling. 2. En utsteder gjør opplysningen om til et signert bevis. 3. Virksomheten mottar beviset i lommeboken. 4. En tjeneste ber om bestemte opplysninger. 5. Virksomheten godkjenner delingen. 6. Tjenesten kontrollerer beviset og bruker dataene i prosessen. Utstederen og datakilden kan være samme virksomhet, men trenger ikke være det. ## Dette er ikke en dokumentmappe En PDF kan leses av et menneske. Et digitalt bevis kan også kontrolleres av et system. Lommeboken erstatter heller ikke datakilden: kilden må fortsatt forvalte riktige data, og utstederen må håndtere utløp og tilbakekalling. En lommebok er heller ikke bare innlogging. Den kan dele konkrete opplysninger etter at virksomheten er identifisert. ## Personen og virksomheten er to ulike aktører At et bevis identifiserer en virksomhet, sier ikke automatisk hvem som kan bruke det. En reell tjeneste må også avklare holder-binding, representasjon, roller og fullmakter. Symfonis nåværende sandkasse har virksomhetsidentitet, men ikke en komplett modell for delegert administrasjon og fullmakter. --- Source: https://www.symfoni.dev/docs/bruksomrader/seriostetskontroll # Seriøsitetskontroll og leverandøroppfølging Samle kontrollerbare bevis om en leverandør og be om oppdatert dokumentasjon gjennom hele kontraktsperioden. ## Problemet i dag Oppdragsgivere ber om firmaattest, skatteopplysninger, godkjenninger og andre vedlegg. Dokumentene har ulik alder og format. Den samme leverandøren leverer dem på nytt i flere konkurranser og kontroller. ## Når lommebok gir verdi Hver ansvarlig kilde kan utstede et eget bevis. Leverandøren deler nødvendige opplysninger ved prekvalifisering eller kontroll. Oppdragsgiveren kan kontrollere opprinnelse og status maskinelt. Lommeboken fjerner ikke behovet for anskaffelsesfaglige vurderinger. Den kan gjøre datagrunnlaget raskere å hente og enklere å kontrollere. ## Hva dere må avklare - Hvilke krav skal dokumenteres, og hvem er fasit? - Må dere lagre hele beviset, eller holder et kontrollresultat? - Hvor ferske må opplysningene være? - Hva skjer når et bevis trekkes tilbake under kontrakten? - Skal underleverandører inngå i samme flyt? ## Mål i en pilot Mål tid brukt av leverandør og oppdragsgiver, antall utdaterte dokumenter, antall manuelle registeroppslag og hvor raskt en statusendring blir oppdaget. ## Prøv i Symfoni Symfoni kan i sandkassen lagre og dele SD-JWT-baserte bevis. «Motta opplysninger» verifiserer medlemskap, ansettelse og trafikalt grunnkurs fra Digdir med Credo. Leverandørkontroll med andre bevistyper og flere bevis i samme forespørsel er ikke implementert i mottaket. --- Source: https://www.symfoni.dev/docs/planlegg-og-forvalt/sikkerhet-og-drift # Sikkerhet og drift En produksjonsklar lommeboktjeneste trenger forvaltning av nøkler, tillit, status, hendelser, gjenoppretting og reserveflyter. ## Tenk på hele kjeden En gyldig signatur beskytter ikke mot feil kilde, for vid fullmakt eller en kompromittert brukerkonto. Vurder hendelser hos alle aktørene: - feil eller kompromittert autentisk kilde - utsteder som bruker feil data eller mister en nøkkel - lommebok eller bruker som mister kontroll over tilgang - mottaker som ber om for mye eller bruker data til et annet formål - tillitsliste eller statusmekanisme som er utilgjengelig ## Minimum før produksjon - navngitt eier for nøkler, sertifikater, regelbøker og tillitsankere - rotasjon, tilbakekalling og varsling som er testet - sterk tilgangsstyring og skille mellom administrasjon og daglig bruk - overvåking med korrelasjon, uten rå bevis og hemmeligheter i logger - dokumentert backup, gjenoppretting og sletting - kapasitetsmål, tilgjengelighetskrav og beredskapskontakt - reserveflyt når lommebok, register eller mottaker er nede ## Test mer enn normalflyten Test avslag, utløpt bevis, tilbakekalling, feil virksomhet, gjenbrukt `nonce`, manglende callback, nøkkelrotasjon og delvis leveranse. Kontroller både hva systemet gjør og hva brukeren får forklart. Symfonis sandkasse kan støtte slike forsøk, men er ikke alene dokumentasjon på produksjonsklarhet. Bruk [kapabilitetsmatrisen](/docs/virksomhetslommebok/hva-kan-brukes-na) for å skille produktfunksjon fra manuelt oppsett og åpne gap. Bruk [NSMs grunnprinsipper for IKT-sikkerhet](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/ta-i-bruk-grunnprinsippene/) som et norsk utgangspunkt, og tilpass tiltakene til virksomhetens risiko, regelverk og avtaler. --- Source: https://www.symfoni.dev/docs/kom-i-gang/velg-bruksomrade # Velg et godt bruksområde Lommebok gir mest verdi når den erstatter gjentatt dokumentasjon, manuell kontroll og usikre dataflyter mellom flere aktører. ## Et godt første forsøk Start med én opplysning i én brukerreise. Bruksområdet er lovende når dere kan svare ja på minst fire av spørsmålene: - Må virksomheten dokumentere samme forhold flere ganger? - Kontrollerer en saksbehandler dokumentet manuelt i dag? - Finnes det en kjent datakilde og en ansvarlig utsteder? - Kan mottakeren bruke strukturerte data direkte? - Har gyldighet, utløp eller tilbakekalling betydning? - Deltar flere offentlige eller private aktører i reisen? - Er det nyttig at virksomheten styrer når data deles? ## Når en annen løsning er bedre Velg ikke lommebok bare fordi teknologien er ny. En direkte API-integrasjon kan være enklere når to kjente systemer utveksler data fast, og virksomheten ikke har behov for å oppbevare eller dele beviset videre. Lommebok passer også dårlig hvis ingen vil eie regelverket for beviset, datakvaliteten er ukjent, eller mottakeren bare kan behandle en PDF manuelt. ## Beskriv behovet i én setning Bruk denne formen: > Når **[virksomheten]** skal **[gjøre noe]**, trenger **[tjenesten]** å kontrollere **[minste nødvendige opplysning]** fra **[kilden]**, slik at **[målbar forbedring]**. Eksempel: Når en serveringsbedrift søker bevilling, trenger kommunen å kontrollere virksomhetsidentitet og relevante tillatelser fra kjente kilder, slik at færre vedlegg må lastes opp og kontrolleres manuelt. Gå deretter til [bruksområdene](/docs/bruksomrader) for konkrete mønstre. --- Source: https://www.symfoni.dev/docs/planlegg-og-forvalt/anskaffelse-og-skalering # Anskaffelse og skalering Still krav til dokumentert funksjon, åpne protokoller, flyttbare data og tydelig driftsansvar før en pilot blir en varig avhengighet. ## Kjøp en evne, ikke en veikartpåstand Skill mellom funksjon som er tilgjengelig og testet, funksjon som krever manuelt oppsett, og planlagt funksjon. Be om en datert kapabilitetsmatrise og dokumenterte interoperabilitetsresultater. ## Krav som reduserer innlåsing - navngitte versjoner av OpenID4VCI, OpenID4VP og bevisformatene - eksport eller kontrollert flytting av bevis, metadata og historikk - dokumenterte API-er, feilkoder og hendelser - eierskap til regelbøker, skjema og domenebegreper - utskifting av utsteder, lommebok eller mottaker uten å bygge hele tjenesten på nytt - plan for standardendringer og bakoverkompatibilitet ## Avklar leveransen Be om tydelig ansvarsdeling for drift, underleverandører, datalagring, nøkkelforvaltning, hendelseshåndtering, universell utforming, support og avslutning av avtalen. Avklar også hvordan testdata fjernes og hvordan virksomheten får ut egne data ved bytte. ## Porten fra pilot til drift Gå videre først når dere har: 1. målt en reell forbedring mot nullmålingen 2. løst representasjon og reserveflyt 3. godkjent personvern-, arkiv- og sikkerhetsvurderinger 4. testet minst én uavhengig motpart eller referanseimplementasjon 5. navngitt eiere og finansiering for hele livsløpet Regelverk og standarder er i bevegelse. Legg derfor inn faste tidspunkt for ny vurdering, og bruk [Kilder og status](/docs/kilder-og-status) som datert utgangspunkt. Se også [DFØs veiledning om kravspesifikasjoner](https://www.anskaffelser.no/anskaffelsesprosess/anskaffelsesprosessen-steg-steg/avklare-behov-og-forberede-konkurransen/kravspesifikasjoner-tildelingskriterier-og-kontraktsvilkar/utarbeide-kravspesifikasjoner), [krav til universell utforming i IT-anskaffelser](https://www.anskaffelser.no/hva-skal-du-kjope/it/krav-om-universell-utforming-i-anskaffelser-av-it) og [NSMs råd om sikkerhet gjennom anskaffelses- og utviklingsløpet](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/beskytte-og-opprettholde/ivareta-sikkerhet-i-anskaffelses-og-utviklingsprosesser/). --- Source: https://www.symfoni.dev/docs/bruksomrader/fullmakt-og-representasjon # Fullmakt og representasjon Kombiner virksomhetsidentitet med et eget bevis på rolle eller fullmakt når en person skal handle på vegne av en organisasjon. ## Identitet er ikke fullmakt Et virksomhetsbevis sier hvilken organisasjon beviset identifiserer. Det sier ikke automatisk at en bestemt person kan sende inn en søknad, inngå en avtale eller dele alle virksomhetens data. En representasjonsflyt må derfor svare på tre spørsmål: 1. Hvilken person handler? 2. Hvilken virksomhet representerer personen? 3. Hvilken handling og tidsperiode dekker retten? ## Et mulig bevissett Tjenesten kan be om virksomhetsidentitet, personidentitet og et separat rolle- eller fullmaktsbevis. Bevisene må bindes til samme transaksjon, og tjenesten må kontrollere om fullmakten fortsatt gjelder. Be om minst mulig. En rett til å sende én søknad bør ikke gi innsyn i andre opplysninger eller generell signaturrett. ## Hva dere må avklare - Hvem er autentisk kilde for rollen eller fullmakten? - Kan retten delegeres videre? - Hvordan trekkes den tilbake? - Krever handlingen personlig signatur, virksomhetssegl eller bare autorisasjon? - Hvordan håndteres personer som bytter rolle under en pågående sak? ## Status i Symfoni Symfonis nåværende sandkasse har virksomhetsidentitet og brukerautorisert deling. Den har ikke en komplett, generell modell for organisasjonsroller, delegert administrasjon eller fullmakter. Dette bruksområdet krever derfor egen modellering og skal omtales som et videre pilotspor, ikke en ferdig produktfunksjon. --- Source: https://www.symfoni.dev/docs/kom-i-gang/planlegg-pilot # Planlegg en pilot Avgrens piloten til én brukerreise, ett bevis og noen få mål som kan vise om løsningen gir mindre arbeid, raskere behandling eller bedre kvalitet. ## Avklar før dere bygger Skriv ned disse seks beslutningene på én side: 1. **Problemet:** Hvilket manuelt arbeid eller hvilken risiko skal reduseres? 2. **Beviset:** Hvilke få opplysninger trenger mottakeren? 3. **Kilden:** Hvem er fasit, og hvem kan utstede på vegne av kilden? 4. **Aktørene:** Hvem eier lommeboken, hvem handler, og hvem kontrollerer? 5. **Livsløpet:** Når utløper beviset, og hvordan trekkes det tilbake? 6. **Målet:** Hva må bli bedre for at dere går videre? ## Mål før og etter Ta en enkel nullmåling. Bruk for eksempel: - minutter brukt på å hente og kontrollere dokumentasjon - antall vedlegg og mangler per sak - andel saker som kan behandles uten manuell kontroll - tid fra innsending til vedtak - antall oppslag eller telefoner til andre virksomheter Mål samme tall i piloten. Ikke bruk forventet gevinst som dokumentert resultat. ## Et praktisk seksukersløp - **Uke 1:** Kartlegg dagens reise og velg bevis. - **Uke 2:** Avklar data, hjemmel, ansvar og testpersoner. - **Uke 3–4:** Konfigurer utstedelse og verifikasjon i sandkassen. - **Uke 5:** Test normalflyt, avslag, utløp og feil. - **Uke 6:** Mål, oppsummer risiko og ta en beslutning. Dette er et forslag til arbeidsform, ikke et løfte om leveringstid. ## Pilotklar Piloten er klar når dere har en ansvarlig produkteier, testdata uten unødvendige personopplysninger, en fungerende fallback og tydelig merking av at sandkassebevis ikke er produksjonsdokumentasjon. --- Source: https://www.symfoni.dev/docs/kom-i-gang/eudi-business-wallet-og-symfoni # EUDI Wallet, Business Wallet og Symfoni EUDI Wallet under eIDAS 2, det foreslåtte European Business Wallet-regelverket og Symfonis norske pilotplattform er beslektet, men ikke det samme. ## Tre forskjellige ting | Navn | Hva det er | Status 20. august 2026 | | --- | --- | --- | | EUDI Wallet | Europeisk identitetslommebok under eIDAS 2; gjeldende ARF-brukstilfeller tar utgangspunkt i en personlig lommebokenhet | eIDAS 2 er vedtatt i EU. Det norske EØS-arbeidet pågår. | | European Business Wallet | Foreslått rammeverk for økonomiske aktører og offentlige organer | EU-lovforslag i ordinær behandling. Ikke endelig regelverk. | | Symfoni | Norsk plattform for virksomhets- og personlommebok, utstedelse, verifikasjon og virksomhetsforsegling | Produkt og pilot i nasjonal sandkasse. Ingen EUDI-sertifisering eller framtidig EBW-leverandørautorisasjon. | ## ARF har tatt ut lommebokenheter for juridiske personer EUs Architecture and Reference Framework (ARF) er den viktigste tekniske oversikten for EUDI Wallet. Versjon 3.0.0 sier presist at temaet lommebokenheter for juridiske personer, som kan inneholde identifikasjonsdata for juridisk person, er tatt ut i lys av arbeidet med en egen Business Wallet. Det betyr ikke at juridiske personer er borte fra eIDAS. ARF er fortsatt en viktig kilde til roller, protokoller og tillit, men den kan ikke brukes som ferdig kravspesifikasjon for en virksomhetslommebok. ## Hva dette betyr for en offentlig virksomhet - Bruk sandkassen til læring, prototyping og interoperabilitet. - Skill mellom funksjoner som finnes i Symfoni og krav som kan komme i et endelig EU-regelverk. - Ikke legg til grunn at pilotbevis har samme rettsvirkning som et framtidig regulert bevis. - Planlegg for endringer i terminologi, sertifisering, tillitslister og representasjonsmodell. Se [Kilder og status](/docs/kilder-og-status) for direkte lenker til EU, Digdir og protokollene. --- Source: https://www.symfoni.dev/docs/bruksomrader/virksomhetsforsegling # Virksomhetsforsegling La en bruker godkjenne forsegling i sandkassen, kontroller representasjonsretten separat og send resultatet til mottakeren. ## Segl og signatur er ulike En elektronisk signatur knyttes til en fysisk person. Et elektronisk segl knyttes til en juridisk person og har som formål å sikre dokumentets opprinnelse og integritet. Kall derfor ikke et virksomhetssegl «virksomhetens signatur». Avklar også det juridiske nivået på tjenesten før dere beskriver resultatet som kvalifisert. ## Slik går flyten 1. Tjenesten beskriver dokumentet og handlingen i en forespørsel. 2. Symfoni viser virksomheten, dokumentet og forespørselen til brukeren. 3. Brukeren godkjenner handlingen i sandkassen. Tjenesten må separat fastslå at personen kan handle for virksomheten. 4. Dokumentet forsegles gjennom Signant eSeal. 5. Symfoni sender det forseglede dokumentet til mottakerens avtalte endepunkt. Forespørselen må binde sammen virksomhetsbevis, dokumenthash, mottaker og en unik transaksjon. ## Hva dere må avklare - Hvem kan godkjenne forseglingen? - Krever handlingen også en personlig signatur? - Hvordan ser brukeren nøyaktig hva som godkjennes? - Hvor lagres dokument, kontrollresultat og hendelseslogg? - Hvordan håndteres avbrudd etter godkjenning, men før levering? ## Prøv i Symfoni Symfoni støtter i dag en sandkasseflyt for brukerautorisert eSeal og push-levering til mottakeren. Se [Virksomhetsforsegling: kom i gang](/docs/virksomhetslommebok/signering/kom-i-gang) for den faktiske integrasjonskontrakten. --- Source: https://www.symfoni.dev/docs/kom-i-gang # Start her Få et kort og presist bilde av virksomhetslommebok, vurder om teknologien passer behovet, og planlegg et avgrenset forsøk. ## Les i denne rekkefølgen 1. [Virksomhetslommebok på fem minutter](/docs/kom-i-gang/virksomhetslommebok-pa-fem-minutter) forklarer ideen uten protokollspråk. 2. [Velg et godt bruksområde](/docs/kom-i-gang/velg-bruksomrade) hjelper deg å vurdere om lommebok er riktig verktøy. 3. [Planlegg en pilot](/docs/kom-i-gang/planlegg-pilot) gir et kort opplegg fra behov til måling. 4. [EUDI Wallet, Business Wallet og Symfoni](/docs/kom-i-gang/eudi-business-wallet-og-symfoni) rydder i regelverk, standarder og produktstatus. ## Målet Etter denne delen skal du kunne forklare: - hvilket problem lommeboken løser - hvem som utsteder, deler og kontrollerer et bevis - når en direkte API-integrasjon kan være et bedre valg - hva dere må avklare før en pilot Du trenger ikke forstå OpenID4VCI, OpenID4VP eller SD-JWT for å ta den første beslutningen. --- Source: https://www.symfoni.dev/docs/bruksomrader/vedtak-som-digitalt-bevis # Vedtak som digitalt bevis Utsted en tillatelse, attest eller et vedtak som strukturert bevis slik at virksomheten kan bruke det videre uten å be etaten bekrefte det på nytt. ## Fra sluttdokument til gjenbrukbare data Et offentlig vedtak ender ofte som brev eller PDF. Virksomheten kan lese det, men en ny tjeneste må kontrollere dokumentet manuelt eller spørre etaten som fattet vedtaket. Et digitalt bevis kan inneholde de strukturerte opplysningene andre faktisk trenger: type tillatelse, virksomhet, gyldighetsperiode, vilkår og referanse til vedtaket. ## Når lommebok gir verdi Mønsteret passer når virksomheten skal dokumentere samme tillatelse overfor flere mottakere, eller når status må kunne kontrolleres etter utstedelsen. Beviset erstatter ikke nødvendigvis arkivdokumentet. Det kan være et maskinlesbart bevis på de viktigste virkningene av vedtaket. ## Hva utstederen må eie - en tydelig regel for hva beviset betyr - maskinlesbare felter med stabil betydning - sikker kobling til riktig virksomhet - utløp, fornyelse og tilbakekalling - kontaktpunkt for feil og klage - samsvar mellom bevis, vedtak og autentisk kilde ## Mål i en pilot Mål hvor ofte virksomheten gjenbruker beviset, hvor mange manuelle bekreftelser som unngås, og hvor raskt en mottaker oppdager at en tillatelse er endret eller trukket tilbake. ## Prøv i Symfoni Symfonis utstederfunksjon har maler, API-nøkler, offer, status og tilbakekalling. [Utstederguiden](/docs/virksomhetslommebok/issuer/kom-i-gang) viser hva som er tilgjengelig nå. --- Source: https://www.symfoni.dev/docs/bruksomrader # Bruksområder Finn tjenester der kontrollerbare virksomhetsdata kan erstatte vedlegg, manuelle oppslag og gjentatt innhenting av den samme dokumentasjonen. ## Se etter gjentatt dokumentasjon De beste bruksområdene har tre kjennetegn: En kjent kilde kan bekrefte data, virksomheten har nytte av å ta beviset med seg, og mottakeren kan bruke strukturerte opplysninger direkte. Start med mønsteret som ligner mest på tjenesten deres: - [Skjemafri saksbehandling](/docs/bruksomrader/skjemafri-saksbehandling) - [Seriøsitetskontroll og leverandøroppfølging](/docs/bruksomrader/seriostetskontroll) - [Fullmakt og representasjon](/docs/bruksomrader/fullmakt-og-representasjon) - [Virksomhetsforsegling](/docs/bruksomrader/virksomhetsforsegling) - [Vedtak som digitalt bevis](/docs/bruksomrader/vedtak-som-digitalt-bevis) ## Bruk samme vurderingsmal For hvert bruksområde bør dere beskrive problemet i dag, aktørene, minste nødvendige data, autentisk kilde, brukerreisen og ønsket gevinst. Merk også modenheten som idé, sandkasse, pilot eller produksjon. Ikke bruk pilotresultater som generelle gevinstløfter. Mål effekten i deres egen prosess. --- Source: https://www.symfoni.dev/docs/planlegg-og-forvalt # Planlegg og forvalt Ta virksomhetslommeboken fra avgrenset forsøk til en tjeneste med tydelig ansvar, lovlig databruk, sikker drift og målbar verdi. ## Fire beslutninger før dere går videre 1. **Eierskap:** Hvem eier beviset, regelboken, tjenesten og tilliten? 2. **Databruk:** Hvilke opplysninger er nødvendige, og hvor lenge skal de beholdes? 3. **Drift:** Hvordan håndteres nøkler, tilbakekalling, hendelser og bortfall? 4. **Skalering:** Hvilke åpne standarder og exit-krav hindrer innlåsing? Start med [Ansvar, personvern og arkiv](/docs/planlegg-og-forvalt/ansvar-personvern-og-arkiv). Bruk deretter [Sikkerhet og drift](/docs/planlegg-og-forvalt/sikkerhet-og-drift) og [Anskaffelse og skalering](/docs/planlegg-og-forvalt/anskaffelse-og-skalering) som beslutningsgrunnlag. Dette er en praktisk sjekkliste, ikke juridisk rådgivning. Involver personvernombud, arkiv, sikkerhet, juss og tjenesteeier tidlig. --- Source: https://www.symfoni.dev/docs/oversikt # Forstå lommeboken Få oversikt over sandkassen, aktørene og begrepene som går igjen før du leser produkt- eller protokolldetaljer. ## Tre spørsmål først 1. Hvilken opplysning trenger tjenesten å stole på? 2. Hvem er autentisk kilde – kilden som er fasit – og ansvarlig utsteder? 3. Hvem handler for virksomheten, og hvilken rett har personen? Les [Den norske sandkassen](/docs/oversikt/hva-er-sandkassen) for rammene, [Hvordan delene henger sammen](/docs/oversikt/hvordan-delene-henger-sammen) for lagene og [Begreper og ordliste](/docs/oversikt/begreper-og-ordliste) når ordene blir uklare. Når modellen er forstått, går du til [Bruksområder](/docs/bruksomrader) eller [Bruk Symfoni](/docs/virksomhetslommebok). --- Source: https://www.symfoni.dev/docs/oversikt/hva-er-sandkassen # Den norske sandkassen Digdirs sandkasse lar offentlige og private virksomheter utforske digitale lommebøker før standarder, ansvar og produksjonsløsninger er ferdig avklart. ## Hva sandkassen er Sandkassen er et sted for å prøve samspillet mellom utsteder, lommebok, mottaker og tillitsinfrastruktur. Den gjør det mulig å teste en hel brukerreise før dere tar stilling til produksjonsarkitektur og anskaffelse. Symfoni er en av løsningene som kan brukes i dette miljøet. Digdir forvalter den nasjonale sandkassen; Symfoni er ikke den nasjonale lommeboken eller en myndighetsgodkjent EUDI Wallet. ## Hva dere kan lære - om bruksområdet faktisk sparer tid eller reduserer feil - hvilket digitalt bevis og hvilke attributter tjenesten trenger - hvem som må være autentisk kilde, utsteder og mottaker - hvordan brukergodkjenning, representasjon, tillit og tilbakekalling skal fungere - hvilke callbacker, sertifikater og driftsrutiner en integrasjon krever ## Hva sandkassen ikke beviser En vellykket test er ikke i seg selv dokumentasjon på juridisk etterlevelse, produksjonssikkerhet, sertifisering eller gevinst. Hver virksomhet må fortsatt avklare behandlingsgrunnlag, arkiv, ansvar, sikkerhet og forvaltning. Start med [Velg bruksområde](/docs/kom-i-gang/velg-bruksomrade), og bruk deretter [Planlegg en pilot](/docs/kom-i-gang/planlegg-pilot). Les også [Digdirs introduksjon til sandkassen](https://docs.digdir.no/docs/lommebok/lommebok_om.html). --- Source: https://www.symfoni.dev/docs/oversikt/hvordan-delene-henger-sammen # Hvordan delene henger sammen Se hvordan forretningsbehov, tillit, protokoller og faktiske tjenester bygger på hverandre i en lommebokflyt. [![Oversikt over sandkasse og Symfoni-flyt](/docs/diagrams/ecosystem-flow.svg)](/docs/diagrams/ecosystem-flow.svg) [Åpne diagrammet i full størrelse](/docs/diagrams/ecosystem-flow.svg). ## Dette gjelder i sandkassen Det er nyttig å holde minst fire lag fra hverandre: 1. Forretningslaget: hvem trenger dataene, hvem representerer virksomheten, og hvem skal stole på resultatet. 2. Tillitslaget: sertifikater, kataloger, tillitslister, rollepåstander og registreringer. 3. Protokollaget: `OpenID4VCI` for utstedelse og `OpenID4VP` for bevis og signering. 4. Driftslaget: faktiske URL-er, callbacker, nonce-bindinger og tilgjengelighet i miljøet. Hvis du blander lagene, blir feilsøking dyr. En request kan være syntaktisk korrekt og likevel feile fordi feil sertifikat ble brukt, fordi `response_uri` ikke er nåbar, eller fordi relying party ikke kjenner igjen egen `state`. ## Lagene som rekkefølge i en virkelig flyt 1. En issuer eller verifier bestemmer hva som trengs for en konkret transaksjon. 2. Tillitsforutsetningene avgjør hvilke identiteter og sertifikater som er gyldige. 3. Protokollen beskriver hvordan offeret eller forespørselen sendes og hvordan svaret returneres. 4. Driftsmiljøet avgjør om offer-URI, request-URI, callback og dokumentlevering faktisk kan nås og fullføres. 5. Status og drift avgjør om du kan følge opp transaksjonen etterpå. ## Slik gjør du det i Symfoni Symfoni konkretiserer de samme lagene i tydelige innganger: - produktlaget starter i [virksomhetslommeboken](/docs/virksomhetslommebok), med `/app/credential/offer` for utstedelse og `/app/credential/verify` for verifikasjon og signering - tillitslaget blir operativt i [Tillit og sertifikater i Symfoni](/docs/virksomhetslommebok/tillitsrammeverk-og-sertifikater), der request-binding, sertifikatkjede og roller må stemme - status- og driftslaget blir synlig i utstederstatus, tilbakekalling, callback og dokumentlevering ## Hvor du finner detaljene - Roller og informasjonsflyt: [økosystem](/docs/okosystem/roller-og-flyter) - Felles språk og synonymer: [begreper og ordliste](/docs/oversikt/begreper-og-ordliste) - Datastrukturer og formater: [datamodell](/docs/datamodell/claims-credentials-presentations) - Tillit og proof-mekanismer: [sikring](/docs/sikring/tillitsrammeverk) - Ende-til-ende-journeys: [scenarier](/docs/scenarier) - Konkrete kjøreveier i produktet: [virksomhetslommebok](/docs/virksomhetslommebok) --- Source: https://www.symfoni.dev/docs/oversikt/begreper-og-ordliste # Begreper og ordliste Ordlisten kobler Digdir-språk, protokollspråk og Symfoni-språk slik at samme rolle eller artefakt ikke ser ut som tre forskjellige ting. ## Hvorfor denne siden finnes I wallet-økosystemet brukes flere språk samtidig: organisasjonsspråk, Digdir-språk, OpenID4VC-språk og produktnavn i Symfoni. Hvis du ikke normaliserer ordene, ser det fort ut som om flere forskjellige systemer gjør samme jobb. ## Samme rolle, ulike ord | Rolle eller artefakt | Vanlige ord i økosystemet | I denne docs-flaten | Slik blir det konkret i Symfoni | | --- | --- | --- | --- | | Utsteder | issuer, issuing authority | issuer | issuer-gateway under `/api/issuers/{issuerSlug}/...` | | Mottaker av bevis | verifier, relying party, brukersted | verifier / relying party | ekstern tjeneste som sender bruker til `/app/credential/verify` | | Wallet | wallet, holder wallet, lommebok | wallet | virksomhetslommeboken i Symfoni | | Tilbud om utstedelse | credential offer, `credential_offer_uri` | offer | inngang til `/app/credential/offer` | | Forespørsel om bevis | authorization request, `request_uri` | request | inngang til `/app/credential/verify` | | Returpunkt | `response_uri`, callback, form-post endpoint | callback | verifierens eget mottakspunkt | | Tillitsgrunnlag | trust list, trust anchor, certificate chain | tillit | sertifikat- og rollevalidering før flyten fullføres | ## Ord som skaper mest friksjon - `verifier` og `relying party` brukes ofte om samme part. I denne dokumentasjonen betyr de normalt samme integrasjon. - `wallet` kan bety både en generell rolle og det konkrete produktet Symfoni. Når vi mener produktet, skriver vi `virksomhetslommeboken`. - `authorization_request` og `request_uri` representerer samme type verifikasjonsforespørsel, men med ulik transportform. - `credential_offer_uri` er ikke selve credentialet. Det er bare inngangen til utstedelsesflyten. ## Hvordan du bruker ordlisten Hvis du leser en sandbox-side, bruk ordene her som fasit og gå videre til: - [Roller og flyter](/docs/okosystem/roller-og-flyter) for ansvar og eierskap - [Virksomhetslommebok: kom i gang](/docs/virksomhetslommebok/kom-i-gang) for de konkrete Symfoni-inngangene --- Source: https://www.symfoni.dev/docs/okosystem # Aktører og ansvar Se hvordan autentisk kilde, utsteder, virksomhet, lommebok, mottaker og tillitsforvalter samarbeider. ## Ingen aktør løser hele reisen alene Datakilden må være riktig. Utstederen må signere et forståelig bevis. Lommeboken må beskytte nøkler og vise brukeren hva som skjer. Mottakeren må kontrollere beviset før det brukes. Tillitsinfrastrukturen må være tilgjengelig og oppdatert. Start med [Roller og flyter](/docs/okosystem/roller-og-flyter). [Tjenester og aktører](/docs/okosystem/tjenester-og-aktorer) skiller den generelle modellen fra Symfoni, og [Registrering og tilgang](/docs/okosystem/registrering-og-tilgang) viser tekniske forutsetninger. --- Source: https://www.symfoni.dev/docs/okosystem/roller-og-flyter # Roller og flyter Utsteder, lommebok og mottaker eier ulike deler av en flyt. Et tydelig ansvarskart gjør piloten enklere å bygge og forvalte. ## Ansvar i en vanlig flyt | Rolle | Eier i flyten | Må kontrollere | | --- | --- | --- | | Utsteder | tilbud, metadata, bevisinnhold, gyldighet og tilbakekalling | riktig kilde, riktig mottaker og korrekt bevis | | Lommebok | lagring, nøkkelbinding, brukergodkjenning og presentasjon | forespørselens tillit og at brukeren ser hva som deles | | Mottaker / verifikator | forespørsel, `response_uri`, `nonce`, `state` og behandling av svaret | signatur, binding, gyldighet, status og formål | | Tillitsforvalter | tillitsankere, registreringer og rolleinformasjon | at listen er korrekt, tilgjengelig og oppdatert | ## Tre hovedflyter ### Utstede Utstederen lager et tilbud. Virksomheten godkjenner det i lommeboken. Lommeboken mottar og validerer beviset før det lagres. ### Dele og kontrollere Mottakeren lager en OpenID4VP-forespørsel. Virksomheten velger og godkjenner opplysningene. Mottakeren validerer responsen før den brukes i saksbehandlingen. ### Forsegle et dokument Mottakeren legger dokumenthash og leveringsinformasjon i `transaction_data`. Etter brukerens godkjenning forsegler Symfoni PDF-en og sender den til mottakerens `dispatch.url`. Den vanlige presentasjonen sendes til `response_uri`. ## Avklar før dere bygger - Hvem er autentisk kilde for hvert felt? - Hvem kan be om og bruke opplysningene? - Hvordan avgjør dere at en person kan handle for virksomheten? - Hvem reagerer ved tilbakekalling, nøkkelkompromittering eller feillevering? - Hvilke data må arkiveres, og hvilke skal slettes? Virksomhetsidentitet er ikke det samme som representasjonsrett. Se [Fullmakt og representasjon](/docs/bruksomrader/fullmakt-og-representasjon). --- Source: https://www.symfoni.dev/docs/okosystem/tjenester-og-aktorer # Tjenester og aktører Se hvem som utsteder, oppbevarer og kontrollerer et digitalt bevis, og hvem som har ansvar for datakilden og tilliten. ## Aktørene i en lommebokflyt | Aktør | Ansvar | | --- | --- | | Virksomheten | bruker lommeboken og godkjenner hva som deles eller forsegles; representasjonsrett må kontrolleres separat | | Autentisk kilde | er fasit for opplysningen, for eksempel et offentlig register | | Utsteder | henter eller mottar opplysningen og utsteder et kryptografisk signert bevis | | Lommebokleverandør | oppbevarer bevis og nøkler og gjennomfører godkjente protokollflyter | | Mottaker / verifikator | ber om nødvendige opplysninger og kontrollerer signatur, binding, gyldighet og status | | Tillitsforvalter | gjør tillitsankere, sertifikater, registreringer eller regelbøker tilgjengelige | Autentisk kilde og utsteder kan være samme virksomhet, men trenger ikke være det. Mottakeren må forstå både hvem som signerte beviset og hvilken kilde opplysningen kommer fra. ## Tjenester Symfoni leverer i sandkassen | Tjeneste | Hva den gjør | | --- | --- | | Virksomhetslommebok | mottar SD-JWT VC, bygger presentasjoner og viser historikk | | Utstedertjeneste | oppretter tilbud, følger utstedelse og kan tilbakekalle bevis | | Verifikasjon | oppretter og behandler OpenID4VP-forespørsler | | Virksomhetsforsegling | forsegler PDF-er med Signant eSeal og leverer dem til mottakerens `dispatch.url` | | Demo og test | gir avgrensede flyter for pilot og interoperabilitet | Se [Hva kan brukes nå?](/docs/virksomhetslommebok/hva-kan-brukes-na) før dere planlegger en pilot. Enkelte funksjoner krever manuelt oppsett, og fullmakt eller delegert administrasjon er ikke komplett produktstøtte. --- Source: https://www.symfoni.dev/docs/okosystem/registrering-og-tilgang # Registrering og tilgang Før du kan teste meningsfullt i sandboxen må roller, miljøer, callbacker, sertifikater og eventuelle API-nøkler være avklart og tilgjengelige. ## Minimum før du begynner For denne sandboxen betyr "tilgang" ikke bare brukerinnlogging. Du trenger også tekniske forutsetninger som gjør at flyten kan fullføres fra ende til ende. ## Sjekkliste per rolle ### Hvis du er issuer - du trenger en issuer-profil eller `issuerSlug` - du trenger minst én template med korrekt attributtmodell - du trenger en Symfoni-API-nøkkel for å opprette offers og følge status ### Hvis du er verifier - du trenger en offentlig `response_uri` som kan ta imot form-post - du trenger egne korrelasjonsnøkler som `state` og `nonce` - ved forsegling trenger du i tillegg en offentlig `dispatch.url` som tar imot multipart, og et kortlivet Bearer-token ### Hvis du tester lokalt - du trenger en offentlig inngang som kan nå localhost, for eksempel en kontrollert tunnel - du må vite hvilke deler av flyten som kan kjøres lokalt og hvilke som må treffe delt testmiljø ## Ytre avhengigheter du må planlegge for - sertifikater eller rollepåstander som matcher forventet tillitsmodell - riktig miljøadresse for wallet og callback - eventuell ekstern verifier- eller issuer-hosting av request- eller offer-URI ## Et praktisk minimumsforløp 1. Velg miljø i [driftssidene](/docs/drift). 2. Avklar om du starter som issuer eller verifier. 3. Opprett eller motta de nødvendige URL-ene, nøklene og sertifikatene. 4. Kjør første reelle test gjennom [virksomhetslommeboken](/docs/virksomhetslommebok/kom-i-gang). --- Source: https://www.symfoni.dev/docs/datamodell # Digitale bevis og data Skill mellom enkeltopplysninger, signerte bevis og presentasjoner, og forstå hvordan formatet påvirker deling og kontroll. ## Tre nivåer - Et **attributt** er én opplysning, for eksempel organisasjonsnummer. - Et **digitalt bevis** samler opplysninger som en utsteder har signert. - En **presentasjon** er det lommeboken deler som svar på en konkret forespørsel. Les [Attributter, bevis og presentasjoner](/docs/datamodell/claims-credentials-presentations) før [Serialisering og formater](/docs/datamodell/serialisering-og-formater). Formatet er teknisk; betydningen, kilden og retten til å bruke dataene er et forretningsansvar. --- Source: https://www.symfoni.dev/docs/datamodell/claims-credentials-presentations # Claims, credentials og presentations Claims er påstander, credentials er signerbare beholdere for påstandene, og presentasjoner er kontrollerte svar bygget fra ett eller flere credentials. ## Claims Claims er de enkelte datafeltene du bryr deg om, for eksempel organisasjonsnummer, navn eller rolle. Et claim får ikke automatisk verdi fordi det finnes i JSON. Det må forankres i et credential som en utsteder faktisk har signert. ## Credentials Et credential er et signert datasett med kontekst, utstederidentitet, payload og ofte regler for hvilke felter som kan selektivt deles videre. I virksomhetslommebokscenarier er det vanlig at ett credential beskriver virksomheten, mens et annet beskriver representasjonsrett eller signeringsautorisasjon. ## Presentasjoner En presentasjon er walletens svar på en konkret forespørsel. Den trenger ikke å inneholde hele credentialet. Den kan inneholde bare feltene relying party faktisk ba om, og den kan knyttes til `nonce`, `state` og klientidentitet slik at svaret ikke kan brukes fritt i en annen sammenheng. --- Source: https://www.symfoni.dev/docs/datamodell/serialisering-og-formater # Serialisering og formater Formatvalg som SD-JWT VC og kodede request objects bestemmer hvordan data kan transporteres, verifiseres og bindes til en flyt. ## Formatet bestemmer handlingsrommet Det viktigste valget er ikke bare hvilket felt du sender, men hvilket format som bærer det. Formatet bestemmer blant annet signatur, holder-binding, selektiv deling og hvilke lommebøker og mottakere som kan behandle beviset. ## Tre ting å kontrollere 1. Hvilket credential-format verifier eller issuer krever. 2. Hvordan request object eller offer beskriver de formatene. 3. Hvordan walleten presenterer eller henter innholdet videre på wire. ## Der dette blir synlig i Symfoni Symfoni støtter SD-JWT VC i utstedelse og remote OpenID4VP. Gjeldende OpenID4VP-term er `dc+sd-jwt`; `vc+sd-jwt` finnes i eldre implementasjoner. Selve SD-JWT-mekanismen er RFC 9901, mens SD-JWT VC-profilen fortsatt er under IETF-standardisering. mdoc og proximity støttes ikke. --- Source: https://www.symfoni.dev/docs/sikring # Sikkerhet og tillit Forstå bevis på nøkkelkontroll, request-binding, tillitskjeder og hvilke hemmeligheter som må beskyttes. ## Hva denne delen svarer på Her ser du hvorfor en forespørsel kan avvises, hvordan `nonce` og proof hindrer gjenbruk, og hvordan sertifikater og tillitslister binder en aktør til riktig rolle. ## Videre lesning - [Proof-mekanismer](/docs/sikring/proof-mekanismer) - [Tillitsrammeverk](/docs/sikring/tillitsrammeverk) - [Tillitslister og sertifikatkjeder](/docs/sikring/tillitslister-og-sertifikatkjeder) --- Source: https://www.symfoni.dev/docs/sikring/proof-mekanismer # Proof-mekanismer Proof-mekanismer binder en presentasjon til riktig utfordring, riktig mottaker og riktig tidspunkt, slik at data ikke bare kan kopieres inn i en ny flyt. ## Nonce og state `nonce` beskytter mot gjenbruk av gamle svar. `state` beskytter mot at svar havner i feil forretningskontekst. Sammen gir de relying party et minimum av bevis for at walleten svarte på akkurat denne forespørselen. ## request_uri og authorization_request Et `request_uri` peker til et objekt som må kunne hentes og stoles på i tide. Hvis URI-en er kortlivet, må verifier forvente at gamle lenker gir 404 eller `invalid_request_uri`. Et inline `authorization_request` unngår ekstra hentesteg, men kan bli større og vanskeligere å rotere. ## direct_post Symfoni forventer at mottakeren bruker `response_mode=direct_post` for vanlige presentasjoner og forsegling. Ved suksess sendes form-post med `vp_token` og eventuelt `state`. `presentation_submission` sendes bare i kompatibilitetsflyter som bruker Presentation Exchange; OpenID4VP 1.0 bruker DCQL. Ved feil sendes `error`, `error_description` og eventuelt `state`. ## Vanlige feil du faktisk skal teste - Replay av gamle `request_uri`-er og `offer_uri`-er. - `state` som ikke matcher aktiv transaksjon hos relying party. - Callback som ikke godtar `application/x-www-form-urlencoded`. - Ulike forventninger til redirect versus direct-post. --- Source: https://www.symfoni.dev/docs/sikring/tillitsrammeverk # Tillitsrammeverk Et tillitsrammeverk avgjør hvilke utstedere, mottakere, sertifikater og roller en lommebok kan godta. ## Hva et tillitsrammeverk gjør Kryptografi kan vise at en bestemt nøkkel signerte noe. Tillitsrammeverket svarer på det neste spørsmålet: Har aktøren bak nøkkelen lov til å opptre som utsteder eller mottaker i denne sammenhengen? Det krever mer enn ett sertifikat: - et tillitsanker som miljøet godtar - en gyldig sertifikatkjede - registrering eller metadata som binder identiteten til en rolle - regler for gyldighet, status, tilbakekalling og rotasjon ## Hva som bindes i flytene - En utsteder bindes til metadata, bevisformat, signaturnøkkel og statusmekanisme. - En mottaker bindes til request object, `client_id`, `nonce`, `state` og callback. - Ved virksomhetsforsegling bindes også dokumenthash, transaksjonsid og leveringsorigin til forespørselen. - Lommeboken må kontrollere bindingene før brukeren deler eller godkjenner noe. ## Hva må virksomheten avklare? 1. Hvem bestemmer hvilke tillitsankere som godtas? 2. Hvordan registreres og fjernes en utsteder eller mottaker? 3. Hvem overvåker utløp og tilbakekalling av sertifikater og bevis? 4. Hvordan håndteres kompromitterte nøkler? 5. Hvilket minimum av kontroll skal logges uten å lagre flere personopplysninger enn nødvendig? Se [Tillit og sertifikater i Symfoni](/docs/virksomhetslommebok/tillitsrammeverk-og-sertifikater) for produktets konkrete bindinger. --- Source: https://www.symfoni.dev/docs/sikring/tillitslister-og-sertifikatkjeder # Tillitslister og sertifikatkjeder Tillitslister og sertifikatkjeder avgjør om en aktør faktisk er autorisert til å opptre som utsteder, mottaker eller tillitstjeneste. ## Hva denne siden svarer på Det er ikke nok å ha et sertifikat. Sertifikatet må inngå i en gyldig kjede som miljøet godtar. ## Hvordan tilliten materialiserer seg - en trust anchor sier hvilket rotnivå av tillit som kan brukes - en sertifikatkjede binder en konkret nøkkel tilbake til dette rotnivået - en rollepåstand eller registrering sier hva identiteten får lov til å gjøre ## Hvor dette blir synlig - issuer-flyter må kunne knyttes til en identitet som får utstede i den aktuelle konteksten - verifier-flyter må kunne knyttes til request object og callback - forsegling må i tillegg binde forespørsel, dokumenthash og leveringsorigin til samme transaksjon ## En praktisk kontrollrekkefølge 1. Verifiser at du bruker riktig sertifikat for riktig jobb. 2. Verifiser at kjeden er komplett nok til at motparten kan validere den. 3. Verifiser at rollen du prøver å utøve faktisk er tillatt for den identiteten. 4. Verifiser at miljøet du tester i bruker samme forventning til trust anchors som du gjør. ## Bro videre til Symfoni Når modellen er klar, gå til [Tillit og sertifikater i Symfoni](/docs/virksomhetslommebok/tillitsrammeverk-og-sertifikater) for de konkrete produktbindingene. --- Source: https://www.symfoni.dev/docs/status # Gyldighet og livsløp Følg et bevis fra tilbud og utstedelse til utløp eller tilbakekalling, og bestem hva mottakeren må lagre. ## Gyldig nå er ikke gyldig for alltid Et tilbud er ikke et utstedt bevis. Et utstedt bevis kan utløpe eller trekkes tilbake. En presentasjon gjelder én forespørsel, og et kontrollresultat må kunne knyttes til tidspunktet og saken. Les [Tilbakekalling og status](/docs/status/revokasjon-og-statuslister) for bevis og [Livssyklus for presentasjoner og forsegling](/docs/status/livssyklus-for-presentasjoner-og-signaturer) for mottakerens ansvar. --- Source: https://www.symfoni.dev/docs/status/revokasjon-og-statuslister # Revokasjon og statuslister Utstedelse og verifikasjon blir ikke ferdig idet et credential er levert; du må også ha kontroll på polling, tilbakekalling og hva som skjer når statusinformasjon er forsinket. ## Issuance-status i Symfoni Issuer-gatewayen i Symfoni lar deg polle `GET /api/issuers/{issuerSlug}/issuances/{issuanceId}` etter at du har opprettet et offer. Du må derfor lagre `issuanceId` fra opprettingssvaret hvis du trenger mer enn bare offerlenken. ## Webhookkvittering og forsinket status **Kompatibilitetsendring for Brreg og andre utstedere:** `200` fra Paradyms webhook-endepunkt betyr at hendelsen er autentisert og varig mottatt. Det betyr ikke at utstedelsesstatusen allerede er oppdatert. Hendelser behandles av en separat worker, og statusen kan derfor bli synlig senere enn kvitteringen. Duplikatleveringer kvitteres også med `200`; samme webhook-ID med motstridende innhold avvises. Workerens statusoppslag har ti sekunders tidsgrense. Feil og manglende lokal utstedelse forsøkes på nytt med økende ventetid, opptil ett minutt mellom forsøk. Prosessomstart mister ikke mottatte hendelser. Brregs EBWOID/EUCC-endepunkter, API-nøkler, malbindinger, payloads, idempotenskrav og svarformater er uendret. Bruk statusendepunktet dersom integrasjonen trenger bekreftet oppdatert status; webhookkvitteringen er ikke en slik bekreftelse. ## Relevante statuser - `offered`: tilbudet er opprettet, men ikke fullført. - `completed`: credentialet er utstedt og registrert som fullført. - `failed`: flyten strandet, ofte hos issuer eller i ekstern sesjon. - `partiallyIssued`: bare deler av bestillingen ble utstedt. - `revoked`: utstedelsen eller credentialet er tilbakekalt. ## Operative konsekvenser Hvis du tilbakekaller via `POST /api/issuers/{issuerSlug}/issuances/{issuanceId}/revoke`, må du forvente at gamle verifikasjonscaser kan avdekke den oppdaterte statusen senere enn GUI-en. Derfor bør relying party alltid validere presentasjoner mot relevante statusmekanismer i tillegg til signaturene. --- Source: https://www.symfoni.dev/docs/status/livssyklus-for-presentasjoner-og-signaturer # Livssyklus for presentasjoner og forsegling En robust integrasjon skiller mellom kortlivede protokollverdier, valideringsresultater og dokumenter som skal forvaltes i mottakerens sakssystem. ## Artefaktene har ulik levetid - Request object og `request_uri` er kortlivede innganger til flyten. - `state` og `nonce` skal brukes til én transaksjon. - `vp_token` og valideringsresultatet behandles av mottakeren. - Forseglede dokumenter skyves til mottakerens `dispatch.url`. - Historikk og saksdokumenter følger virksomhetens egne regler for arkiv, innsyn og sletting. ## Dette bør mottakeren lagre - egen saks- og transaksjonsid - `state`, `nonce` og relevante tidsstempler - resultatet av signatur-, binding-, gyldighets- og statuskontroll - dokumenthash og mottatt leveringsmanifest ved forsegling - teknisk leveringsstatus uten tokens eller dokumentinnhold i applikasjonsloggen ## Idempotens og gjenforsøk Behandle `transaction_id` som en idempotensnøkkel på mottakersiden. En identisk leveranse kan gjenkjennes uten å opprette to saksdokumenter. En leveranse med samme id, men andre hasher, skal avvises og undersøkes. Ikke gjenbruk en gammel `nonce` for å reparere en feilet flyt. Opprett en ny forespørsel og behold koblingen til opprinnelig sak. ## Avklar oppbevaring Symfoni-historikk er et teknisk revisjonsspor, ikke automatisk virksomhetens arkiv. Mottakeren må selv bestemme hva som er arkivpliktig, hvem som kan se dokumentene, og når data skal slettes. --- Source: https://www.symfoni.dev/docs/drift # Drift Teknisk referanse for miljøer, URL-er, interoperabilitet og nettverksforutsetninger i Symfoni-sandkassen. ## Hva du finner her Her finner du miljøer, endepunkter, testverktøy og de praktiske rammene som avgjør om eksterne tilbud, forespørsler, callbacker og dokumentlevering virker utenfor localhost. ## Videre lesning - [Miljøer og URL-er](/docs/drift/miljoer-og-url-er) - [Testdata og verktøy](/docs/drift/testdata-og-verktoy) - [EUDI Dev Hub interop](/docs/drift/eudi-dev-hub-interop) - [Interoperabilitet og kjente gap](/docs/drift/eudi-dev-hub-conformance) - [Callbacker, tilgjengelighet og feilbilder](/docs/drift/callbacker-tilgjengelighet-og-feilbilder) --- Source: https://www.symfoni.dev/docs/drift/miljoer-og-url-er # Miljøer og URL-er Velg riktig Symfoni-miljø og gjør eksterne callbacker og dokumentmottak tilgjengelige før dere tester en hel flyt. ## Miljøer | Miljø | URL | Bruk | | --- | --- | --- | | Lokal utvikling | `http://localhost:3000` | utvikling med `pnpm dev` | | Lokal test via tunnel | `https://chamois-amazed-deeply.ngrok-free.app` | eksterne forespørsler mot lokal app; adressen kan endres | | Delt test | `https://www.symfoni.dev` | pilot, demonstrasjon og ekstern integrasjon | Testmiljøet er ikke en produksjonsgaranti. Avklar tilgang, dataklassifisering og levetid på testdata med Symfoni før dere bruker reelle opplysninger. ## Viktige innganger - Motta bevis: `/app/credential/offer` - Dele bevis og forsegle dokument: `/app/credential/verify` - Utsteder-API: `/api/issuers/{issuerSlug}/...` - OpenAPI for det offentlige docs-API-et: `/openapi.json` - Forseglet dokumentlevering: mottakerens egen `dispatch.url` `/openapi.json` beskriver docs-API-et, ikke hele utsteder-API-et. ## Krav til eksterne endepunkter `response_uri`, dokument-URL-er og `dispatch.url` må være tilgjengelige fra miljøet som kjører Symfoni. Bruk HTTPS i delt test. Ikke legg hemmeligheter i query-parametere, og ikke bruk lokale eller private nettverksadresser i eksterne flyter. Symfoni bruker en kortvarig cache ved oppslag av offer og forespørsler for å tåle forhåndslasting og dobbel navigasjon. Ikke gjør engangs-URI-er så kortlivede at et vanlig brukerklikk rekker å utløpe dem. --- Source: https://www.symfoni.dev/docs/drift/callbacker-tilgjengelighet-og-feilbilder # Callbacker og dokumentmottak Feilsøk nettverk, utløp, callback og multipart-levering når en ellers riktig lommebokflyt stopper. ## Kontroller nettverket først Mange feil skyldes at partene ikke kan nå hverandre. Test endepunktene fra samme nettverk som Symfoni-miljøet bruker, ikke bare fra egen nettleser. ## Krav per endepunkt ### `response_uri` - må ta imot OpenID4VP `direct_post` - må kontrollere `state` og validere hele presentasjonen - må kunne håndtere protokollens feilrespons ### `dispatch.url` - må ta imot `multipart/form-data` med manifest og alle forseglede PDF-er - må kontrollere Bearer-tokenet - bør lagre manifest og dokumenter atomisk før den svarer 2xx - må ikke være avhengig av redirect; Symfoni følger ikke redirects ## Logg dette med korrelasjon - egen saksid, `state`, `nonce` og `transaction_id` - tidspunkt og HTTP-status for callback og dokumentlevering - om signatur-, hash-, status- eller trustkontroll feilet - hvilken del av flyten som eide feilen Ikke logg rå bevis, PDF-innhold, private nøkler eller Bearer-token. ## Typiske feil - `response_uri` er ikke offentlig tilgjengelig eller godtar ikke form-post. - `state` eller `nonce` er ukjent, utløpt eller gjenbrukt. - `dispatch.url` har feil origin eller peker til privat nettverk. - mottakeren avviser Bearer-tokenet eller forventer andre multipart-navn. - mottakeren svarer ikke 2xx etter at hele leveransen er lagret. Ved feil dokumentlevering skal saken ikke markeres som fullført. Bruk en ny, kontrollert transaksjon fremfor å gjenbruke gammel `nonce`. --- Source: https://www.symfoni.dev/docs/drift/testdata-og-verktoy # Testdata og verktøy Denne siden samler de viktigste lokale verktøyene, testkommandoene og praktiske datapunktene du trenger for å gjøre meningsfulle sandbox-eksperimenter uten å reverse-engineere repoet. ## Verktøy du allerede har i repoet Denne sandboxen krever ikke at du starter med blanke ark. Repoet inneholder flere nyttige innganger for test, observasjon og feilsøking. ## Kommandoer som gir deg signal raskt - `pnpm dev` starter lokal app på `http://localhost:3000` - `pnpm check` validerer SvelteKit- og TypeScript-kontrakter - `pnpm test:unit` kjører vitest, inkludert docs-manifestet - `pnpm test:integration --grep docs` kjører Playwright mot docs-opplevelsen - `pnpm users:recent -- --days=14` viser nylig aktive brukere - `pnpm issuers:usage --month=2026-03` viser issuer-bruk per måned ## Lett EUDI Dev Hub-spor For standard-interoperabilitet mot EUDI Dev Hub bruker vi de samme Playwright-testene som ellers, men med live URI-er fra EUDI-verktøyene: - `TEST_CREDENTIAL_OFFER_URI=... pnpm test:integration:live --grep OID4VCI` - `TEST_CREDENTIAL_OFFER_URI=... TEST_PRESENTATION_REQUEST_URI=... pnpm test:integration:live --grep "should display presentation request UI elements"` Detaljert runbook ligger på [EUDI Dev Hub interop](/docs/drift/eudi-dev-hub-interop). Norsk sandbox er fortsatt primær akseptanse for EBWOID og de norske tillitsflytene. ## EUDI conformance-spor Når du vil kjøre strengere EUDI-spor uten å bruke opp engangs-URI-er ved et uhell, bruk egne conformance-gates: - `TEST_EUDI_CONFORMANCE_TRACK=1 TEST_EUDI_CREDENTIAL_OFFER_URI=... pnpm test:integration:live --grep "Full Credential Issuance Flow"` - `TEST_EUDI_CONFORMANCE_TRACK=1 TEST_EUDI_CREDENTIAL_OFFER_URI=... TEST_EUDI_PRESENTATION_REQUEST_URI=... pnpm test:integration:live --grep "should display presentation request UI elements"` - `TEST_EUDI_CONFORMANCE_TRACK=1 TEST_EUDI_SUBMIT_PRESENTATION=1 TEST_EUDI_CREDENTIAL_OFFER_URI=... TEST_EUDI_PRESENTATION_REQUEST_URI=... pnpm test:integration:live --grep "should complete presentation exchange"` Scope, pass/fail og gap-klassifisering ligger på [EUDI Dev Hub conformance-spor](/docs/drift/eudi-dev-hub-conformance). ## Nyttige testflater i applikasjonen - `/app/mottak` for valg av opplysninger, test og integrasjon gjennom Symfoni/Credo - `/api/integrations/v1/sessions` for kundens backend-integrasjon med Symfoni-nøkkel - `/api/test/create-vp-request` for intern opprettelse av OpenID4VP-request mot en statisk test-PDF - `/api/test/vp-callback` for mock verifier-callback i development, med de siste svarene tilgjengelig via `GET` ## Testdata du bør kontrollere - miljøet du peker mot: localhost, ngrok eller delt test - hvilke credentials som allerede ligger i walleten - hvilke templates og issuer-profiler som finnes - om `state`, `nonce` og `issuanceId` logges eller lagres hos din egen tjeneste ## Bro videre til Symfoni Når du har kontroll på verktøy og testdata, bruk [scenarier](/docs/scenarier) for å velge et konkret forløp og gå derfra videre til riktig Symfoni-guide. --- Source: https://www.symfoni.dev/docs/drift/eudi-dev-hub-interop # EUDI Dev Hub interop Lett EUDI Dev Hub-testing brukes som tidlig interoperabilitetssjekk for OpenID4VCI og OpenID4VP, mens norsk sandbox fortsatt er akseptansegrunnlaget for forretningsflytene. ## Hvorfor dette sporet finnes Norsk sandbox er primær akseptansetest for domenet: BRREG/Altinn EBWOID, norske tillitskjeder og Symfoni-flytene. EUDI Dev Hub brukes i tillegg som et lett interoperabilitetsspor for standardprotokollene. Målet er å oppdage avvik i `credential_offer`, `request_uri`, `response_uri`, SD-JWT-VC-format og verifier-respons før de låser seg fast i demo- og produktflyter. Dette er ikke full ARF-conformance. Første runde skal bare gi et praktisk signal om at walleten oppfører seg rimelig mot EUDI reference tooling. Neste nivå er dokumentert i [EUDI Dev Hub conformance-spor](/docs/drift/eudi-dev-hub-conformance), med must/should/could, egne `TEST_EUDI_*` gates og tydelig skille mellom automatisk test, manuell runbook, produktkode og utsatte gap. ## Kilder og testflater - EUDI Dev Hub: [Testverktøy](https://docs.eudi.dev/latest/test/) - EUDI issuer-test: [Issuer](https://docs.eudi.dev/latest/test/issuer/) - EUDI reference repositories: [Repositories list](https://docs.eudi.dev/latest/reference-implementation/repositories-list/) - ARF-protokolloversikt: [Architecture and reference framework](https://eudi.dev/latest/architecture-and-reference-framework-main/) Bruk spesielt EUDI issuer eller advanced issuer tester for SD-JWT-VC issuance, og EUDI online verifier når credential type og request matcher det walleten faktisk støtter. ## Forutsetninger - Appen kjører lokalt på `http://localhost:3000` eller med offentlig ingress via `pnpm dev:ngrok`. - Testbrukeren finnes lokalt, normalt `test` / `test`. - Offeret er SD-JWT-VC. Walleten avviser foreløpig andre credential records i offerflyten. - Request URI fra verifier ber om en credential type walleten har lagret. - Engangs-URI-er må leve lenge nok til browser-prefetch og walletens korte resolve-cache. ## Issuance med EUDI issuer 1. Start appen med offentlig URL hvis issuer må kalle tilbake til lokal maskin: ```bash pnpm dev:ngrok ``` 2. Hent et SD-JWT-VC credential offer fra EUDI issuer eller advanced issuer tester. Hvis issuer viser en "Use Wallet Tester"-lenke med `credential_offer` og `tx_code`, kan hele den lenken brukes som `TEST_CREDENTIAL_OFFER_URI`. 3. Kjør OID4VCI-testen med eksisterende env-var: ```bash TEST_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...' pnpm test:integration:live --grep OID4VCI ``` 4. Verifiser at credentialet ble lagret og vises i wallet UI. 5. Hvis testen feiler, noter konkret hvor feilen ligger: offer-resolving, issuer metadata, token/credential endpoint, SD-JWT-VC record, x509-trust, lagring eller UI-visning. `test:integration:live` rydder den lokale testwalleten når prosessen avsluttes. For en sammenhengende issuance→presentation-flyt må begge URI-ene kjøres i samme fokuserte Playwright-kjøring. ## Remote presentation med EUDI verifier 1. Hent både et nytt SD-JWT-VC-offer og en verifier-request som matcher credentialet. Den isolerte testwalleten opprettes på nytt for hver kommando. 2. Opprett en EUDI verifier-request med `Person Identification Data (PID)`, `dc+sd-jwt`, `OpenID4VP` og `GET`. 3. Hvis verifieren tilbyr "Specific attributes", start med felter som finnes i testcredentialet, for eksempel `Family name`, `Given name` og `Birthdate`. "All attributes" kan gi korrekt request-resolving, men likevel ende i "Ingen passende bevis funnet" hvis issuer ikke har utstedt alle feltene. 4. Kopier `OPEN WITH YOUR WALLET`-lenken. Den er normalt på formen `openid4vp://?client_id=...&request_uri=...&request_uri_method=get`. 5. Kjør issuance og nøyaktig én OID4VP-test i samme prosess: ```bash TEST_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...' \ TEST_PRESENTATION_REQUEST_URI='openid4vp://?client_id=...&request_uri=...&request_uri_method=get' \ pnpm test:integration:live --grep "should display presentation request UI elements" ``` 6. Verifiser minst at walleten kan åpne requesten, validere request object, matche credential og vise hva som etterspørres. 7. Hvis presentasjonen ikke kan fullføres, dokumenter årsaken presist som gap. Ikke la det stå igjen som en ukjent feil. ## Live EUDI-run 2026-05-08 Dette ble kjørt manuelt mot EUDI issuer/verifier med Playwright: - Issuance: `PID (SD-JWT VC)` fra EUDI issuer med `Pre-Authorization Code Grant` og `tx_code` bestod. Integrasjonstesten `TEST_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...&tx_code=...&credential_offer=...' pnpm test:integration:live --grep 'Full Credential Issuance Flow'` passerte, og credentialet ble lagret og vist i UI. - Trust: EUDI issuer-kjeden manglet i lokal trust store, så Credo traff eksisterende X.509-fallback og lagret credentialet uten full kryptografisk signaturverifisering. Dette er et trust-materiale-gap, ikke et offer parsing-gap. - Presentation request: EUDI verifier med `All attributes` ga en gyldig request, men walleten fant ingen matchende credential fordi requesten var bredere enn den utstedte PID-en. - Presentation request: EUDI verifier med `Specific attributes` = `Family name`, `Given name`, `Birthdate`, format `dc+sd-jwt`, profil `OpenID4VP`, method `GET` ble løst av walleten og matchet `1 bevis`. - Presentation delivery: Første forsøk stoppet ved KB-JWT-signering fordi en eldre EUDI PID var lagret uten `kmsKeyId` for holder-bindingen. Etter fixen for jwk-til-kms-key mapping ble en ny EUDI PID utstedt til en ren testbruker, samme verifier-request ble kjørt på nytt, `Del bevis` sendte direct_post, og EUDI verifier viste `1 documents` for `urn:eudi:pid:1` i `dc+sd-jwt` format. Konkret oppfølging etter live-run: 1. Bruk en ren testbruker eller slett gamle EUDI PID-er før ny VP-test. Eldre credentials som ble lagret før `kmsKeyId`-fixen kan fortsatt bli valgt først og feile ved KB-JWT-signering. 2. Legg EUDI issuer CA/intermediate inn i lokal trust store for å fjerne X.509-fallbacken. Inntil det er gjort, er interop-resultatet protokollmessig nyttig, men ikke en full kryptografisk trust-godkjenning. 3. Automatiser samme smale EUDI verifier-request når Dev Hub tilbyr stabile fixtures eller et API som ikke krever manuell browser-opprettelse av engangs-URI. Typiske gap er mismatch mellom verifierens credential query og lagret credential, krav til mDoc/proximity, annen client binding enn walleten støtter, eller trust-materiale som ikke finnes i lokal konfigurasjon. ## Ikke-mål i første runde - mDoc og proximity testing. - Deferred og dynamic issuance hvis hosted issuer krever mer enn eksisterende Credo-holderflyt håndterer. - Wallet Instance Attestation, Key Attestation og en komplett Wallet Unit-modell. - Full conformance mot ARF eller nasjonal sertifisering. ## Akseptansekriterier - Norsk sandbox-flyt med EBWOID fungerer fortsatt som domeneakseptanse. - EUDI SD-JWT-VC offer kan løses, aksepteres, lagres og vises. - EUDI OpenID4VP request kan åpnes og presenteres i wallet UI. - Alle avvik skrives som konkrete gap med kilde, request type, miljø og feilsteg. --- Source: https://www.symfoni.dev/docs/drift/eudi-dev-hub-conformance # Interoperabilitet og kjente gap Se hva Symfoni har testet mot europeiske verktøy, hva produktet støtter, og hvilke områder som fortsatt er åpne. ## Kort svar Symfoni kan brukes til interoperabilitetstesting av SD-JWT VC, OpenID4VCI og remote OpenID4VP. Produktet har ingen EUDI-sertifisering eller framtidig EBW-leverandørautorisasjon, og testresultatene skal ikke omtales som full konformitet. Dette er særlig viktig for virksomhetslommebøker: Gjeldende EUDI Architecture and Reference Framework har tatt temaet lommebokenheter for juridiske personer ut i lys av arbeidet med en egen European Business Wallet. Se [EUDI Wallet, Business Wallet og Symfoni](/docs/kom-i-gang/eudi-business-wallet-og-symfoni). ## Status per 20. august 2026 | Område | Symfoni-status | Teststatus | | --- | --- | --- | | SD-JWT VC | støttet | automatiske produkt- og protokolltester | | OpenID4VCI, forhåndsautorisert kode | støttet | automatiske tester og manuelle eksterne løp | | OpenID4VCI, autorisasjonskode | støttet med miljøoppsett | automatiske tester; ekstern registrering må settes opp | | Utsatt utstedelse | eksperimentelt og eksplisitt aktivert | manuell polling og avgrensede tester | | Remote OpenID4VP | støttet | automatiske tester og manuelle eksterne løp | | DCQL | støttet mot OpenID4VP 1.0 | automatiske tester | | Presentation Exchange | kompatibilitet med eldre OpenID4VP-utkast | automatiske tester | | Tillitsvalidering av ekstern X.509-kjede | delvis miljøavhengig | må verifiseres med riktig test-CA og metadata | | mdoc | ikke støttet | tilbud avvises kontrollert | | Proximity via QR, Bluetooth eller NFC | ikke støttet | ikke testet som produktflyt | | Wallet Instance Attestation og Key Attestation | ikke støttet | ikke testet som produktflyt | | EUDI-sertifisering eller framtidig EBW-leverandørautorisasjon | ikke gjennomført | ingen godkjenningspåstand | ## Hva en interoperabilitetstest skal dokumentere For hvert eksternt løp bør dere lagre: - dato, miljø og versjon av testverktøyet - protokoll, grant-type, format og bevisprofil - hvilken utsteder og mottaker som deltok - hvilke tillitsankere som var konfigurert - forventet resultat, faktisk resultat og kjent avvik - om testen var automatisk, manuell eller bare en negativ test Et teknisk svar er ikke nok. Kontroller også at brukeren forstår hvem som ber om data, hva som deles, og hva et avslag betyr. ## Kjente avgrensninger - En vellykket lokal test beviser ikke interoperabilitet med alle utstedere og mottakere. - Et testsertifikat eller en lokal tillitsrot er ikke produksjonstillit. - mdoc-, proximity- og attestasjonskrav krever andre komponenter enn dagens webbaserte SD-JWT-flyt. - Symfoni har ingen komplett modell for delegert virksomhetsadministrasjon, roller eller fullmakt. - European Business Wallet-regelverket og de tilhørende tekniske spesifikasjonene er fortsatt under utvikling. ## Eksterne testkilder - [EUDI Dev Hub: Testverktøy](https://docs.eudi.dev/latest/test/) - [EUDI Dev Hub Issuer](https://docs.eudi.dev/latest/test/issuer/) - [EUDI Dev Hub Online Verifier](https://docs.eudi.dev/latest/test/online-verifier/) - [OpenID4VCI 1.0 Final](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html) - [OpenID4VP 1.0 Final](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) - [EUDI ARF, siste publiserte versjon](https://eudi.dev/latest/) Bruk [EUDI Dev Hub interop](/docs/drift/eudi-dev-hub-interop) som praktisk testguide og [Hva kan brukes nå?](/docs/virksomhetslommebok/hva-kan-brukes-na) som produktavgrensning. --- Source: https://www.symfoni.dev/docs/scenarier # Tekniske ende-til-ende-flyter Følg utstedelse, deling og virksomhetsforsegling på tvers av aktørene og se hvilke verdier hver part må kontrollere. ## Velg flyt - [Fra utsteder til mottaker](/docs/scenarier/issuer-til-verifier) viser et bevis fra tilbud til validert presentasjon. - [Verifikasjon med virksomhetsforsegling](/docs/scenarier/verifikasjon-med-signering) viser bevisdeling, eSeal og dokumentlevering. For forretningsnære mønstre, gevinster og pilotspørsmål går du til [Bruksområder](/docs/bruksomrader). --- Source: https://www.symfoni.dev/docs/scenarier/issuer-til-verifier # Fra utsteder til mottaker Følg et digitalt bevis fra fagsystemets utstedelse, via virksomhetens lommebok, til en mottaker som kontrollerer opplysningene. ## Målet En utsteder gir virksomheten et digitalt bevis. Senere deler virksomheten nødvendige opplysninger med en mottaker som kontrollerer dem maskinelt. ## Flyten 1. Fagsystemet oppretter et tilbud via Symfonis utsteder-API. 2. Fagsystemet lagrer `issuanceId` og sender tilbudslenken til riktig virksomhet. 3. Virksomheten godkjenner tilbudet, og Symfoni validerer og lagrer beviset. 4. Mottakeren lager en OpenID4VP-forespørsel med DCQL, `response_uri`, `nonce` og `state`. 5. Virksomheten godkjenner hvilke opplysninger som deles. 6. Symfoni sender `vp_token` og tilhørende `state` til callbacken. 7. Mottakeren validerer hele presentasjonen før dataene brukes. ## Ansvar og korrelasjon - Utstederen lagrer `issuanceId`, bevismal, kilde og eventuell tilbakekallingsreferanse. - Mottakeren lagrer `state`, `nonce`, forespørsel og kontrollresultat. - Symfoni oppbevarer beviset og fører teknisk hendelseshistorikk for lommeboken. Ingen av partene bør bruke samme identifikator som hemmelighet. Private nøkler, API-nøkler og rå bevis krever egen beskyttelse. ## Typiske brudd - feltene passer ikke bevismalen ved utstedelse - mottakeren spør etter et annet format eller andre felt enn lommeboken har - `state` eller `nonce` er utløpt, ukjent eller gjenbrukt - tillit, gyldighet eller status blir ikke kontrollert hos mottakeren Kjør [utstederguiden](/docs/virksomhetslommebok/issuer/kom-i-gang) først og deretter [verifikatorguiden](/docs/virksomhetslommebok/verifikasjon/kom-i-gang). --- Source: https://www.symfoni.dev/docs/scenarier/verifikasjon-med-signering # Verifikasjon med virksomhetsforsegling Kombiner deling av virksomhetsbevis med brukerautorisert eSeal og sikker levering av forseglede PDF-er. ## Når passer dette? Bruk flyten når en mottaker trenger både et virksomhetsbevis og en PDF med elektronisk virksomhetssegl. Seglet har som formål å sikre dokumentets opprinnelse og integritet. Det er noe annet enn en persons elektroniske signatur. ## Slik går flyten 1. Mottakeren lager en OpenID4VP-forespørsel med `transaction_data`, unik `nonce` og en offentlig `response_uri`. 2. `transaction_data` beskriver dokumentene, dokumenthashene og mottakerens `dispatch.url` med et kortlivet Bearer-token. 3. Brukeren åpner forespørselen i Symfoni, kontrollerer virksomhet og dokumenter og godkjenner handlingen. 4. Symfoni kontrollerer dokumenthashene og forsegler PDF-ene med Signant eSeal. 5. Symfoni sender de forseglede PDF-ene som `multipart/form-data` til `dispatch.url`. 6. Mottakeren får også den vanlige OpenID4VP-responsen på `response_uri`. Dokumentene skyves til mottakeren. De hentes ikke fra et eget Symfoni-endepunkt. ## Dette må henge sammen - `credential_ids` må vise til bevisforespørselen. - Hvert dokument må ha korrekt SHA-256-hash. Mottakeren bør kreve unike id-er; dagens prototype avviser ikke duplikater før multipart bygges. - `transaction_id` må identifisere mottakerens sak. - `dispatch.url` må være en tillatt HTTPS-origin knyttet til forespørselen. - Mottakeren må validere OpenID4VP-responsen og behandle dokumentleveransen som samme forretningstransaksjon. ## Dette bør mottakeren lagre - egen saks- eller transaksjonsid - `state`, `nonce` og `transaction_id` - dokumenthashene og mottatt manifest - resultatet av OpenID4VP-valideringen - leveringstidspunkt og HTTP-status for dokumentene Ikke logg Bearer-tokenet eller innholdet i dokumentene. Se [Virksomhetsforsegling: kom i gang](/docs/virksomhetslommebok/signering/kom-i-gang) for payload og mottakskontrakt. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok # Bruk Symfoni Se hva Symfoni gjør i dag, prøv en av de støttede flytene og gå videre til tekniske guider for utstedelse, verifikasjon eller virksomhetsforsegling. ## Plattformen kort fortalt Symfoni samler flere roller i én plattform: - virksomhetslommebok for å motta, oppbevare og dele bevis - utsteder for å lage bevis fra egne data - verifikator for å be om og kontrollere bevis - brukerautorisert virksomhetsforsegling av PDF-dokumenter - historikk for hendelser i disse flytene Dette er en prototype og sandkasseplattform. Se [Hva kan brukes nå?](/docs/virksomhetslommebok/hva-kan-brukes-na) før du planlegger en pilot. Siden skiller mellom tilgjengelig, manuelt oppsett, eksperimentelt og ikke støttet. ## Velg oppgaven din - Vil du prøve lommeboken som bruker? Start med [Kom i gang med Symfoni](/docs/virksomhetslommebok/kom-i-gang). - Vil fagsystemet utstede et bevis? Bruk [utstederguiden](/docs/virksomhetslommebok/issuer/kom-i-gang). - Vil tjenesten be om bevis? Bruk [verifikasjonsguiden](/docs/virksomhetslommebok/verifikasjon/kom-i-gang). - Vil tjenesten få en PDF forseglet? Bruk [guiden for virksomhetsforsegling](/docs/virksomhetslommebok/signering/kom-i-gang). ## Hva Symfoni ikke avgjør Kunden må fortsatt eie formål, behandlingsgrunnlag, dataminimering, arkivkrav, tjenesteflyt og vurderingen av bevisets rettsvirkning. En gyldig signatur identifiserer signeringsnøkkelen og viser at dataene ikke er endret. En validert sertifikatkjede eller annen tillitsbinding må knytte nøkkelen til aktøren. Ingen av kontrollene sier alene at innholdet er riktig eller tilstrekkelig for et vedtak. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/hva-kan-brukes-na # Hva kan brukes nå? En ærlig kapabilitetsmatrise for Symfoni-sandkassen viser hva som virker, hva som krever manuelt oppsett, og hva som ikke er implementert. ## Tilgjengelig i sandkassen - Motta og oppbevare SD-JWT VC-bevis med OpenID4VCI. - Dele bevis med ekstern tjeneste gjennom OpenID4VP. - Velge opplysninger og starte mottak gjennom Symfoni/Credo. - Opprette utstedermaler, API-nøkler og bevis-tilbud. - Følge status og trekke tilbake utstedelser. - Vise historikk for mottak, deling, utstedelse, verifikasjon og forsegling. - Forsegle én eller flere PDF-er med Signant eSeal og sende resultatet til mottakeren. ## Krever manuelt oppsett - Hente EBWOID fra Brønnøysundregistrenes testtjeneste og lime inn tilbudslenken. - Koble en utstederprofil til et Paradym-prosjekt. - Legge inn eksterne tillitsrøtter. - Konfigurere Signant og godkjent leveringsendepunkt. - Gjøre callback- og dokument-URL-er offentlig tilgjengelige. ## Eksperimentelt - Deferred issuance. - HAIP- og conformance-spor. Eksperimentelle funksjoner kan endres og bør ikke være kritisk avhengighet i en pilot uten egen avtale. Se [Data, nøkler og lagring](/docs/virksomhetslommebok/data-nokler-og-lagring) for et viktig prototypegap: forseglede PDF-er lagres i dag i `app.db` uten ferdig automatisk opprydding. ## Ikke støttet nå - mdoc og proximity-flyter. - Wallet Instance Attestation og Key Attestation i en komplett Wallet Unit-modell. - Presentation during issuance. - Full ARF-conformance eller EUDI-sertifisering. - Komplett rolle-, RBAC-, delegasjons- eller fullmaktsmodell for en virksomhet. ## Pilot og demo «Enkel Servering» og «Kompetansespor» må leses som pilot eller demo. «Motta opplysninger» bruker Symfoni/Credo og støtter tre Digdir-bevistyper: medlemskap, ansettelse og trafikalt grunnkurs. Denne siden beskriver kodebasen slik den er 20. august 2026. Bruk [Kilder og status](/docs/kilder-og-status) for regulatorisk status. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/kom-i-gang # Kom i gang med Symfoni Opprett en testkonto, hent virksomhetsidentiteten og prøv å motta, dele eller utstede et digitalt bevis i sandkassen. ## Før du begynner Symfoni er et testmiljø. Bruk syntetiske data, og ikke legg inn produksjonshemmeligheter eller dokumentasjon som ikke er godkjent for piloten. Du trenger: - en konto i Symfoni - tilgang til riktig sandkasse og testvirksomhet - en tilbudslenke for et bevis, eller en verifikasjonsforespørsel - en offentlig callback hvis et eksternt fagsystem skal motta svar ## 1. Opprett lommeboken Registrer en testkonto og følg onboarding i appen. Dagens løsning bruker brukernavn og passord. Rollebasert virksomhetsadministrasjon er ikke ferdig produktfunksjon. ## 2. Hent virksomhetsidentiteten I norsk sandkasse utsteder Brønnøysundregistrene et foreløpig EBWOID fra syntetiske testdata. Klikk **«Hent virksomhetsbevis hos Brønnøysundregistrene»** i Symfoni. Logg inn med TestID / ID-porten test på høyt nivå, velg virksomheten og bestill beviset. Du sendes automatisk tilbake til Symfoni med tilbudet. Se gjennom tilbudet og klikk **«Legg til i lommeboken»**. Når beviset er mottatt, vises det som **Virksomhetsbevis**. Kontroller navn, identifikator, utsteder og tillitsstatus. ## 3. Velg en flyt - [Utsted et bevis](/docs/virksomhetslommebok/issuer/kom-i-gang) fra et fagsystem. - [Be om og kontroller et bevis](/docs/virksomhetslommebok/verifikasjon/kom-i-gang). - [Forsegl et PDF-dokument](/docs/virksomhetslommebok/signering/kom-i-gang) etter brukerens godkjenning. ## Tekniske innganger Et OpenID4VCI-tilbud åpnes slik: ```text https://www.symfoni.dev/app/credential/offer?credential_offer_uri= ``` En OpenID4VP-forespørsel åpnes slik: ```text https://www.symfoni.dev/app/credential/verify?request_uri= ``` Eksterne integrasjoner skal bruke `credential_offer_uri`, `request_uri` eller `authorization_request`. Interne testparametre er ikke en del av produktkontrakten. ## Forventet resultat Du skal kunne se beviset i lommeboken og hendelsen i historikken. Ved deling skal mottakeren kunne knytte svaret til egen transaksjon. Hvis dette ikke skjer, gå til [miljøer og URL-er](/docs/drift/miljoer-og-url-er) før du feilsøker protokollen. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/data-nokler-og-lagring # Data, nøkler og lagring Se hvor Symfoni-prototypen lagrer kontoer, bevis, nøkler, historikk og forseglede dokumenter, og hvilke produksjonsgap som gjenstår. ## Lagring i dagens prototype | Data | Lagring | Merknad | | --- | --- | --- | | brukere, sesjoner, tokens og lommebokmetadata | `app.db` | applikasjonsdata i SQLite | | bevis og private lommeboknøkler | Askar-profiler under `~/.afj/data/wallet/root/` | én profil per lommebok gir teknisk tenant-skille | | hendelseshistorikk | `historikk.db` | teknisk spor for mottak, deling, utstedelse, verifikasjon og forsegling | | forseglede PDF-er | base64 i signaturrecords i `app.db` | full dokumentkopi lagres i prototypen | Historikken er ikke automatisk virksomhetens arkiv, og tenant-profiler er ikke det samme som en komplett modell for organisasjonsroller og delegert administrasjon. ## Åpent gap for forseglede dokumenter Signaturrecorden har metadata om utløp, men nedlastingsruten håndhever ikke dette fullt ut, og automatisk opprydding av dokumentkopiene er ikke implementert. Inntil dette er rettet og verifisert: - bruk bare godkjente testdokumenter - ikke anta at en utløpt lenke betyr at dokumentet er slettet - avklar sletting og backup før hver pilot - la mottakerens fagsystem være ansvarlig arkiv når leveransen er fullført ## Før produksjon Virksomheten må dokumentere kryptering, tilgangsstyring, nøkkelrotasjon, backup, gjenoppretting, sletting, datalokalitet og hendelseshåndtering. Test også tenant-isolasjon og gjenoppretting med egne sikkerhetskrav. Ikke lagre private nøkler eller API-nøkler i kildekode, logger eller vanlige saksdata. Begrens teknisk historikk til det som trengs for drift og revisjon. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/tillitsrammeverk-og-sertifikater # Tillit og sertifikater i Symfoni Se hvilke identitets- og transportbindinger Symfoni kontrollerer ved utstedelse, verifikasjon og virksomhetsforsegling. ## 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:`. 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_id` inneholder feil sertifikathash. - Sertifikatkjeden ender ikke i et tillitsanker miljøet kjenner. - `nonce` eller `state` er utløpt, ukjent eller gjenbrukt. - `dispatch.url` har 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. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/issuer # Utstede bevis Bruk Symfoni til å definere et digitalt bevis, opprette et tilbud fra fagsystemet og følge eller tilbakekalle utstedelsen. ## Hva Symfoni gjør Utstederfunksjonen kobler et fagsystem til en bevismal. Fagsystemet sender attributtene, får en tilbudslenke og kan senere følge status eller tilbakekalle et utstedt bevis. Symfoni avgjør ikke om kildedataene er riktige eller om virksomheten har hjemmel til å utstede. Utstederen må eie datakvalitet, regelbok, gyldighet og feilretting. ## Før dere integrerer - avklar hvilke felt mottakeren faktisk trenger - velg autentisk kilde for hvert felt - definer utløp og tilbakekalling - få en Symfoni-utstederprofil og et Paradym-prosjekt satt opp manuelt - opprett en bevismal og en API-nøkkel Gå til [Utsteder-API: kom i gang](/docs/virksomhetslommebok/issuer/kom-i-gang) for endepunkter og eksempel. [Brønnøysundregistrene](/docs/virksomhetslommebok/issuer/gateways/brreg) viser en tjenestespesifikk testkonfigurasjon. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/issuer/kom-i-gang # Utsteder-API: kom i gang Opprett et bevis-tilbud fra fagsystemet, lagre `issuanceId`, følg status og tilbakekall beviset ved behov. [![Utstederflyt i Symfoni](/docs/diagrams/issuer-flow.svg)](/docs/diagrams/issuer-flow.svg) [Åpne diagrammet i full størrelse](/docs/diagrams/issuer-flow.svg). ## Før du begynner En administrator må ha opprettet utstederprofilen og koblet den til et Paradym-prosjekt. Deretter trenger du: 1. en bevismal med stabil `templateSlug` 2. en Symfoni-API-nøkkel; den vises bare én gang 3. testdata som følger feltene og datatypene i malen Hold API-nøkkelen på serveren. Ikke legg den i nettleser, mobilapp eller URL. ## 1. Opprett et tilbud ```http POST /api/issuers/{issuerSlug}/credentials/{templateSlug}/issue Authorization: Bearer Content-Type: application/json ``` ```bash curl -X POST "https://www.symfoni.dev/api/issuers/brreg/credentials/euwoid/issue?offerUrlFormat=symfoni" \ -H "Authorization: Bearer $SYMFONI_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: " \ -d '{ "attributes": { "organizationnumber": "999888777", "legalname": "Eksempelvirksomheten AS" } }' ``` Feltnavnene er malavhengige. Eksempelet er ikke en generell EBWOID-regelbok. ## 2. Lagre svaret ```json { "issuanceId": "9357a8ce-f1c5-4d2d-b0d9-f20dd80fd770", "offerUri": "https://www.symfoni.dev/app/credential/offer?credential_offer_uri=...", "status": "offered", "templateSlug": "euwoid", "offerUrlFormat": "symfoni" } ``` Send `offerUri` til riktig mottaker gjennom en avtalt kanal. Lagre `issuanceId` som teknisk korrelasjonsnøkkel. ## 3. Følg status ```http GET /api/issuers/{issuerSlug}/issuances/{issuanceId} Authorization: Bearer ``` Ikke behandle `offered` som et ferdig utstedt bevis. Les den returnerte statusen og sett et tidsavgrenset pollingsintervall i eget fagsystem. ## 4. Tilbakekall ved behov ```http POST /api/issuers/{issuerSlug}/issuances/{issuanceId}/revoke Authorization: Bearer ``` Tilbakekalling virker først etter at et bevis er utstedt. Gjentatte eller umulige kall gir en kontrollert feil. ## Feil du må håndtere - `400` for ugyldig JSON, feil felt, datatype eller umulig tilbakekalling - `401` eller `403` for manglende, ugyldig eller utilstrekkelig API-nøkkel - `404` når profil, mal eller utstedelse ikke finnes for denne klienten - `409` når konfigurasjonen endres mens tilbudet opprettes - `500` ved uventet avhengighets- eller systemfeil Bruk egen request-id og idempotenslogikk rundt kallene. Det offentlige `/openapi.json` beskriver foreløpig docs-API-et, ikke denne utstederkontrakten. ## Sikre gjentatte utstedelseskall Send `Idempotency-Key` (1–200 tegn) på hvert utstedelseskall. `x-request-id` støttes som alternativ når `Idempotency-Key` mangler. Bruk samme nøkkel og samme feltverdier når et kall må gjentas. Gatewayen returnerer det lagrede tilbudet uten å utstede på nytt. En nøkkel med endrede felt gir `409 idempotency_conflict`; en ny tilsiktet utstedelse skal ha en ny nøkkel. Ved `issuance_reconcile_required` kan samme nøkkel gjentas for å fullføre lokal lagring. Ved `issuance_outcome_unknown` skal du ikke bytte nøkkel eller automatisk prøve en ny utstedelse: operasjonen må avstemmes mot utsteder først. Dette beskytter mot duplikater etter tidsavbrudd hvor utsteder allerede kan ha opprettet tilbudet. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/issuer/gateways/brreg # Brønnøysundregistrene: testintegrasjon Konfigurer testutstedelse for virksomhetsidentitet med riktig utstederprofil, bevismal og Symfoni-API-nøkkel. ## Status Dette er en sandkassekonfigurasjon for testdata. EBWOID er en foreløpig virksomhetsidentitet i sandkassen og skal ikke beskrives som et ferdig produksjonsbevis. ## Konfigurasjon I den nåværende testprofilen er `issuerSlug` satt til `brreg`. Fagsystemet trenger: - base-URL: `https://www.symfoni.dev/api/issuers/brreg` - avtalt `templateSlug`, for eksempel `euwoid` - egen Symfoni-API-nøkkel ```bash curl -X POST "https://www.symfoni.dev/api/issuers/brreg/credentials/euwoid/issue?offerUrlFormat=symfoni" \ -H "Authorization: Bearer $SYMFONI_BRREG_API_KEY" \ -H "Idempotency-Key: " \ -H "Content-Type: application/json" \ -d '{ "attributes": { "organizationnumber": "999888777", "legalname": "Eksempelvirksomheten AS" } }' ``` Bruk bare feltene som finnes i den konfigurerte malen. Virksomhetsnavn og organisasjonsnummer må komme fra avtalt testkilde. `attributes` støtter også nestede objekter og lister når malen definerer disse typene. Send ekte JSON-objekter og lister, og bruk malens eksakte tekniske feltnøkler. Serveren avviser ukjente felt, feil datatype og manglende påkrevde underfelt med HTTP 400 og `error.code = "invalid_payload"`. Feilmeldingen angir feltstien, for eksempel `registered_address.full_address` eller `representatives[0].legal_name`. Responsformatet er det samme som ved utstedelse med flate felt. ## EUCC For EU Company Certificate brukes `templateSlug=eucc` og den versjonsfestede [EUCC-kontrakten](/docs/virksomhetslommebok/issuer/gateways/eucc). EUCC endrer ikke EBWOIDs rolle som virksomhetsidentitet. ## Direkte retur fra Altinn til Symfoni Brregs lenkede EBWOID-flyt sender brukeren automatisk tilbake til Symfoni med tilbudet etter bestilling. Ved integrasjon med en eksplisitt returlenke åpnes den i samme fane. Bruk helst `offerUri` fra utstedelses-API-et direkte som lenkens `href`. Eksempelet over ber eksplisitt om `offerUrlFormat=symfoni`; responsen inneholder da en ferdig returlenke. Ikke URL-kod hele `offerUri` på nytt eller legg den inni en ny `credential_offer_uri`. Illustrerende respons (tilbudsadressen er ikke et aktivt tilbud): ```json { "issuanceId": "issuance-example", "offerUri": "https://www.symfoni.dev/app/credential/offer?credential_offer_uri=https%3A%2F%2Fissuer.example%2Foffer%3Fid%3D123%26token%3Da%252Bb", "status": "offered", "templateSlug": "euwoid", "offerUrlFormat": "symfoni" } ``` Dersom Brreg bare har selve tilbudsadressen, er mottaksadressen: ```text https://www.symfoni.dev/app/credential/offer?credential_offer_uri= ``` Kod tilbudsadressen som én parameterverdi, inkludert alle dens egne query-parametere. Eksempel for en landingsside hos Brreg: ```js const returnUrl = new URL('https://www.symfoni.dev/app/credential/offer'); returnUrl.searchParams.set('credential_offer_uri', rawCredentialOfferUri); link.href = returnUrl.href; link.textContent = 'Åpne beviset i Symfoni'; ``` Innebygde tilbud støttes også: sett `credential_offer` til JSON-teksten via `URLSearchParams` i stedet for `credential_offer_uri`. Bruk én av parameterne per lenke. Returlenken åpner eksisterende mottaksflyt, som viser tilbudet før brukeren klikker «Legg til i lommeboken». Uten aktiv innlogging sendes brukeren via innlogging og tilbake til samme tilbud med alle parametere bevart. ## Lenken til Altinn Digdirs EBWOID-dokumentasjon oppgir allerede `sandkasse + symfoni` som en gyldig kombinasjon. `issuer=symfoni` velger utsteder og angir ikke hvilken lommebok beviset skal mottas i. Brreg opplyser at `linked=true` er nødvendig for brukeropplevelsen i den lenkede flyten. Både velkomstsiden og lommeboken bruker knappen **«Hent virksomhetsbevis hos Brønnøysundregistrene»** med denne adressen i samme fane. Etter bestilling returnerer brukeren automatisk til Symfoni med tilbudet, uten manuell innliming: ```text https://brg.apps.tt02.altinn.no/brg/lommebok-v1/set-query-params?issuer=symfoni&environment=sandkasse&linked=true ``` Altinn dokumenterer prefylling via [`set-query-params`](https://docs.altinn.studio/en/altinn-studio/v8/guides/development/prefill/query-params/). ### Bekreftet returflyt 10. september 2026 Brukeren bekreftet at den lenkede flyten fra Brregs TT02-sandkasse tilbake til `https://www.symfoni.dev` fungerte uten manuell innliming. Dette erstatter statusen fra 9. september, da testen bare nådde en sluttside med QR-kode og tilbudsadresse uten synlig returknapp. Bekreftelsen gjelder den gjennomførte brukerflyten. En runde uten aktiv Symfoni-innlogging ble ikke særskilt bekreftet i denne testen; bevaring av tilbud gjennom innlogging dekkes av lokale regresjonstester. ### Kontroll ved senere sandkassetester 1. Åpne virksomhetsbevis-tjenesten fra Symfoni. Kontroller at Altinn åpnes i samme fane med Symfoni og sandkasse forhåndsvalgt. 2. Logg inn med TestID / ID-porten test, velg virksomhet og bestill EBWOID. 3. Kontroller automatisk retur til Symfoni med tilbudet. Se gjennom tilbudet, klikk «Legg til i lommeboken» og kontroller at beviset vises i lommeboken. 4. Ved testing uten aktiv Symfoni-innlogging, kontroller at innlogging returnerer til riktig tilbud. Kontroller også tilbud med egne query-parametere dersom utstederen tilbyr det. 5. Registrer dato, miljø, testutfall og eventuelle avvik. Ikke lagre aktive tilbudslenker, engangskoder eller tokens i testnotatet. ## Drift - Lagre `issuanceId` hvis dere må vite om tilbudet ble hentet. - Avtal hvor raskt en tilbakekalling skal bli synlig for mottakere. - Roter API-nøkkelen og fjern tilgang når integrasjonen avsluttes. - Skill testpåstander fra dokumenterte fakta om Brønnøysundregistrenes produksjonstjenester. Se [Digdirs EBWOID-dokumentasjon](https://docs.digdir.no/docs/lommebok/lommebok_ebwoid_usteder.html) for den nasjonale sandkassens begreper og avgrensninger. ## Tidsgrenser og usikkert tilbakekallingsutfall Paradym-kall gjennom gatewayen har 30 sekunders samlet tidsgrense og maksimalt 4 MiB respons. Redirects og automatiske gjentakelser er slått av. EBWOID/EUCC- forespørsler, API-nøkler, idempotens, tilbudsformater og vellykkede svar beholdes. Tilbakekalling kan gi disse feilsvarene: - `409 revocation_in_progress`: samme tilbakekalling behandles allerede; prøv samme utstedelsesadresse igjen senere. - `503 revocation_outcome_unknown`: fjernutfallet er ukjent. Operasjonen må avstemmes med dokumentert bekreftelse fra utsteder. Ingen ny tilbakekalling sendes automatisk. - `503 revocation_reconcile_required`: utsteder har bekreftet tilbakekallingen; lokal status publiseres på nytt i bakgrunnen eller ved nytt kall til samme adresse. Dette er endret feiloppførsel som integrasjonen må håndtere. Normal suksess er fortsatt `{ "issuanceId": "…", "status": "revoked" }`; allerede tilbakekalte utstedelser gir fortsatt `400 already_revoked`. Ikke opprett en ny utstedelse for å omgå et ukjent utfall. Utstedelse beholder eksisterende `issuance_outcome_unknown` og kravet om å gjenbruke samme idempotensnøkkel. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/verifikasjon # Be om og kontrollere bevis Lag en OpenID4VP-forespørsel, send brukeren til Symfoni og valider presentasjonen før opplysningene brukes. ## Hva mottakeren gjør Mottakeren beskriver hvilke bevis og opplysninger tjenesten trenger. Symfoni viser forespørselen, lar brukeren godkjenne eller avslå og sender en OpenID4VP-respons til mottakerens callback. Et mottatt svar er ikke ferdig kontrollert. Mottakeren må validere request-binding, signatur, holder-binding, utsteder, gyldighet, status og at de delte opplysningene faktisk oppfyller forespørselen. Gå til [Verifikator: kom i gang](/docs/virksomhetslommebok/verifikasjon/kom-i-gang) for produktkontrakten eller [OpenID4VP](/docs/protokoller/openid4vp) for standarden. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/issuer/gateways/eucc # EUCC: API-kontrakt til Brreg Utsted EU Company Certificate gjennom Brregs Paradym-prosjekt med versjonsfestet validering. ## Omfang og status EUCC er et vanlig bevis. EBWOID er fortsatt virksomhetsidentitet og styrer tilgang. Malen heter `EUCC`, har slug `eucc` og tilhører Brregs eksisterende utstederprofil. Både malen og signeringen ligger i Brregs Paradym-prosjekt. Kontrakten bygger på vedlegget **WE BUILD – EU Company Certificate 0.9.0**. Valideringsprofilen er `eucc/0.9.0`. Sandkassestandarden er **én kalendermåneds gyldighet fra utstedelse**, med tilbakekalling og prosjektets P-256-utstedersertifikat. Dette angir ikke at sandkasseutstederen er kvalifisert; testeksempelet bruker `EAA`. Live-testen 9. september 2026 passerte for begge representantvariantene og en blandet liste, inkludert mottak, presentasjon og tilbakekalling. Symfoni har akseptert følgende to forskjeller for piloten: - Status følger `status.status_list: { idx, uri }`, mens skjema 0.9.0 krever `type`, `status_list_credential`, `status_list_index` og `status_purpose` under `status`. - Utstederen identifiseres med X.509-sertifikatet; `iss` fra eksempelvedlegget er ikke inkludert. `iss` er valgfritt i selve JSON-skjemaet. Forskjellene blokkerer ikke pilotbruk. Originalskjemaet og beviset beholdes uendret. Koden og pilotbindingen må deployes før adressen under brukes mot pilot. Se `docs/eucc-brreg.md` for testbevis og oppsett. ## Utstedelse ```http POST https://www.symfoni.dev/api/issuers/brreg/credentials/eucc/issue?offerUrlFormat=symfoni Authorization: Bearer Content-Type: application/json Idempotency-Key: ``` Nøkkelen i denne requesten er Brregs **Symfoni-API-nøkkel**. Symfoni bruker Paradym-nøkkelen på serveren for å utstede i Brregs prosjekt. Eksempelet bruker syntetiske virksomhets- og representantdata fra vedleggene. Feltene for utstedermyndighet og autentisk kilde sendes av Brreg som virksomhetsdata. `iss` er et teknisk felt som ikke kan sendes av klienten. I det testede sertifikatoppsettet identifiseres utstederen gjennom X.509-sertifikatet; Paradym utsteder uten et eget `iss`-felt. ```json { "attributes": { "attestation_legal_category": "EAA", "issuing_authority": "Brønnøysundregistrene", "issuing_authority_id": "NOFOR.974760673", "issuing_country": "NO", "authentic_source_id": "NOFOR.974760673", "authentic_source_name": "Brønnøysundregistrene", "legal_person_name": "EUDI WALLET SOLUTIONS AS", "legal_person_id": "NOFOR.987654321", "legal_form_type": "Aksjeselskap (AS)", "registration_member_state": "NO", "registered_address": { "full_address": "Storgata 1; 9008; Tromsø; NO", "thorough_fare": "Storgata", "locator_designator": "1", "post_code": "9008", "post_name": "Tromsø", "admin_unit_level_1": "NO", "admin_unit_level_2": "Troms" }, "registration_date": "2020-05-20", "share_capital": { "amount": "30000", "currency": "NOK" }, "legal_person_status": "active", "legal_person_activity": { "code": "62.010", "description": "Computer programming activities" }, "digital_contact_point": { "website": "https://www.example-eudi-wallet.no", "email": "post@example-eudi-wallet.no" }, "legal_representative": [ { "natural_person": { "full_name": "Lysende Blomst", "date_of_birth": "1980-01-01", "nationality": "Norwegian", "signatory_rule": "sole" } }, { "legal_person": { "name": "PARENT HOLDING AS", "id": "NOFOR.123456789", "legal_form_type": "Aksjeselskap (AS)", "signatory_rule": "sole" } } ], "trust_anchor": "https://trust.example.org/anchors/eidas" } } ``` Dette eksempelet finnes også i `docs/examples/eucc/issue-request.json`: ```sh curl --fail-with-body \ 'https://www.symfoni.dev/api/issuers/brreg/credentials/eucc/issue?offerUrlFormat=symfoni' \ -H "Authorization: Bearer $SYMFONI_BRREG_API_KEY" \ -H 'Idempotency-Key: ' \ -H 'Content-Type: application/json' \ --data-binary @docs/examples/eucc/issue-request.json ``` Illustrerende respons; adressen er ikke et aktivt tilbud: ```json { "issuanceId": "issuance-example", "offerUri": "https://www.symfoni.dev/app/credential/offer?credential_offer_uri=https%3A%2F%2Fissuer.example%2Foffers%2Feucc-example", "status": "offered", "templateSlug": "eucc", "offerUrlFormat": "symfoni" } ``` Brreg bruker `offerUri` uendret som lenke for **«Åpne beviset i Symfoni»**. `offered` betyr at tilbudet er opprettet; beviset er ennå ikke nødvendigvis mottatt. Send `Idempotency-Key` (1–200 tegn) for hver tilsiktet utstedelse. `x-request-id` støttes som alternativ. Samme nøkkel og samme request returnerer samme tilbud; endrede felt med samme nøkkel gir `409 idempotency_conflict`. Ved `issuance_reconcile_required` gjentas samme nøkkel. Ved `issuance_outcome_unknown` må operasjonen avstemmes mot utsteder før en ny utstedelse forsøkes. ## Felt og validering Ingen verdier konverteres til tekst eller andre datatyper. Ukjente felt avvises, også inne i objekter og listeelementer. Valgfrie felt utelates når de ikke finnes; `null` er ikke en gyldig erstatning. Land- og valutakoder kontrolleres mot mønstrene i vedlegget (henholdsvis to og tre store bokstaver), ikke mot et eksternt koderegister. Skjemaet definerer ikke ytterligere formatkontroll for EUID, NACE-kode eller beløp. Hvert element i `legal_representative` må inneholde **nøyaktig én** av `natural_person` og `legal_person`. Begge varianter kan forekomme i samme liste. Listen må ha minst ett element. `legal_representative[].natural_person.date_of_birth` er en obligatorisk streng uten datoformatkontroll. Dette tillater Tenors bevisst umulige testdatoer, som `1974-85-29`. Verdien sendes videre uendret, også ved manuell utstedelse. Originalskjema 0.9.0 krever fortsatt `date`, så slike verdier avviker fra originalskjemaet selv om gatewayen godtar dem. Andre datofelt valideres som før. `signatory_rule` må være `sole`, `joint`, `joint_two`, `joint_all` eller `limited`. Bruk `sole` for signatur alene; `alone` er ikke en gyldig verdi. Ved manuell utstedelse velges verdien fra en nedtrekksliste. Ugyldige underfelter rapporteres med feltsti, for eksempel `legal_representative[0].natural_person.signatory_rule`. «Ja» på et underfelt betyr påkrevd når det overordnede objektet er til stede. | Felt | Type | Påkrevd | Format eller tillatte verdier | | --- | --- | --- | --- | | `issuing_authority` | string | Ja | | | `issuing_authority_id` | string | Ja | | | `issuing_country` | string | Ja | ^[A-Z]{2}$ | | `authentic_source_id` | string | Ja | | | `authentic_source_name` | string | Ja | | | `attestation_legal_category` | string | Ja | EAA, PUB-EAA, QEAA | | `legal_person_name` | string | Ja | | | `legal_person_id` | string | Ja | | | `legal_form_type` | string | Ja | | | `registration_member_state` | string | Ja | ^[A-Z]{2}$ | | `registered_address` | object | Ja | | | `registered_address.care_of` | string | Nei | | | `registered_address.full_address` | string | Ja | | | `registered_address.thorough_fare` | string | Nei | | | `registered_address.locator_designator` | string | Nei | | | `registered_address.post_code` | string | Nei | | | `registered_address.post_name` | string | Nei | | | `registered_address.post_office_box` | string | Nei | | | `registered_address.locator_name` | string | Nei | | | `registered_address.admin_unit_level_1` | string | Nei | | | `registered_address.admin_unit_level_2` | string | Nei | | | `registration_date` | string | Ja | date | | `share_capital` | object | Nei | | | `share_capital.amount` | string | Ja | | | `share_capital.currency` | string | Ja | ^[A-Z]{3}$ | | `legal_person_status` | string | Ja | active, inactive | | `legal_person_activity` | object | Ja | | | `legal_person_activity.code` | string | Ja | | | `legal_person_activity.description` | string | Ja | | | `legal_person_duration` | string | Nei | date | | `digital_contact_point` | object | Nei | | | `digital_contact_point.website` | string | Nei | uri | | `digital_contact_point.email` | string | Nei | email | | `legal_representative` | array | Ja | Minst ett element; nøyaktig én representantvariant per element | | `trust_anchor` | string | Nei | uri | | `legal_representative[].natural_person` | object | Én variant | | | `legal_representative[].natural_person.full_name` | string | Ja | | | `legal_representative[].natural_person.date_of_birth` | string | Ja | Fritekst (Tenor-unntak; originalskjemaet krever date) | | `legal_representative[].natural_person.nationality` | string | Nei | | | `legal_representative[].natural_person.signatory_rule` | string | Ja | sole, joint, joint_two, joint_all, limited | | `legal_representative[].legal_person` | object | Én variant | | | `legal_representative[].legal_person.name` | string | Ja | | | `legal_representative[].legal_person.id` | string | Ja | | | `legal_representative[].legal_person.legal_form_type` | string | Ja | | | `legal_representative[].legal_person.signatory_rule` | string | Ja | sole, joint, joint_two, joint_all, limited | ## Systemfelter Brreg skal ikke sende `vct`, `issuance_date`, `iss`, `sub`, `jti`, `cnf`, `iat`, `nbf`, `exp` eller `status` i `attributes`. Disse avvises fremfor å overstyres. Symfoni genererer `issuance_date` som UTC-tid når tilbudet opprettes. Paradym håndterer signatur, faktisk JWT-utstedelsestid og utløp, holderbinding og status. Derfor kan `issuance_date` være litt tidligere enn `iat` når tilbudet innløses senere. Eventuelle `sub`, `jti` og `nbf` må vurderes ut fra det faktisk utstedte beviset; vedleggets eksempelnøkler og faste tidspunkter kopieres aldri. Malen må ha eksakt `vct = uri:eu:eudi:eucc:1`. Oppsett og utstedelse stopper ved avvik; en automatisk Paradym-type brukes ikke som erstatning. ## Feil Ugyldige virksomhetsdata gir HTTP 400 før Paradym kalles: ```json { "error": { "code": "invalid_payload", "message": "registered_address.full_address must have required property 'full_address'", "path": "registered_address.full_address" } } ``` HTTP 409 med `error.code = "issuance_profile_mismatch"` betyr at den versjonsfestede profilen eller Paradym-malen avviker fra oppsettet. Ingen tilbud opprettes. Eksisterende 401/404-feil for API-nøkkel, utsteder, mal og utstedelse er uendret. ## Status og tilbakekalling ```http GET https://www.symfoni.dev/api/issuers/brreg/issuances/?offerUrlFormat=symfoni Authorization: Bearer ``` ```http POST https://www.symfoni.dev/api/issuers/brreg/issuances//revoke Authorization: Bearer ``` Tilbakekalling krever et faktisk utstedt bevis. Respons: ```json { "issuanceId": "issuance-example", "status": "revoked" } ``` Statuser omfatter `offered`, `completed`, `partiallyIssued`, `failed` og `revoked`. Statusendepunktet og tilbakekallingsendepunktet bruker eksisterende tilgangskontroll. ## Tidsgrenser og usikkert tilbakekallingsutfall Paradym-kall gjennom gatewayen har 30 sekunders samlet tidsgrense og maksimalt 4 MiB respons. Redirects og automatiske gjentakelser er slått av. EBWOID/EUCC- forespørsler, API-nøkler, idempotens, tilbudsformater og vellykkede svar beholdes. Tilbakekalling kan gi disse feilsvarene: - `409 revocation_in_progress`: samme tilbakekalling behandles allerede; prøv samme utstedelsesadresse igjen senere. - `503 revocation_outcome_unknown`: fjernutfallet er ukjent. Operasjonen må avstemmes med dokumentert bekreftelse fra utsteder. Ingen ny tilbakekalling sendes automatisk. - `503 revocation_reconcile_required`: utsteder har bekreftet tilbakekallingen; lokal status publiseres på nytt i bakgrunnen eller ved nytt kall til samme adresse. Dette er endret feiloppførsel som integrasjonen må håndtere. Normal suksess er fortsatt `{ "issuanceId": "…", "status": "revoked" }`; allerede tilbakekalte utstedelser gir fortsatt `400 already_revoked`. Ikke opprett en ny utstedelse for å omgå et ukjent utfall. Utstedelse beholder eksisterende `issuance_outcome_unknown` og kravet om å gjenbruke samme idempotensnøkkel. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/issuer/gateways # Utstederintegrasjoner Tjenestespesifikke sider viser felter og driftsavklaringer som kommer i tillegg til det generelle Symfoni-API-et. ## Hvorfor egne sider? Det generelle API-et er likt for alle utstedere. Bevismal, feltnavn, autentisk kilde, gyldighet og operativt ansvar må likevel avtales for hver tjeneste. Tilgjengelig eksempel: - [Brønnøysundregistrene: testintegrasjon](/docs/virksomhetslommebok/issuer/gateways/brreg) --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/verifikasjon/kom-i-gang # Verifikator: kom i gang Send en DCQL-basert OpenID4VP-forespørsel til Symfoni og valider suksess eller avslag på mottakerens callback. [![Verifikasjonsflyt i Symfoni](/docs/diagrams/verification-flow.svg)](/docs/diagrams/verification-flow.svg) [Åpne diagrammet i full størrelse](/docs/diagrams/verification-flow.svg). ## 1. Bygg forespørselen Nye integrasjoner bør bruke OpenID4VP 1.0 med DCQL. Sett minst: - et stabilt `client_id` med riktig tillitsbinding - `response_mode=direct_post` - offentlig `response_uri` - fersk, tilfeldig `nonce` - ugjennomsiktig `state` som identifiserer mottakerens transaksjon - en DCQL-spørring som bare ber om nødvendige bevis og felt Symfoni kan lese Presentation Exchange for kompatibilitet med eldre OpenID4VP-utkast. Ikke velg dette for en ny 1.0-integrasjon. ## 2. Åpne Symfoni Bruk enten en URL til request object: ```text https://www.symfoni.dev/app/credential/verify?request_uri=https%3A%2F%2Fverifier.example.com%2Fpar%2Fxyz ``` eller et kompakt, signert request object: ```text https://www.symfoni.dev/app/credential/verify?authorization_request=eyJhbGciOi... ``` `request_uri` kan hentes med GET eller POST. Velg metoden mottakeren annonserer og test utløp og gjenbruk. ## 3. Motta svaret Ved suksess sender Symfoni form-post til `response_uri` med `vp_token` og `state` når det var med i forespørselen. Eldre Presentation Exchange-flyter har i tillegg `presentation_submission`. Ved avslag eller protokollfeil sender Symfoni `error`, `error_description` og tilhørende `state` når callbacken er tilgjengelig. ## 4. Valider før bruk Mottakeren må minst: 1. finne aktiv transaksjon fra `state` 2. kontrollere `nonce`, målgruppe og request-binding 3. validere presentasjonens signatur og holder-binding 4. godta riktig utsteder og sertifikatkjede 5. kontrollere gyldighet og eventuell tilbakekalling 6. kontrollere at format, bevis og felter oppfyller DCQL-spørringen Logg et kontrollresultat med korrelasjonsnøkkel. Ikke logg rått `vp_token` uten et dokumentert behov og riktig beskyttelse. ## Vanlige feil - callbacken er ikke offentlig tilgjengelig eller godtar ikke form-post - `state` er ukjent eller allerede brukt - forespørselen ber om felt som ikke finnes i beviset - tillitskjeden eller request-signaturen kan ikke valideres - mottakeren antar at et teknisk gyldig bevis automatisk er tilstrekkelig for vedtaket ## Mottak gjennom Symfonis server-API For integrasjoner opprettet i `/app/mottak` håndterer Symfoni verifikasjonen. Kundens backend bruker `/api/integrations/v1/sessions` med egen API-nøkkel. Dette er en annen leveringsmåte enn mottakerens egen OpenID4VP-callback ovenfor. **Endret oppbevaringskontrakt:** Verifiserte felt kan hentes i 15 minutter fra faktisk `verifiedAt`. Responsens `resultExpiresAt` angir fristen. Etter fristen beholdes `receipt.status=verified`, men `receipt.result` fjernes og `receipt.resultExpired=true`. Et resultat som ikke ble vurdert mot den aktuelle integrasjonens policy innen fristen, gir `expired`, ikke en ny bekreftelse av verifikasjon. Symfoni rydder feltverdier og råpresentasjoner automatisk i aktive lagre, også uten polling. Minimale status- og idempotensposter beholdes i 24 timer etter avslutning; deretter gir oppslag HTTP 404. Ny deling krever en ny Idempotency-Key. Mottakeren må selv begrunne og begrense eventuell egen lagring. Sikkerhetskopier har separate oppbevaringsfrister; resultatfristen er ikke et løfte om fysisk sletting fra alle sikkerhetskopier etter 15 minutter. Eksporter oppdaterte integrasjonsinstruksjoner fra mottaksoppsettet før aktivering. Denne endringen gjelder mottak/verifikasjon. Brregs EBWOID-/EUCC- utstedelses-API og walletens lagrede bevis endres ikke. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/signering # Virksomhetsforsegling Symfoni kan kombinere deling av virksomhetsbevis med brukerautorisert forsegling av PDF-er og sikker push-levering til mottakeren. ## Hva flyten gjør Mottakeren sender en OpenID4VP-forespørsel med `transaction_data`. Den beskriver virksomhetsbeviset, PDF-dokumentene, dokumenthashene og hvor de forseglede dokumentene skal leveres. Brukeren ser forespørselen og godkjenner handlingen i sandkassen. Symfoni bruker Signant eSeal og sender resultatet som `multipart/form-data` til mottakerens registrerte endepunkt. Tjenesten må separat fastslå at brukeren kan handle for virksomheten. Dette er elektronisk segl for juridisk person. Det er ikke automatisk en personlig elektronisk signatur, og docs fastsetter ikke juridisk kvalifikasjonsnivå. Gå til [Virksomhetsforsegling: kom i gang](/docs/virksomhetslommebok/signering/kom-i-gang) for request og mottakskontrakt. --- Source: https://www.symfoni.dev/docs/virksomhetslommebok/signering/kom-i-gang # Virksomhetsforsegling: kom i gang Send en OpenID4VP-forespørsel med PDF-er og leveringsinformasjon, og motta forseglede dokumenter som en autentisert multipart POST. [![Flyt for virksomhetsforsegling i Symfoni](/docs/diagrams/signing-flow.svg)](/docs/diagrams/signing-flow.svg) [Åpne diagrammet i full størrelse](/docs/diagrams/signing-flow.svg). ## 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: ```text https://www.symfoni.dev/app/credential/verify?request_uri= ``` Forespørselen må ha en unik `nonce`. `client_id` skal være `x509_hash:`. 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: ```json { "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": "", "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": "" }, "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_` 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](/docs/virksomhetslommebok/data-nokler-og-lagring). --- Source: https://www.symfoni.dev/docs/personlommebok # Personlommebok Person- og virksomhetslommebøker kan bruke de samme protokollene, men identitet, representasjon, brukergodkjenning og ansvar er forskjellige. ## Samme protokoll betyr ikke samme beslutning En personlommebok brukes av en fysisk person. En virksomhetslommebok brukes på vegne av en organisasjon. Derfor må virksomhetsflyten ofte bevise både organisasjonens identitet og personens rolle eller fullmakt. En personlig elektronisk signatur er også noe annet enn et elektronisk virksomhetssegl. Les [Forskjellen på person- og virksomhetslommebok](/docs/personlommebok/hvordan-den-skiller-seg-fra-virksomhetslommebok) og [Fullmakt og representasjon](/docs/bruksomrader/fullmakt-og-representasjon) før dere kombinerer bevis fra begge lommeboktypene. --- Source: https://www.symfoni.dev/docs/personlommebok/hvordan-den-skiller-seg-fra-virksomhetslommebok # Forskjellen på person- og virksomhetslommebok Personlommeboken og virksomhetslommeboken kan bruke like protokoller, men de skiller seg i hvem som godkjenner deling, hvem som bærer risikoen og hvordan tillit vurderes. ## Samme mekanisme, ulik beslutning Begge lommeboktypene kan bruke digitale bevis, presentasjoner, OpenID4VCI og OpenID4VP. Det som endres er hvem som handler, hva handlingen betyr, og hvem som bærer ansvaret. ## Tre forskjeller som påvirker designet 1. Personlommeboken handler om personlig identitet og brukerens godkjenning, ikke representasjon på vegne av en virksomhet. 2. Virksomhetslommeboken må ofte dokumentere rolle, fullmakt eller organisatorisk binding i tillegg til identitet. 3. Feil og misbruk får ulik operativ konsekvens: feil brukergodkjenning er ikke det samme som feil virksomhetsforsegling. ## Konsekvens for integrasjoner - tekster, godkjenningsflater og revisjonsspor må utformes forskjellig - tillitsvurdering kan ikke gjenbrukes blindt mellom person- og virksomhetsflyter - signeringsscenarier må skille mellom personlig underskrift og virksomhetsforsegling ## I Symfoni Symfoni har både person- og virksomhetsrettede spor, men denne dokumentasjonen prioriterer virksomhetslommeboken. Se [Bruk Symfoni](/docs/virksomhetslommebok) for tilgjengelige produktflyter. En kombinasjon av personidentitet og virksomhetsfullmakt krever fortsatt egen modellering. --- Source: https://www.symfoni.dev/docs/protokoller # Protokoller Teknisk referanse for utstedelse med OpenID4VCI, deling med OpenID4VP og Symfonis profil for virksomhetsforsegling. ## Velg riktig protokoll - [OpenID4VCI](/docs/protokoller/openid4vci) brukes når et bevis skal utstedes til en lommebok. - [OpenID4VP](/docs/protokoller/openid4vp) brukes når en mottaker ber lommeboken om bevis. - [Forsegling med transaction_data](/docs/protokoller/signering-med-transaction-data) binder dokument og godkjenning til en presentasjon, med en Symfoni-spesifikk leveringsprofil. Begynn med brukerreisen. Gå hit når dere skal bygge eller feilsøke selve integrasjonen. --- Source: https://www.symfoni.dev/docs/protokoller/openid4vci # OpenID4VCI OpenID4VCI beskriver hvordan issuer, wallet og eventuelle autorisasjonsservere samarbeider om å levere et credential fra tilbud til ferdig lagret credential. ## Kort flyt 1. Issuer oppretter et credential offer. 2. Walleten løser offeret via `credential_offer_uri` eller inline `credential_offer`. 3. Walleten fullfører enten `pre-authorized_code`-flyt eller `authorization_code`-flyt. 4. Walleten henter credentialet og lagrer det lokalt. ## Hva Symfoni krever i praksis - `credential_offer_uri` må kunne hentes fra walletens miljø. - Hvis issuer bruker `authorization_code`, må den registrere redirect tilbake til walleten. - Walleten trenger en avtalt `client_id` mot issuer i OAuth-caset. ## Feil du skal forvente - `invalid_json` eller `invalid_request` hvis issuer-gatewayen får feil payload. - `template_not_found` hvis `templateSlug` ikke finnes. - Runtime-feil i walleten hvis issuerens metadata eller callbacker ikke stemmer med det walleten forventer. --- Source: https://www.symfoni.dev/docs/protokoller/openid4vp # OpenID4VP OpenID4VP beskriver hvordan en mottaker ber om digitale bevis, og hvordan lommeboken returnerer et svar bundet til riktig transaksjon. ## Hva protokollen gjør OpenID4VP lar en mottaker beskrive hvilke bevis eller opplysninger den trenger. Lommeboken matcher forespørselen mot tilgjengelige bevis, viser valget til brukeren og sender en verifiserbar presentasjon tilbake. ## Grunnflyten 1. Mottakeren lager et signert request object eller publiserer det på `request_uri`. 2. Brukeren åpner forespørselen i lommeboken. 3. Lommeboken validerer forespørselen og finner bevis som passer DCQL. 4. Brukeren godkjenner eller avslår. 5. Svaret sendes som `direct_post` til mottakerens `response_uri`. ## Dette binder svaret - `nonce` binder presentasjonen til utfordringen. - `state` lar mottakeren koble svaret til egen transaksjon. - `client_id` og request-signaturen bindes til mottakeren gjennom mekanismen som følger av valgt prefix, for eksempel sertifikatkjede, verifier-attestasjon, føderasjon eller forhåndsregistrering. - `response_uri` bestemmer hvor svaret leveres. - Holder-binding viser at lommeboken kontrollerer nøkkelen som beviset er bundet til. Mottakeren må kontrollere alle relevante bindinger, signaturer, gyldighet og status før opplysningene brukes. ## Symfoni-støtte Symfoni støtter remote OpenID4VP med DCQL, GET- og POST-baserte `request_uri`-oppslag, brukergodkjenning og avslag. OpenID4VP 1.0 Final bruker DCQL. Symfoni kan i tillegg lese Presentation Exchange for kompatibilitet med eldre OpenID4VP-utkast; nye integrasjoner bør bruke DCQL. Proximity-flyter med mdoc, Bluetooth eller NFC støttes ikke. Ved virksomhetsforsegling brukes `transaction_data` i tillegg. Forseglede dokumenter sendes separat til mottakerens `dispatch.url`; de er ikke en del av selve `vp_token`. ## Test negative tilfeller Prøv utløpt eller gjenbrukt `nonce`, endret callback, ukjent `state`, feil request-signatur og et bevis som ikke oppfyller forespørselen. Et forståelig avslag er også en viktig interoperabilitetstest. --- Source: https://www.symfoni.dev/docs/protokoller/signering-med-transaction-data # Forsegling med transaction_data `transaction_data` binder virksomhetsbevis, dokumenthash, brukerens godkjenning og mottakerens leveringsendepunkt til samme OpenID4VP-transaksjon. ## Hva som kommer i tillegg til OpenID4VP En vanlig presentasjon deler bevis. En forsegling må i tillegg beskrive dokumentene, vise dem til brukeren, kontrollere hashene, gjennomføre eSeal-operasjonen og levere resultatet til riktig mottaker. `transaction_data` bærer denne konteksten. Hvert element er base64url-enkodet JSON og må knyttes til et bevis gjennom `credential_ids`. [OpenID4VP 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-8.4) standardiserer den generelle bindingen. Kjernen definerer `type` og `credential_ids`, og SD-JWT VC-profilen beskriver `transaction_data_hashes`. Typeverdien `qes_authorization` og feltene `documentDigests`, `transaction_id` og `dispatch` er del av Symfonis integrasjonsprofil. De skal ikke presenteres som universelle OpenID4VP-felt eller som bevis på et kvalifisert nivå. ## Bindingene som må holde - `credential_ids` viser til forespurte virksomhetsbevis. - `nonce` er unik for forespørselen og hindrer gjenbruk. - Hver `documentDigest` har en stabil `id`, PDF-kilde og SHA-256-hash. - `transaction_id` knytter leveransen til mottakerens sak. - `dispatch.url` og engangstoken bestemmer hvor resultatet kan leveres. - Leveringsorigin må være knyttet til forespørselen eller godkjent på forhånd. - `transaction_data_hashes` i SD-JWT VC-ens Key Binding JWT må stemme med de kodede verdiene mottakeren sendte. ## Leveringskontrakten Symfoni sender en `multipart/form-data`-leveranse per `transaction_data`-element. Ved nettverksfeil kan samme leveranse sendes flere ganger med samme `Idempotency-Key`. Mottakeren må lagre nøkkelen og resultatet atomisk, returnere samme kvittering ved gjenlevering og ikke utføre saken på nytt. Tokenet må kunne bekrefte en slik gjenlevering også etter første vellykkede mottak. Manifestet navngir alle dokumentdelene. Mottakeren må behandle leveransen atomisk: Ikke marker saken som fullført dersom én dokumentdel mangler. Mottakeren må også validere presentasjonen og kontrollere `transaction_data_hashes` før leveransen og beviset behandles som samme autoriserte transaksjon. Redirects følges ikke. Responskroppen fra et mislykket mottak eksponeres heller ikke videre, fordi den kan inneholde sensitiv informasjon. ## Varig status og gjenoppretting Walleten journalfører hvert dokument før QTSP-kallet. Mottatte signaturer lagres med en gang, også når et senere dokument i samme forespørsel feiler. Et avbrutt QTSP-kall har status `unknown` og gjentas aldri automatisk. Operatøren må avklare resultatet hos QTSP med `ExternalRef` (`requestId:transactionId:documentId`) før en ny signering vurderes. En slik referanse gir korrelasjon; den er ingen garanti for at QTSP tilbyr idempotens. Bare levering av allerede lagrede signaturer gjentas automatisk. Presentasjonen gjentas ikke automatisk når den første dokumentleveransen feiler. Mottakeren må fortsatt kreve en gyldig presentasjon før saken fullføres. Status kan leses av en innlogget bruker i eierwalleten via `GET /app/credential/verify/signing-status?requestId=...`. Forhåndsvisning og signering bruker samme transport med kontroll av DNS også ved socket-tilkobling. Grensene er ti dokumenter og 30 MiB totalt per forespørsel, og 15 MiB per dokument. Dokumenter lastes sekvensielt. ## Serverkonfigurasjon `SIGNANT_ESEAL_WALLET_CERTIFICATES` er et JSON-objekt med wallet-ID som nøkkel, for eksempel `{"wallet-id":{"certificateName":"VIRKSOMHET A","certificateSubject":"Org 123456789"}}`. Bare serverens konfigurasjon kan gi en wallet tilgang til et sertifikat. Driftsansvarlig må kontrollere sertifikatets virksomhet og fullmakten ved konfigurering. Produksjon avviser wallets uten binding. Den gamle globale sertifikatkonfigurasjonen kan bare brukes med `SIGNANT_ESEAL_ALLOW_GLOBAL_SANDBOX_CERTIFICATE=true` i eksplisitt development/test-miljø. QTSP-endepunkt, distributor-ID og tilgangskode konfigureres fortsatt med de eksisterende `SIGNANT_ESEAL_*`-variablene. Den krypterte signeringsjournalen ligger i `SYMFONI_SIGNING_DB_PATH`, som normalt er app-databasens filsti med `.signing` som suffiks. Den må ligge på varig disk og inngå i SQLite-konsistent sikkerhetskopiering. Journalen krever `WALLET_ACTION_ENCRYPTION_KEY` (32 tilfeldige byte, base64url) og bruker `WALLET_ACTION_ENCRYPTION_KEY_VERSION` (standard `1`). Sikkerhetskopier nøkkelen separat. Bytte av nøkkel eller versjon uten migrering gjør tidligere journaldata utilgjengelige. ## Sikkerhetsspørsmål Test minst gjenbrukt nonce, feil dokumenthash, ukjent dokumentorigin, manglende Bearer-token, duplisert dokument-id og avvist leveranse. Kontroller også at brukeren ser virksomhet, dokumentnavn og handling før godkjenning. Se [den konkrete Symfoni-guiden](/docs/virksomhetslommebok/signering/kom-i-gang) for eksempelpayload. --- Source: https://www.symfoni.dev/docs/kilder-og-status # Kilder og status Autoritative kilder for regelverk, arkitektur, norsk sandkasse og protokoller, med tydelig skille mellom gjeldende rett, forslag og Symfoni-funksjon. ## Status per 20. august 2026 | Tema | Status | Hva du kan legge til grunn | | --- | --- | --- | | eIDAS 2 | Gjeldende EU-rett | Endringsforordningen er vedtatt i EU. Norsk innlemmelse i EØS og gjennomføring er ikke ferdig. | | EUDI ARF | Teknisk rammeverk | ARF 3.0.0 er siste publiserte versjon. Temaet lommebokenheter for juridiske personer er tatt ut i lys av arbeidet med en egen Business Wallet. | | European Business Wallet | EU-forslag | Rådet har vedtatt forhandlingsposisjon. Europaparlamentets behandling pågår. | | Nasjonal sandkasse | Testmiljø | Digdir og Brønnøysundregistrene tilbyr et separat miljø og tillitsrammeverk for utprøving. | | Symfoni | Produkt og pilot | Funksjonene må vurderes mot [kapabilitetsmatrisen](/docs/virksomhetslommebok/hva-kan-brukes-na). | ## EU og europeisk arkitektur - [eIDAS 2 – Regulation (EU) 2024/1183](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1183) - [Konsolidert eIDAS-forordning](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02014R0910-20241018) - [EUDI ARF – bevegelig siste versjon](https://eudi.dev/latest/) - [EUDI ARF 3.0.0 – pinnet utgivelse](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases/tag/v3.0.0) - [ARF 3.2 om lommebokenheter for juridiske personer](https://eudi.dev/latest/main/03-roles-within-the-eudi-wallet-ecosystem/#32-users-of-wallet-units) - [European Business Wallet – Kommisjonens forslag](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025PC0838) - [Rådets forhandlingsposisjon, 9. juni 2026](https://www.consilium.europa.eu/en/press/press-releases/2026/06/09/european-business-wallets-council-adopts-negotiating-position/) - [Løpende status i Europaparlamentet](https://oeil.europarl.europa.eu/oeil/en/procedure-file?reference=2025%2F0358%28COD%29) ## Norge og sandkassen - [Digdir: Nasjonal sandkasse for digital lommebok](https://docs.digdir.no/docs/lommebok/lommebok_om.html) - [Digdir: Arkitektur for digital lommebok](https://docs.digdir.no/docs/lommebok/lommebok_arkitektur.html) - [Digdir: Lommebøker for virksomheter](https://samarbeid.digdir.no/digital-lommebok/lommeboker-virksomheter/2913) - [Digdir: EBWOID-utsteder](https://docs.digdir.no/docs/lommebok/lommebok_ebwoid_usteder.html) - [Digdir: Symfoni i sandkassen](https://samarbeid.digdir.no/digital-lommebok/symfoni/3656) - [Regjeringen: EØS-notat om personidentifikasjonsdata og attesterte attributter](https://www.regjeringen.no/no/sub/eos-notatbasen/notatene/2025/okt/digital-lommebok-personidentifikasjonsdata-og-elektronisk-attesterte-attributtar/id3163599/) - [Regjeringen: overordnet EØS-notat om eIDAS-endringsforordningen](https://www.regjeringen.no/no/sub/eos-notatbasen/notatene/2021/des/endringsbestemmelser-i-eidas-forordningen/id2905581/) ## Protokoller - [OpenID4VCI 1.0 Final](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html) - [OpenID4VP 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) - [SD-JWT – RFC 9901](https://www.rfc-editor.org/rfc/rfc9901.html) - [SD-JWT VC – aktiv IETF-draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) ## Forvaltning, personvern og anskaffelser - [Datatilsynet: behandlingsansvarlig og databehandler](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/behandlingsansvarlig-og-databehandler/) - [Datatilsynet: vurdering av personvernkonsekvenser (DPIA)](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/) - [Arkivverket: arkivpliktig informasjon i felles saksbehandlingssystem](https://www.arkivverket.no/veiledere-for-offentlig-sektor/arkivpliktig-informasjon-i-felles-saksbehandlingssystem) - [NSM: grunnprinsipper for IKT-sikkerhet](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/ta-i-bruk-grunnprinsippene/) - [DFØ: kravspesifikasjoner i anskaffelser](https://www.anskaffelser.no/anskaffelsesprosess/anskaffelsesprosessen-steg-steg/avklare-behov-og-forberede-konkurransen/kravspesifikasjoner-tildelingskriterier-og-kontraktsvilkar/utarbeide-kravspesifikasjoner) - [DFØ: universell utforming i IT-anskaffelser](https://www.anskaffelser.no/hva-skal-du-kjope/it/krav-om-universell-utforming-i-anskaffelser-av-it) - [Uu-tilsynet: regelverk og krav](https://www.uutilsynet.no/regelverk/regelverk-og-krav/746) ARF forklarer helheten, men rettsaktene er bindende. Protokollene beskriver datautvekslingen, men gir ikke et bevis juridisk status alene. ---