Spørsmål og svar

Hvilke roller i virksomheten kan signere på bruksvilkår for sluttbrukersystemleverandører?
Svar: I punkt 1.1 i våre bruksvilkår fremgår det at vilkårene må signeres av en bemyndiget person. Dette innebærer at det er virksomheten selv som er ansvarlig for å påse at personen som signerer på vegne av virksomheten, har fått nødvendig fullmakt til dette.

Kan vi ha flere kontaktpersoner i registreringsskjemaet?
Svar: Ja, i punkt tre er det mulig å skrive inn flere navn og epostadresser.

Stemmer det at vi ikke lenger må kjøpe Altinn virksomhetssertifikat fra Commfides eller Buypass?
Svar: Innlogging med virksomhetssertifikat er utgående. Ved bruk av Maskinporten (med eller uten systembruker) og ID-porten er det ikke nødvendig med virksomhetssertifikat.

Vi skal bruke et API fra Skatteetaten, og dette API-et er ikke utviklet enda. Hvor langt i integrasjonsprosessen kan vi komme mens vi venter? Kan vi få gjort unna den delen som omhandler Maskinporten, eller kreves det at API-et vi skal bruke finnes under "Apper i produksjon"?
Svar: Det kommer litt an på hvilket API det gjelder, men dersom Maskinporten-scope allerede er opprettet for tjenesten, kan den delen av prosessen startes.

For en leverandør av et lønnssystem som tar i bruk Maskinporten: Er det kostnader for oss som bygger alle tjenestene selv? Eller gjelder kostnaden kun de som benytter Altinn Studio?
Svar: Egenutviklet løsning med direkte integrasjon mot Maskinporten har ingen kostnader. Ved bruk av Altinn Studio er det kostnader knyttet til transaksjoner, infrastruktur og etablering.

Blir kvitteringen tilgjengelig umiddelbart etter at innsendingen er fullført, eller må en forvente noe forsinkelse?
Svar: Kvitteringen blir generert som en del av siste steg, og blir tilgjengelig umiddelbart.

Når blir klientbiblioteker for autorisasjon tilgjengelig?
Svar: Her er vi helt i planleggingsfasen, og har ikke noe konkret å vise til enda.

For innsending av årsregnskap, kan autorisasjon bli gitt både av Maskinporten og ID-porten?
Altinn-apper kan velge å støtte autentisering med både Maskinporten og ID-porten. Tjenesteeier må svare på hvilke valg de har tatt i den konkrete appen for årsregnskap.

• 1) I dokumentasjonen står det at man må bruke systembruker for å opprette agentsystembruker. Er dette riktig, og hvordan fungerer den prosessen?

Her er det en feil i dokumentasjonen, som vil rettes innen kort tid.

Riktig prosess:
- Ha et registrert system hos Altinn.
- Systemleverandøren sender forespørsel om Systembruker for klientforhold.
- Altinn gir en lenke som leverandøren deler sikkert med sluttbrukeren.
- Sluttbrukeren godkjenner i Altinn.
- Systembruker for klientforhold kan deretter brukes til å representere flere klienter.

• Hva er forskjellen på en systembruker og en agentsystembruker?

Systembruker for eget system:
Brukes når en virksomhet eller person leverer tjenester for seg selv. Den representerer kun én juridisk enhet og kan ikke ha klienter tilknyttet.

Systembruker for klientforhold:
Brukes når en tjenesteleverandør (f.eks. et regnskapsbyrå) leverer på vegne av flere klienter. Denne typen kan ha flere klienter knyttet til seg og krever en godkjenningsprosess via Altinn

• 2) Kan en systembruker være tilknyttet flere systembrukeragenter? Med andre ord – kan ett selskap være knyttet til flere agenter?

Ja, ett selskap være knyttet til flere klienter:

Et selskap kan være kunde hos flere systemleverandører, og hver leverandør kan opprette sin egen Systembruker for klientforhold.

Knytningen skjer mellom det registrerte systemet (hos leverandøren) og organisasjonsnummeret til kunden.

Dermed kan samme selskap være tilknyttet flere agent‑systembrukere, for eksempel én for regnskap og én for HR.

• 3) Hvordan er flyten for at man er identifisert som en systemleverandør for å deretter få denne agentsystembrukeren?

1. Systemleverandør identifiseres ved at de har et registrert system hos Altinn. Nærmere beskrivelse finner du her: https://samarbeid.digdir.no/altinn/kom-i-gang/2868

2. Leverandøren sender en forespørsel om å opprette Systembruker for klientforhold via API eller integrasjon.

