elsand / elsand.github.io Goto Github PK

Denne pilen må gå til "Dialogporten" ikke Ressurs registeret

[anchor_id="sekvensdiagram"]

Gul overskrift «Mutering av DE» --> bør dette heller kalles «oppdatering av DE»?

[anchor_id="opprettelse-av-dialogelement"]

Under overskriften "Mutering (oppdatering) av dialogelement" kommer på nytt stiplede piler for oppdatering av tjenesteressurs. Er dette en copy/paste feil og skal fjernes? Hvis ikke bør det forklares i teksten nedenfor hvorfor de er oppført på nytt - dette kan selvfølgelig skje, men hører vel egentlig ikke til standardløpet for oppdatering av et dialogelement?

[anchor_id="opprettelse-av-dialogelement"]

Bør definisjonen av Dialogtjeneste også inkludere kommunikasjon ut til bruker inkludert deling av informasjon med bruker, og ikke bare innhenting av informasjon? Ref scenarier som beskrives lengre ned på siden?

[anchor_id="dialogtjeneste"]

Dette er en testeissue

[anchor_id="dialogboksen"]

Usikker på om det er en god idé å tilby en mekanisme for å foreta et synkront oppslag for å refreshe dialogbokselementet ved åpning, i stedet for å legge opp til at tjenestetilbyder alltid må selv sørge for å holde elementet oppdatert. Førstnevnte skaper hardere bindinger til eksterne endepunkter, og vil ha teknisk/praktiske konsekvenser som i noen tilfeller - f.eks. et SBS som itererer gjennom og åpner mange elementer - kan ha negativ innvirkning på tilgjengelighet.

[anchor_id="dialogelement-de"]

Pil med «administrer dialogelementer gjennom» for Altinn 3 App skal vel gå fra Altinn 3 App og ikke Digdir?

[anchor_id="overordnet-diagram-over-konsept"]

Nav utforsker SMART on FHIR for å kunne tilby tjenester i helsepersonells sluttbruker system, er det aktuelt å vurdere i sammenheng med dialogporten? De har laget en rapport med erfaringer fra pilot, se
https://www.ehelse.no/publikasjoner/na-snakker-vi-utredning-om-forbedret-informasjonsutveksling-mellom-nav-og-helse-og-omsorgstjenesten

[anchor_id="sluttbrukersystem-sbs-og-fagsystem"]

Det er kanskje interessant for deg og se to av NAVs systemer som ligner veldig. Mulig at Håkon Jendal allerede har delt disse med deg, men her er de:

• https://navikt.github.io/arbeidsgiver-notifikasjon-produsent-api/ (rettet mot arbeidsgivere, tilgangsstyrt på enkeltrettigheter og NAV-interne registre)
• https://navikt.github.io/brukernotifikasjon-docs/ (til personbrukere, tilgangsstyrt på fnr)

Begrepsoversettelse blir noe sånt som:

• Dialogelement ~ beskjed, oppgave
• Dialoggruppe ~ sak (men brukernotifikasjoner har gått bort fra saker/dialoggrupper tror jeg)

[anchor_id="introduksjon"]

I tilfellet at en autentisert konsument opptrer på vegne av en annen part (som kan være en virksomhet, innbygger eller selvregistert bruker ):
Er det tenkt at man skal få tilbake en liste med alt som finnes av instanser/spesialisert dialoger i listen som returnere?
Eller kreves det at man bare returnerer en liste over bare de instanser/sesialiserte dialoger som bruker faktisk har tilgang til i henhold til policy for tjenesteressursen?

Jeg antar svaret på det vil avhenge av hvor "sensitive" data man mener det er behov for å vise konsumenten i en slik liste.

[anchor_id="sekvensdiagram-1"]

Skal ikke token inneholde informasjon om hvem virksomhetsbruker er (altsåsystemidentitet i Altinn med tildelte rettigheter som gir tilgang til tjenesteressursen),

