elsand.github.io's People
elsand.github.io's Issues
Opprettelse av Dialogelement
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"]
Ressurs-orientert navngiving av API
Bedre å velge mer "ressurs"-orientert navngiving på APIet? F.eks. dialogporten.no/dialogelement/{id} osv.
[anchor_id="openapi"]
SSO
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"]
Asynk oppdatering av Dialogport og løsere kobling
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"]
Validering av opak token
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"]
Sluttbruker initiert dialog gjennom API
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"]
Ang pilen "endre tjenesteressurs med oppgitt
Denne pilen må gå til "Dialogporten" ikke Ressurs registeret
[anchor_id="sekvensdiagram"]
Tilgang til Dialogelement
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"]
Synkron oppdatering av DBE
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"]
Dobble piler for endring av tjenesteressurs?
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"]
Felles Arbeidsflate som eksempel
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"]
Abonnement på hendelser for en part
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"]
Sjekk mot Dialogport om allerede påstartet dialog unødvendig?
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"]
Diagram
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"]
Pil med «administrer dialogelementer gjennom» for Altinn 3 App
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"]
Tydeliggjøring av hva produktet er / omfatter
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"]
Personvern
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"]
SMART om FHIR?
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"]
Navngiving "Dialogport" versus "Dialogboks"
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"]
Token som query string parameter
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"]
Tilsvarende systemer hos NAV
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"]
Ang konsum gjennom GUI eller API
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"]
Multiple audiences versus tokeninnveksling
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"]
Sekvensdiagrammer
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"]
GUI vs API
Vurder å splitt dette begrepet for å skille API-delen og denne felles implementasjonen av GUI. Kanskje bruke "felles arbeidsflate" for sistnevnte?
[anchor_id="dialogboksen"]
Tilgangsstyring "internt" for store tjenestetilbydere
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"]
Erstatte "mutering" med "oppdatering"
Gul overskrift «Mutering av DE» --> bør dette heller kalles «oppdatering av DE»?
[anchor_id="opprettelse-av-dialogelement"]
Testeissue
Dette er en testeissue
[anchor_id="dialogboksen"]
kommunikasjon ut til bruker
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"]
Pil "implementerer" fra Arbeidsflate og SBS
Bør pilen «implementerer» fra felles arbeidsflate og SBS til Dialogport heller tagges som «benytter»?
[anchor_id="overordnet-diagram-over-konsept"]
Digitale dialoger kan være
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"]
Ang Dialogporten-spesifikke claims
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"]
Tjenestetilbyders verifisering av token
I steg 4 bør det inkluderes informasjon om hvordan tjenesteeier verifiserer maskinporten token.
[anchor_id="tekstlig-beskrivelse-av-trinn-2"]
Sesjonstoken
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"]
Generelle tema
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"]
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.