3. Altinn returnerer en lenke som leverandøren må dele sikkert med sluttbrukeren.

4. Sluttbrukeren logger inn i Altinn og godkjenner forespørselen.

5. Når godkjenningen er fullført, kan Systembrukeren for klientforhold brukes til å representere flere klienter. (Eksempel: regnskapsbyrå som leverer for mange kunder.)

• 4) I endringsflyt for systembruker som kommer i dag – støtter den også agent?

Endringsflyten for systembruker støtter også Systembruker for klientforholde. Når en endringsforespørsel sendes inn, får man tilbake en respons med en lenke som må deles sikkert med kunden. Hvis flere endringsforespørsler opprettes samtidig, er det den sist aksepterte forespørselen som gjelder. Hver endringsforespørsel må ha en unik korrelasjons-ID. Det er opp til leverandøren hvilken forespørsel som vises til kunden; hvis kunden får flere lenker, mister leverandøren kontroll over hva som godkjennes.

• 5) Hva skjer om man oppretter to aktive endringsforespørsler – er det mulig, og vinner sist aksepterte endringsforespørsel?

Ja, det er mulig, men hver forespørsel må ha en unik korrelasjons-ID. Den sist aksepterte forespørselen vinner, altså den som sluttbrukeren godkjenner sist, blir gjeldende. Det er leverandørens ansvar å styre hvilke forespørsler som vises til kunden. Hvis kunden får flere lenker og godkjenner begge, mister leverandøren kontroll over rekkefølgen.

• 6) Så vidt jeg kan se har vi i dag ikke mulighet til å bruke tilgangspakker med vanlige systembrukere. Stemmer det, og vil det i så fall bli mulig?

Ja, det stemmer at det så langt ikke har vært mulig å bruke tilgangspakker med Systembrukere for eget system, men dette er i ferd med å endres:

Det er allerede en versjon i test som gir støtte for tilgangspakker også for Systembrukere for eget system. Denne er planlagt i produksjon fra 1. desember.

Systembrukere for klientforhold har hatt støtte for tilgangspakker hele tiden.

• 7) Hvordan ser det ut i sluttbrukers Altinn-oversikt når man har lagt til en eller flere systembrukere? Jeg har testet med en systembruker i dag jeg ikke ser i Altinn.

Per dags dato er det ikke synlig i Altinns vanlige oversikt når du har lagt til en eller flere Systembrukere for eget system.

Det finnes ingen innboks eller GUI som viser ventende eller eksisterende systembrukerforespørsler.

Den eneste inngangen er den dype lenken som returneres i responsen når forespørselen opprettes. Denne må systemet ta vare på og gi til brukeren på en trygg måte.

Dette kan bli bedre senere, men per nå er det ikke implementert i Altinn-portalen.

• 8) Jeg trodde systembrukere bare hadde tilgangspakker, og ikke roller – og personbrukere skulle få tilgangspakker etter hvert. Er det forskjell på systembruker og agentsystembruker når det gjelder dette?

Systembrukere har ingen knytning til Altinn-rollene som nå fases ut. Tilgangsstyring her skjer på ressurser (Systembrukere for eget system) eller tilgangspakker (Systembrukere for klientforhold og Systembrukere for eget system). Personbrukere kan fortsatt få tilgang via Altinn-rollene, men også snart via tilgangspakker.

Forskjellen mellom systembruker for eget system og Systembruker for klientforhold er ikke i hvordan tilgang gis, men i bruksområdet:

- Systembruker for eget system: Jobber på vegne av egen virksomhet.
- Systembruker for klientforhold: Brukes av en tredjepart (f.eks. regnskapsfører) for å representere flere klienter.

• 9) Har dere anbefalinger ift. hvordan fordele rettighetene på flere systembrukere?

Ha så få tilganger som mulig per systembruker – dette er den sikreste tilnærmingen.

Samtidig må det tilpasses arbeidsprosessen. Hvis ett system jobber mot flere tjenester (f.eks. NAV og Skatteetaten), kan det være fornuftig å samle disse i én systembruker for det caset.

Unngå å lage én systembruker med «alle rettigheter» hvis det ikke er nødvendig, da dette øker risikoen ved misbruk.

• 10) Dersom man legger til flere rettigheter på en systembruker, og klienter allerede har godkjent med de gamle rettighetene, hvordan håndteres dette?

Når du legger til flere rettigheter (tilgangspakker) på en eksisterende systembruker, og klientene allerede har godkjent tidligere rettigheter, så brukes endringsforespørsel-mekanismen:

Du sender inn en endringsforespørsel for den aktuelle systembrukeren.

Endringsforespørselen kan inneholde én eller flere nye tilgangspakker.

Viktig: Operasjonen er idempotent add – det betyr at nye pakker legges til uten å fjerne de gamle.

Klienten må godkjenne endringen via en ny lenke (samme prosess som ved opprettelse).

Eksisterende rettigheter forblir aktive til endringen er godkjent.

• 11) Forstod jeg det riktig at på en agentbruker som er knyttet til 1000 klienter, må man inn og endre for én og én?

Ja, i dagens løsning må endringer gjøres per klient i brukergrensesnittet. For å håndtere store volumer mer effektivt anbefales det å bruke API-et, som gjør det mulig å automatisere prosessen (for eksempel med en løkke som legger til alle klientene programmatisk).

• 12) Hvis et selskap mottar en systembrukerforespørsel med flere scopes eller access packages, men bare ønsker å autorisere én av dem – hvordan kan dette gjøres?

Det er ikke mulig å godkjenne bare deler av en forespørsel. Når en systembrukerforespørsel er opprettet, gjelder prinsippet «alt eller ingenting». Hvis kunden kun skal gi tilgang til et utvalg av rettighetene, må systemleverandøren opprette en ny forespørsel som kun inneholder de ønskede tilgangene.

• 13) Jeg har tidligere etterlyst et API for å sjekke om en agentbruker har rettigheter for et gitt organisasjonsnummer. Er dette noe dere ser på?

Per i dag finnes det ikke et eget API for dette. Den eneste kontrollen skjer gjennom Maskinporten, som spør Altinn om rettigheter når et token brukes. Det er foreløpig ikke planlagt å eksponere dette endepunktet for systemleverandører, fordi det mangler underliggende data for å løse det på en god måte. Teamet har ikke landet en løsning ennå.

• 14) Kan dere gå igjennom hvordan en systembruker opprettes?

Følg dokumentasjon for opprettelse av systembruker: https://docs.altinn.studio/nb/authorization/guides/system-vendor/system-user/systemuserrequest/

• 15) Finnes det en oversikt i Altinn Access Management for ventende systembrukerforespørsler, og er det planlagt en GUI-løsning for godkjenning?

Nei, det finnes per i dag ingen innboks eller oversikt i Altinn-portalen for ventende forespørsler. Den eneste inngangen er den dype lenken som returneres i API-responsen ved opprettelse. Det er heller ikke planlagt en GUI-løsning for dette, men status på forespørsler kan hentes via API.

• 16) Typisk case: Bruker av sluttbrukersystem har ikke tilgang til å godkjenne, men må få en annen til å logge inn i Altinn og godkjenne – hvordan håndteres dette?

Det finnes ikke en innboks eller oversikt i Altinn-portalen der slike forespørsler automatisk vises. Den eneste måten å godkjenne forespørselen på er via den dype lenken som systemleverandøren mottar i responsen ved opprettelse. Denne lenken må systemet selv ta vare på og distribuere til riktig person (f.eks. daglig leder) på en trygg måte.

• 17) I tilfeller der man skal signere en innsendelse og bruker Maskinporten-token (f.eks. innsendelse av signert årsregnskap): Sender man da inn med Maskinporten-token og signerer med ID-porten-token? Finnes det scenarier der man benytter både Maskinporten og ID-porten?

Ja, det finnes scenarioer der man benytter både Maskinporten og ID-porten. Man kan sende inn data med Maskinporten-token og deretter signere med ID-porten-token. Dette er spesielt aktuelt ved innsendelse av signert årsregnskap, hvor selve innsendingen skjer via Maskinporten, mens signeringen gjøres med ID-porten for å sikre sporbarhet. Brønnøysundregistrene har åpnet for begge metoder, og det er mulig å bruke samme API med enten Maskinporten-token eller ID-porten-token, avhengig av behov og rollefordeling.

• 18) Det er også mulig å gjøre alt med ID-porten-bruker, både i portal og via API, og aldri bruke systembruker – stemmer det?

Ja, det er mulig. Man kan bruke ID-porten-bruker til å utføre hele prosessen – både innsending og signering – uten å benytte systembruker. Dette gjelder både via Altinn-portalen og via API. Det ble nevnt at Brønnøysundregistrene har åpnet for begge metoder, og at samme API kan benyttes med ID-porten-token for å sikre sporbarhet, som systembruker ikke tilbyr.