[anchor_id="dialogporten-spesifikke-claims"]

Figuren viser at man må gjøre et kall for å validere token. Bør vel være self contained token (eller hav det heter) slik at man ikke må gjøre dette kallet, men kan validere tokenet der og da?

[anchor_id="sekvensdiagram-1"]

Bør siste setning justeres litt for å tydeliggjøre selve løsningen/produktet - f.eks. noe slikt: «Dialogporten benyttes også som navn på løsningskomponenten (produktet) som tilbyr API for enhetlig tilgang og håndtering av digitale dialoger til Felles Arbeidsflate(r) og Sluttbrukersystemer, inkludert lagring av metadata om dialogene, og som dekker Altinn Platform-funksjonalitet for tilgangsstyring og -kontroll, hendelser og varsling».

[anchor_id="dialogporten"]

Ref. steg 2: vi bør vurdere hvordan slik kall-serier skal løses: mutiple audiences for et token versus innveksling av tokens

[anchor_id="tekstlig-beskrivelse-av-trinn-2"]

I steg 4 bør det inkluderes informasjon om hvordan tjenesteeier verifiserer maskinporten token.

[anchor_id="tekstlig-beskrivelse-av-trinn-2"]

Veldig bra dette :-)

Tror det utover i januar hadde vært nyttig å ha dedikerte møter hvor vi prater oss igjennom ett og ett sekvensdiagram og blir enige om justering, noterer hva som er uavklart og eventuelle uenigheter som det bør jobbes med.

[anchor_id="introduksjon"]

Vurder å splitt dette begrepet for å skille API-delen og denne felles implementasjonen av GUI. Kanskje bruke "felles arbeidsflate" for sistnevnte?

[anchor_id="dialogboksen"]

Vi er litt usikre på navnet Dialogport, gitt at verdien av løsningen ikke nødvendigvis ligger i at det er en felles "port" som alle/alt skal gjennom, men heller en felles samling og håndtering av digitale dialogtjenenster på tvers av flater og tjenensteeiere.

[anchor_id="dialogporten"]

Felles Arbeidsflate er et konkret eksempel på GUI-basert bruk av Dialogport-APIet, dvs. at det kan finnes andre typer GUI-klienter på lik linje - bør vi skrive det tydelig er sted, f.eks. over sekvensdiagrammene for GUI-basert bruk?

[anchor_id="konsum-gjennom-gui-portal"]

Tenker vi burde hatt et eget avsnitt på personvern her. I dette konseptet vil man kunne unngå at det som legges på Dialogporten er personsensitivt ved at dokumentasjonen hentes fra NAV/Skatt og ikke ligger i meldingsboksen slik det gjøres i dag.

[anchor_id="autorisasjon"]

Validering av sesjonstoken gjøres av dialogporten i denne figuren – dette blir vel feil, dialogporten har vel ikke noe forhold til brukerens sesjon? Ref også tekst under sekvensdiagrammet på steg 4 kulepunkt 2: "Når tjenestetilbyder mottar forspørsel fra nettleser, gjøres et bakkanal-oppslag mot Dialogporten tjenestetilbyder-API hvor sesjonstoken oppgis. Returnerer en modell som forteller autentisert part (f/dnr, orgnr),
valgt aktør, ...."

[anchor_id="konsum-gjennom-gui-portal"]

Kunne det vært en ide at dialogelement først blir laget etter at virksomhet har utført sin endring? Reduserer antall handlinger mot "Dialogporten".

[anchor_id="sekvensdiagram-3"]

Hadde det vært lurt å ta en diskusjon på sekvensdiagrammene på både med og uten instansiering? Er det en mulighet for å forenkle sekvensdiagrammet ved at man avventer med å opprette et dialogelement til senere i prosessen?
Tror ikke vi har diskutert ferdig hvordan en SBS teknisk går fram for å kalle et API. Det vil si hvilken funksjonalitet API katalogen tilbyr etc. og hva som skal til for å sikre at API "alignes" tilfredsstillende slik at det ikke blir unødvendig komplekst for leverandørene.