• 19) I TT02 får vi feilmeldingen 401 Unauthorized for party (agent-systembruker, tilgangspakke regnskapsfører med full signeringsrettighet, sender inn på vegne av systembrukerens kunder). Vet dere hva som typisk mangler i oppsettet for denne feilen?

For konkret feilsøking trenger vi at dere sender så mye info dere har til servicedesk@altinn.no. Nøyaktig klokkeslett og evt traceid er spesielt nyttig.

• 20) Hvordan kan systemleverandører som ikke har norsk organisasjonsnummer eller norsk ID-/D-nummer registrere sitt system?

Det er ikke mulig å registrere et system uten norsk organisasjonsnummer. Systemet må være registrert i Enhetsregisteret, og det valideres mot dette ved opprettelse. Det holder ikke å ha et personnummer – det må være et organisasjonsnummer. Dersom utviklerne eller eierne av systemet sitter i utlandet, må de ha et norsk søsterselskap med organisasjonsnummer som kan stå som systemeier.

• 21) API-et for «klientdelegering» som kommer – krever det at kunden delegerer full klientadministrator-rettighet til systemet/systemleverandøren?

Ja, API-et for klientdelegering krever at kunden gir klientadministrator-rettighet til systemleverandøren. Dette skjer via ID-porten med riktig scope, og det er en forutsetning for at systemleverandøren skal kunne administrere klienter på vegne av kunden.

• 22) Det blir vanskelig med to systembrukere, der de enten er for seg selv med Ordinær eller om de er for andre med Agent

Å bruke samme systembruker både for eget system og klientforhold vil kreve nyutvikling hos Altinn, og vi har ikke noe tidshorisont som vi kan kommunisere ut for det nå.

• 23) Bruke EIDAS for å logge inn i Maskinporten, for å kunne opprette et system

Det vil i så fall kreve ny utvikling hos Altinn, og vi har ikke noe tidshorisont som vi kan kommunisere ut for det nå.

• 1) Vi skal integrere mot Miljødirektoratets "avfallsdeklarering.no" via en integrasjonsplattform. Hvordan fungerer pålogging med en Altinn systembruker i praksis for en slik maskin-til-maskin-løsning? Vi ønsker en upersonlig pålogging uten brukerinteraksjon (som pop-ups for BankID), gjerne via et token.

Systembruker er designet for akkurat dette. Det gir en upersonlig, langtlevende pålogging på vegne av virksomheten (i dette tilfellet Norsk Gjenvinning).

- Løsningen bruker et langtlevende token som dere benytter mot etatens API. Levetiden på dette tokenet styrer dere selv.

- I motsetning til personlig pålogging via ID-porten, hvor handlinger spores til en enkeltperson, spores handlinger med systembruker tilbake til virksomheten.

- For å sette dette opp, må dere opprette en systembruker. Prosessen for dette er beskrevet på dokumentasjonssidene.

• 2) Er "klientdelegerings-API-et" nå tilgjengelig i produksjon?

Ja, klientdelegerings-API-et ble produksjonssatt i går ettermiddag (14. oktober). Se dokumentasjon av API-et.

• 3) Hvor finner jeg produksjons-URL-er for dette? Dokumentasjonen ser ut til å kun inneholde test-URL-er.

Produksjons-URL-en er den samme som test-URL-en, men uten test-identifikatorer (f.eks. fjern "tt02").

Den generelle adressen er plattform.altinn.no. Vi skal sørge for å tydeliggjøre dette i de delene av dokumentasjonen der det i dag kan være uklart.

• 4) Hvilke roller kreves for å godkjenne opprettelse av en systembruker, og kan denne retten delegeres?

Godkjenning krever Altinn-rollen "Tilgangsstyring". Daglig leder og styreleder har denne rollen implisitt, men den kan delegeres til andre personer i virksomheten som da også kan godkjenne opprettelse av systembrukere.

• 5) Når vi oppretter en systembruker via API-et, får vi tilbake en URL som kunden må bruke for å godkjenne. Er dette den eneste måten å godkjenne på per i dag? Vil det komme en funksjon i Altinn-portalen der kunden kan se og behandle forespørsler som venter på godkjenning?

Per nå er lenken den eneste måten å godkjenne på. Vi har imidlertid identifisert behovet for å kunne se og behandle ventende forespørsler direkte i Altinn-portalen, siden den som oppretter forespørselen ikke alltid er den som skal godkjenne. Dette ligger i vår backlog for å bli implementert.

• 6) Hvordan skal vi som systemleverandør håndtere rettigheter for en systembruker over tid? En kunde kan for eksempel kjøpe en ny modul som krever utvidede rettigheter. Vi har ingen måte å se hvilke rettigheter en systembruker har, spesielt siden kunden selv kan endre disse i Altinn.

Dette er en kjent svakhet per i dag. Dere må foreløpig selv holde kontroll på hvilke rettigheter som er tildelt. Vi venter på underliggende funksjonalitet før vi kan tilby et API for å slå opp hvilke rettigheter en systembruker har. Dette ligger i vår backlog.

• 7) Det nye API-et for å slå opp systembrukere per organisasjonsnummer er veldig bra. Vi ser at man får tilbake informasjon om "tilgangspakker", men ikke om enkelttjenester. Når kan vi forvente å kunne se enkelttjenester?

Det stemmer. Muligheten til å se enkelttjenester avhenger av annen funksjonalitet vi venter på. Dette ligger i vår backlog, og vi håper å ha dette på plass innen utgangen av året.

• 8) Flere av de tematiske tilgangspakkene (f.eks. "Lønn" og "Merverdiavgift") virker å være tomme. Hva er status på disse, og kan vi som systemleverandører gi tilbakemeldinger på innholdet?

Vi har i utgangspunktet ikke invitert SBSL til å komme med innspill på tilgangspakker. Fristen som er gitt nå handler om hvilke tilgangspakker som er nødvendig. Det er tjenesteeier (TE) som velger hvilke(n) tilgangspakke(r) som er relevant for deres tjenester, og SBSL må melde inn evt ønsker til aktuell(e) TE.

• 9) Vi er et regnskapskontor som får tilgang til klienter via rollen "Regnskapsfører" i Enhetsregisteret. Hvordan kan vi få systembrukertilgang for en klient som ikke er en del av denne ordningen? Vi har prøvd å delegere tilgang, men får det ikke til.

For å få tilgang til klienter der det ikke finnes knytning mellom regnskapsfører- eller revisorfirmaet og kunden i Enhetsregisteret kan kunden delegere den tilgangspakken som tjenesten krever (f.eks skattegrunnlag) til regnskapsfører- eller revisorfirmaet (på organisasjonsnummeret). Deretter kan leverandør av sluttbrukersystem sende en forespørsel om å opprette systembruker for klientforhold med den aktuelle tilgangspakken, som klientadministrator på regnskapsfører- eller revisorfirmaet kan godkjenne og knytte til aktuell kunde. Merk at en systembruker som har både tilgangspakke som følge av Enhetsregisterkobling og tilgangspakke delegert fra kunde i de fleste tilfeller ikke vil fungere. Det bør derfor opprettes separate systembrukere. Denne problemstillingen er beskrevet som et av brukerscenariene for systembruker.

• 10) Hva er forskjellen på en vanlig systembruker og en "agent systembruker"? Vi skal hente data (f.eks. påleggstrekk) på vegne av våre kunder, som er kommuner. Hvilken type skal vi bruke?

Systembruker for eget system:
Brukes når en virksomhet eller person leverer tjenester for seg selv. Den representerer kun én juridisk enhet og kan ikke ha klienter tilknyttet.

Systembruker for klientforhold:
Brukes når en tjenesteleverandør (f.eks. et regnskapsbyrå) leverer på vegne av flere klienter. Denne typen kan ha flere klienter knyttet til seg og krever en godkjenningsprosess via Altinn.

I deres tilfelle, der kunden bruker en instans av deres system for å hente egne data, høres det ut som at hver kunde skal ha en systembruker for eget system. De ulike typene systembruker er grundigere beskrevet i dokumentasjonen.

• 11) En bruker med rollen "daglig leder" godkjente en systembruker-forespørsel for en enkelttjeneste uten feilmelding. Da vi kalte API-et, fikk vi "403 Forbidden". Det viste seg at den daglige lederen som godkjente, ikke selv hadde tilgang til enkelttjenesten. Skal ikke systemet validere dette ved godkjenning?

Jo, den som godkjenner må ha tilgang til den aktuelle tjenesten. At forespørselen ble godkjent uten feilmelding høres ut som en feil. Vi ser nærmere på GitHub-isssue som ble delt av spørsmålsstiller.

• 12) Er Altinns support (første-, andre- og tredjelinje) opplært i de nye systembruker-konseptene? Kan vi begynne å sende sluttbrukerne våre dit?

Vi jobber med opplæring av support-apparatet. De bygger kompetanse og eskalerer saker de ikke kan løse. Send oss gjerne typiske spørsmål dere får fra kunder, så kan vi bruke det i opplæringen.

• 13) Finnes det dokumentasjon rettet mot sluttbrukere som vi kan peke dem til?