[anchor_id="gjennom-api"]

Usikker på om det kommer klart nok frem at den felles GUI-flaten "bare" er én mulig implementasjon av API-et, og at det også rent teknisk vil være et sluttbrukersystem. Har lagt inn en "implementerer"-linje for å indikere dette.
[anchor_id="overordnet-diagram-over-konsept"]

Bør pilen «implementerer» fra felles arbeidsflate og SBS til Dialogport heller tagges som «benytter»?

[anchor_id="overordnet-diagram-over-konsept"]

For større tjenestetilbydere som NAV, så tenker jeg det er uheldig å ikke ha noe mer finkornet tilgangsstyring på API-et som tjenestetilbydere bruker. Altså hvis én NAV-tjeneste blir hacket, så er dumt om dialogporten kan bruke for å lekke dialoger for helt urelaterte tjenester.

I NAVs notifikasjonsplattform for arbeidsgiver (https://navikt.github.io/arbeidsgiver-notifikasjon-produsent-api/) så er produsenter tilgangsstyrt på "merkelapper", slik at de ikke kan se dialogen til andre team. Samtidig ser jeg på https://app.swaggerhub.com/apis-docs/Altinn/Dialogporten/0.0.1 at det ikke er noe måte å liste opp eller søke etter dialoger: om det er et bevisst valg, så hjelper jo det betydelig.

[anchor_id="tjenestetilbyder"]

Supert underlag og godt beskrevet konsept!
Vi har et par generelle tema vi bør diskutere fremover:

• "Aktiv port" versus "passiv boks": Vår oppfatning er at løsningen (dialogport/dialogboks) ikke skal være en "port" som alt/alle skal gjennom. Det er et mål for oss at det er så løse koblinger som mulig mellom tjenesteeiers systemer (som er "master" for dialogenes innhold og status) og Dialogporten/Dialogboksen som holder på en asynkront oppdatert kopi av metadata om tjenesteinstansene (i form av et dialogelement). Kall bør ikke gå via "porten" hvis det ikke gir en egen nytte/verdi? F.eks. går oppslag på et dialogelement som tilhører en hendelse/event alltid via Dialogporten, gir det verdi/mening? Alternativt kall direkte til URL til tjenesteinstans hos tjenesteeier.
  --> Tankekors til diskusjon: blir modellen med kombinasjonen direkte til TE eller via DialogPort for kompleks, og kan dette forenkles?

• Vi må se på sammenhengen til dagens Instances-API på Altinn3 - det er lite hensiktsmessig for de som bruker dette i dag at det lages noe helt nytt på siden? Og den nye Dialogport erstatter vel (langt på vei) behovet?

• Noen steder nevnes «subressurs» - hvordan er sammenhengen mellom TjenesteRessurs og Subressurs <-> handling?
  «Er gjenstand for autorisasjon definert av referert tjenesteressurs og eventuell subressurs. F.eks. vil f.eks. “Signer” kunne kreve andre rettigheter avhengig av policy knyttet til tjenesteressursen.»

• Vi må jobbe litt mer med hvilke handlinger og statuser som er forhåndsdefinert (og evt. "standard"/default" og hvilke som «tilhører» og/eller tolkes av hvilke komponenter - dette tas fra det funksjonelle arbeidet som går i parallell.
  o f.eks. står det innledningsvis under begrepsforklaringen «GUI handlinger» at det kun er «slett» som Dialogporten har knyttet semantikk til. Vi er usikre om det bør kunne slettes fra Dialogporten.
  o Eksempler på handlinger under 1. sekvensdiagram – steg 2 “Åpne”, “Arkiver”, “Slett”, “Bekreft”, “Signer”, “Betal”, “Les mer”, etc. --> arkiver er en handling som kun Arbeidsflaten har et forhold til? (under 2. sekvensdiagram nevnes «arkivering» i steg 6)
  o Eksempler på status Status 1. sekvensdiagram – steg 2 (“under utfylling”, “klar til signering”, “venter på andre”, “venter på svar fra tjenestetilbyder” etc)

• Api 'ene for dialoger må være utvidbare uten at det påvirker de som allerede har tatt det i bruk (vi ønsker jo på sikt å jobbe med omnikanal, legge på nye "standard" handlinger / status, se på støtte for sammenhengende tjenester etc. fremover?)

[anchor_id="introduksjon"]

Opt steg 3: bakkanal kall for sjekk om det finnes allerede påstartet dialog -> denne trengs vel ikke, tjenesteeier er «master» og skal alltid ha fasiten?

[anchor_id="tekstlig-beskrivelse-av-trinn-3"]

Generelt sett tenker jeg det er bedre at Dialogporten oppdateres asynk i etterkant, og ikke underveis, for å få en løsere kobling.
Må ellers passe på transaksjonskontekst (boundary) - Event kan først fyres av når både tjeneteinstans hos TE og DE hos dialogport finnes og gjensidig referer hverandre. Bedre at TE er "master" og generer tjenesteinstans med ID og bestemmer ID for Dialogelement også (samme?)? (ellers må TE mellom steg 5 og 6 kalle Dialogport for å signalisere at kobling mellom Tjenensteinstans og DE er opprettet og klar til at event kan sendes...).

[anchor_id="variant-uten-instansierings-api"]

Til listepunkt 3: sending av digital post – siste kulepunkt «Teknisk/funksjonelt subset av tjenestetilbyder-initiert dialog.» --> melding til parten/bruker (f.eks. digital post) er ofte en del av (subset) av begge typene ovenfor, altså også som et svar i en Sluttbruker-initiert dialog.
En dialog kan også omfatte begge de to scenarioene, altså at det er mulig å initiere den både fra tjenesteeier og fra Sluttbruker - bør det nevnes til slutt?

[anchor_id="scenarioer-som-påvirker-dialogporten"]

Bedre å velge mer "ressurs"-orientert navngiving på APIet? F.eks. dialogporten.no/dialogelement/{id} osv.

[anchor_id="openapi"]

Steg 1: "SBS abonnerer på hendelser knyttet til opprettelse av dialogelementer av en eller flere typer," --> må legge til "for en spesifikk part"? (det finnes mulighet for å filtrere slik at SBS ikke får alle hendelser av en viss type?)

[anchor_id="tekstlig-beskrivelse-av-trinn-2"]

For NAVs del vil det kunne være behov for å kunne få tilgang til alle Dialogelementer som er knyttet til NAV slik at vi kan spegle disse på NAVs side for arbeidsgivere. Hvilken vei en arbeidsgiver kommer inn til det offentlige kan variere, så dersom NAV kan spegle disse Dialogelementene så vil bruker oppleve å se det samme uavhengig av hvilken vei man går inn.

[anchor_id="dialogelement-de"]

Bruker bør oppleve SSO på tvers av Dialogporten og tjenestetilbyder. Det bør ikke bli slik det fungerer med Digipost og kommunene hvor man først logger seg på Digipost og så kommunen for å få tilgang til noe.

[anchor_id="dialogelementtoken-det"]

Dersom brukere omdirigeres til en lenke med token som query string parameter, vil ikke tokenet ligge som klartekst i brukerens browser historikk? I tillegg anses tradisjonelt ikke en url som en hemmelighet og havner ofte i diverse systemlogger. Her mener jeg at det kan være potensialer for noen unødvendige angrepsvektorer. Hvilke vurderinger, om noen, er gjort til rundt denne problemstillingen?

[anchor_id="overføring-av-token-til-tjenestetilbyder"]