Ja, det finnes en egen seksjon for sluttbrukere i dokumentasjonen. Denne vil på sikt bli flyttet til altinn.no, slik at det vil være lett å vise til den mot deres brukere. Gi oss gjerne beskjed om det er mangler der. Den midlertidige dokumentasjonen finner dere her: https://docs.altinn.studio/nb/authorization/guides/end-user/system-user/

• 14) Kan det etableres en mekanisme i Slack, f.eks. en emoji, for å flagge tråder der det avdekkes mangler i dokumentasjonen?

Det er en veldig god idé. Vi ser på en løsning for dette. Målet vårt er å svare på spørsmål ved å peke til dokumentasjonen, og hvis den er mangelfull, oppdaterer vi den først.

• 1) Så langt har dere migrert data tilbake til mai. Når ser dere for dere å ha migrert data fra desember (2024) og januar (2025)? Vi spør spesifikt på grunn av Aksjonærregisteroppgaven, som leveres i den perioden. Våre kunder (ofte små bedrifter) leverer gjerne samme oppgave som i fjor, så det er en stor forenkling om vi kan hente fjorårets oppgave direkte via Dialogporten, istedenfor å måtte bruke de gamle Altinn 2-API-ene.

I utgangspunktet har vi konsentrert oss om inneværende år (2025). Målet er å nå 1. januar 2025 i løpet av de neste par ukene, for både arkiverte skjema og meldinger. Vi tar migreringen i biter for å ha kontroll på datamengdene og for å håndtere feil og særegenheter i gamle data underveis. Derfor kan vi ikke love en eksakt dato for når vi når desember/januar. Vi har imidlertid en statusside som er i støpeskjeen og snart publiseres på Docs. Der vil dere fortløpende kunne se hvor langt tilbake i tid migreringen har kommet. Oversikten blir tilgjengelig fra https://docs.altinn.studio/nb/dialogporten/

• 2) I Altinn 2 brukte vi 90-dagers samtykke via ID-porten for å hente meldinger. Finnes det en tilsvarende mekanisme i Altinn 3 / Dialogporten, eller er det kun Maskinporten med virksomhetssertifikat som gjelder nå?

Dialogporten støtter begge deler. Du kan autentisere: 1. En systembruker (via Maskinporten) 2. En person (via ID-porten) på samme måte som i Altinn 2 (90 dagers samtykke). Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/user-guides/authenticating/

• 3) Vil det si at for tjenester som krever Nivå 4, må vi fortsatt bruke ID-porten og hente samtykke fra f.eks. daglig leder?

Det er korrekt. For å oppnå Nivå 4 (som i eIDAS kalles "Høy") kreves det 2-faktor-autentisering. Det får man ikke gjennom Maskinporten. Maskinporten gir tilgang opp til Nivå 3. Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/getting-started/authorization/

• 4) Hva er grunnen til at det kreves systembruker for oppkobling til Dialogporten via Maskinporten? Det fungerer, men det er mer komplekst enn å bare bruke et vanlig access token.

Det er mer komplekst, men det er nødvendig for å fange opp fleksibiliteten i Altinns autorisasjonsmodell, noe et enkelt "scope" i et OAuth2-token ikke kan. Altinn-autorisasjon er veldig finkornet; du kan f.eks. ha tilgang til tre tjenester, men ikke den fjerde, eller signere én, men ikke en annen. Denne kompleksiteten er vanskelig å uttrykke i et standard token. I tillegg må mekanismen håndtere representasjonsforhold (f.eks. en kunde, et regnskapsbyrå og en systemleverandør). Se mer info på https://docs.altinn.studio/nb/authorization/what-do-you-get/systemuser/

• 5) Brukes "on behalf of"-mekanismen (OBO) i Maskinporten i denne sammenhengen?

Den gamle OBO-mekanismen i Maskinporten har ingenting med Altinn-autorisasjon å gjøre, og vi anbefaler generelt at en benytter den nye delegeringsmekanismen i Maskinporten som er basert på Altinn-autorisasjon. Denne brukes f.eks. hvis en kommune (som har API-tilgang) lar en leverandør kalle API-et på sine vegne. Det er viktig å merke seg at dette kun gjelder den grovkornede API-tilgangen (scope). Se info på https://docs.digdir.no/docs/Maskinporten/maskinporten_func_delegering.html

• 6) Vi har en systembruker (via Maskinporten) som vi har gitt tilgang til å hente skattekort. Da vi gjenbrukte denne systembrukeren mot Dialogporten, fikk vi også tilgang der. Må man be om en spesiell tilgang for Dialogporten?

Nei, det er den samme autorisasjonsmodellen som ligger til grunn. Policyen (rettigheten) som regulerer tilgangen til et skjema eller en melding, regulerer også tilgangen til dialogen som representerer den. Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/getting-started/authorization/

• 7) Så hvis en systembruker har fått rettighet til å rapportere Aksjonærregisteroppgaven, får den automatisk tilgang til dialogene som omhandler den oppgaven?

Ja, det er korrekt. Hvis kunden delegerer en tilgangspakke (f.eks. "Revisormedarbeider") til deres systembruker, vil alle tjenester knyttet til den pakken bli tilgjengelige når systembrukeren henter data for den kunden. Dette fungerer likt enten det er en hel tilgangspakke eller enkelttilganger.

• 8) Vi bruker en "agent systembruker" med rettighetspakken "Revisormedarbeider" for våre klienter. Jeg opplever at jeg ikke får opp alle meldinger, spesifikt meldinger knyttet til MVA-innsending i Altinn 3. Jeg ser disse meldingene hvis jeg logger inn manuelt i arbeidsflaten med samme rolle. Skyldes dette "lag" eller er det noe jeg gjør feil?

Det er vanskelig å si uten flere detaljer, men en vanlig feil er at man spør på feil part (f.eks. at man spør på egne vegne og ikke på vegne av kunden). Hvis dere har kjørt dere fast, ber vi om at dere sender inn en supportsak (se spm. 17), så kan vi se nærmere på det. Merk: Agent systembruker omtales i dokumentasjon og løsning som: Systembruker for klientforhold.

• 9) Hva er prosessen for nye data som oppstår i dag (ikke de historiske dere migrerer)?

Det er ulikt for Altinn 2 og Altinn 3:
Altinn 3 Apper: Synkroniseres fortløpende. I løpet av sekunder etter at en instans opprettes i "App", vil den dukke opp som en dialog i Dialogporten.
Altinn 2 Skjema: Vises kun i Altinn 2-innboksen mens de er under utfylling eller signering. Først når skjemaet arkiveres i Altinn 2 (dvs. etter innsending), blir det fanget opp for overføring til Dialogporten. Denne synkroniseringen skjer ca. hvert femte minutt.
Meldinger (Correspondence): Altinn 3-meldinger dukker opp umiddelbart. Altinn 2-meldinger vil dukke opp begge steder, men med en liten forsinkelse i Dialogporten (siden de må synkroniseres over).

• 10) Vi har erfart at brukere ikke finner igjen elementer i arbeidsflaten for vår første Altinn 3-app. Hva skyldes dette?

Dette kan skyldes at bruksmønsteret er litt annerledes enn i Altinn. I Altinn 3-arbeidsflaten vil skjema som brukeren selv har startet og som er under utfylling, legge seg under visningen "Utkast". Det er mulig brukerne ikke ser etter dem der.

• 11) Vi har to problemer med hvordan historiske data håndteres: 1. Historiske skjema og meldinger ser ut til å bli egne ressurser i vårt ressursregister (ISKD). Dette gjør registeret rotete, stort og tregt. 2. Titlene som vises til brukerne er uheldige. For eksempel "Brev fra Skatteetaten (migrert fra Altinn 2)", eller kryptiske skjemanavn. Brukerne forstår ikke dette, og tror kanskje de har tilgang til alle brev, ikke bare de historiske. Har det blitt gjort noen tanker om dette?

Om rot i ressursregisteret: Dette er en kjent utfordring. Siden tjenestene og delegeringene i Altinn 2 ikke er de samme som i Altinn 3, ble det besluttet å ikke migrere/synke delegeringer. Derfor må man ha doble ressurser (én for A2, én for A3). Dette er en kostnad vi må ta i overgangsfasen, og problemet vil forsvinne når Altinn 2 skrus av.
Om treghet i ressursregister-API: Det skal finnes filtreringsmuligheter i API-et for ressursregisteret, slik at man kan velge å inkludere eller ekskludere ressurser basert på Altinn-versjon (A2/A3).
Om titler: Vi kan ikke svare konkret på dette her nå, på hvilke vurderinger som er gjort rundt navngivingen; det ligger hos autorisasjons-teamet. Men vi tar med oss innspillet om at dette er en pedagogisk utfordring for brukerne.

• 12) I arbeidsflaten i Altinn 3 ser jeg mappen "Utkast", men jeg finner ingen knapp eller lenke for å starte et nytt skjema, slik man kunne i Altinn.

Det stemmer, det mangler en lenke til "skjemakatalogen" (som i Altinn 2 tilsvarte "infoportalen"). Vi er enig i at den burde vært der, slik at brukere enkelt kan finne og starte utfylling av skjema. Dette kommer i produksjon 1. desember, og er allerede på plass i testmiljøet TT02.

• 13) Forsendelser (Transmissions) i Dialogporten har en "type" (f.eks. "alert"). Er det en standard for hvordan tjenesteleverandører bruker disse? Jeg ser Skatteetaten bruker "alert" for en innsending som var godkjent, men hvor de bare ville påpeke noe.

Det finnes retningslinjer for hvordan typene skal benyttes , men vi har ingen mulighet til å håndheve at en gitt meldingstype brukes på en spesifikk måte. Det er til syvende og sist opp til tjenesteeieren (som Skatteetaten) å beslutte dette for sin tjeneste. Tjenesteeiere som NAV og Skatt har en direkte integrasjon og definerer dette selv. De fleste andre tjenesteeiere bruker Altinn 3 Apps, som gir en mer standardisert implementasjon. Se også https://docs.altinn.studio/nb/dialogporten/user-guides/service-owners/creating-dialogs/

• 14) Dette er i ferd med å skape et kaos for oss som konsumenter. Det er ikke mulig i dag å se intensjonen med en dialog, eller hva systemet (API-et) forventes å gjøre. Dialogene virker laget for et GUI, men vi skal handle på dem. Spesielt de store aktørene (NAV og Skatt) som integrerer direkte, fomler. Dere bør komme på banen med tydeligere retningslinjer for å gjøre det enklere for oss.

Vi har mekanismer i dialogmodellen, som API actions, som er tiltenkt å guide API-konsumenter om hva de kan foreta seg gitt en tilstand. Vi har nok litt å gå på for å få utnyttet det bedre. Vi antar at de fleste tjenesteeiere vil benytte Altinn 3 Apps, som gir en standardisert integrasjon. Altinn 3 tilbyr mye mer fleksbilitet enn Altinn 2, og det er nok vanskelig å lage én generisk integrasjon som håndterer alle tenkelige forretningsbehov - protokollen som må brukes vil kunne være ulik fra tjeneste til tjeneste. Dette er imidlertid en viktig tilbakemelding til de som integrerer direkte (NAV/Skatt): at de må utnytte mekanismene i datamodellen for å tydeliggjøre intensjonen og tilstanden, samt dokumentere dette grundig. Digdir som plattformleverandør har en veiledningsplikt og jobber med å etablere arenaer for å dele "beste praksis" mellom tjenesteeierne.

• 15) Når dere migrerer data, blir de gamle (migrerte) ressursene inkludert i de eksisterende tilgangspakkene? Eller må vi som systemleverandører legge til masse enkeltressurser på systembrukerne våre for å få en total oversikt i overgangsfasen?

Tilgangspakkene blir ikke satt på de migrerte ressursene, det er kun policy fra A2 som migreres sammen med instansene. Vi har ikke landet helt hvordan tilgang til historiske meldinger skal ivaretas når A2-rollene fjernes, men sannsynligvis vil nøkkelroller i virksomhetene få tilgang, og kan delegere enkelttjenester ved behov. ALternativet er at tjenesteeierne må finne tilgangspakker som gir tilgang til gamle/historiske tjenester. [Spørsmålet ble ikke besvart i møtet, svar er avklart i bakkant]

• 16) Mye av dokumentasjonen er kun på norsk. Vi har mange utenlandske utviklere og må oversette mye selv. Kan dere sørge for at dokumentasjon er tilgjengelig på engelsk?

På Docs og for Dialogporten spesifikt, skal alt være på både norsk og engelsk. Dette oppdateres fortløpende. Hvis dere finner feil eller har innspill på innhold i "Docs"-sidene er det en lenke til GitHub nederst på siden hvor en kan legge inn både issues og pull requests.

• 17) Er det en fast struktur for disse drop-in-møtene? Og er Slack den eneste kanalen for support?

Møter: Dette er første sesjon for Dialogporten. Det er ikke satt opp faste datoer, men vi vil følge opp med flere sesjoner ved behov. Invitasjoner kommer på e-post og publiseres på Samarbeidsportalen her: https://www.digdir.no/digdir/arrangementsoversikt/692.
Support: Slack er en "community"-kanal. Primærkanalen for support er e-post til vår servicedesk (servicedesk@altinn.no) eller skjema som ligger etter innlogging i Samarbeidsportalen. Da sikrer vi at saken logges i mottakssystemet vårt.