Open TageGitHub opened 1 year ago
@erlendoksvoll @DanRJ @CecilieFjellsoy Når det gjelder bankers tilgang til DD skifteattestregister vil dette kun gjelde de banker som 1) den avdøde ved sin død hadde et kundeforhold til (der KAR returnerer bankforbindelse) OG 2) der banken er med i DD løsningen
Dette betyr at DD må må holde oversikt over disse to forholden ved autentisering av forespørsel fra bank.
@TageGitHub Jeg trodde vi ble enige om at KAR-oppslaget ikke var nødvendig? Punkt 2 er ikke noe vi implementerer teknisk, det styres fra maskinporten og er drift/tilgangskontroll.
Hei, Det jeg nevnte i brukerhistorien er kravet. Ingen grunn til å gi andre aktører enn de som har et kundeforhold til avdøde mulighet til å slå opp i vårt skifteattestregister. Kravet innebærer også at banker som ikke er del av 'godkjente' DD aktører løsningen heller ikke skal ha mulighet for oppslag på skifteattester.
Mvh Tage
Fra: erlendoksvoll @.> Sendt: onsdag 13. desember 2023 10:34 Til: Altinn/oed @.> Kopi: Bryn, Tage @.>; Mention @.> Emne: Re: [Altinn/oed] Bank tilgang skifteattest API (Issue #634)
[ Ekstern e-post ]
@TageGitHubhttps://github.com/TageGitHub Jeg trodde vi ble enige om at KAR-oppslaget ikke var nødvendig? Punkt 2 er ikke noe vi implementerer teknisk, det styres fra maskinporten og er drift/tilgangskontroll.
- Reply to this email directly, view it on GitHubhttps://github.com/Altinn/oed/issues/634#issuecomment-1853564937, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQ5ZM2OY73B56GMP4EVKCATYJFY7RAVCNFSM6AAAAAA3ZTDVXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTGU3DIOJTG4. You are receiving this because you were mentioned.Message ID: @.**@.>>
@TageGitHub Vi får ta en prat med Bredo ved anledning siden han var med i diskusjonene rundt dette sist og bare lande det. Alle brukerhistoriene som går på tilgang til api-et er egentlig klare for test, med mindre vi må implementere alle kall mot aktører fra autorisasjonsløsningen for ekstra verifikasjon.
@TageGitHub - Lukkes. Som diskutert tidligere er tilgang til skifteattest-api-et uavhengig av forhold til avdøde og reguleres bare gjennom maskinporten-scopes - bruken av api-et og dataene reguleres av avtaleverk.
Brukerhistorie
Som aktør med et kundeforhold til en avdød ønsker jeg tilgang til skifteattest-API'et i Altinn dødsbo slik at jeg kan forberede henvendelser fra arving og utføre handlinger knyttet til skifte uten at annen skifteattest er nødvendig.
Krav/akseptansekriterier Gitt at en skifteattest er mottatt i Digitalt dødsbo. Når en arving ønsker å dele denne informasjonen med en aktør så skal Digitalt dødsbo tilgjengeliggjør digital representasjon av skifteattest via et oppslags API dersom 1) gjelder aktører har sendt informasjon om kundeforhold til avdøde (KAR) og derved vist at avdøde hadde et kundeforhold med aktøren og 2) banken er del av DD løsningen.
~~og varsel sendes aktøren om at skifteattest er klar for å hentes via skifteattest API'et (ev. annen mekaniske som avtales med den enkelte aktør) ~~ (tb) ikke del av MVP da behovet ikke er tilstrekkelig dokumentert~~ ~~og arvinger skal ha tilgang til logg i DD vedrørende hvilke aktører som har laste ned skifteattest.~~ (tb) tatt ut i MVP da sporingsbehovet ikke tilstrekkelig dokumentert.
Utfyllende tekst
Det er aktører som inngår i MVP OG som har sendt opplysninger om avdøde til DD som skal informeres.Utfyllende informasjon
Funksjonelt Status (ok, under avklaring, n/a): Avklaringsområder:
GUI Status: (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Teknisk Status(ok, under avklaring, n/a): Avklaringsområder:
Dokumentasjon: Ønsker aktører en hendelsesbasert trigger om at skifteattest er utstedt? I dag er det slik at arvingene leverer skifteattesten. Er det ønskelig med en tilsvarende løsning i Digitalt dødsbo?
Antagelse: Aktør har etablert mottak av dig repr av skifteattest i sine systemer via API. Når kriterier er oppfylt for tilgjengeliggjøring av elektronisk skifteattest, så tilgjengeliggjør DD dette for aktøren.
Juridisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Prioriteringskriterier produktkø
Funksjonell viktighet (må, bør, vent): Teknisk modenhet (høy, medium, lav): Samarbeidspartnere tilgjengelig (klar, under avklaring, nei, na):
Estimat
Test (sprint)
Funksjonelt Akseptert (j/n): Avvik:
System Akseptert (j/n): Avvik:
Integrasjon Akseptert (j/n): Avvik:
Brukerhistorie
Som ... ønsker jeg å .... slik at ...
Akseptansekriterier
Gitt at.. Når ... så skal ... og...
Kvalitetskrav/akseptansekriterier
Gitt at.. Når ... så skal ... og...
Utfyllende tekst
..
Utfyllende informasjon
Funksjonelt Status (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon
GUI Status: (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Teknisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Juridisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Test (sprint) Akseptansetest bh (ok ev avvik): Systemtest (ok ev avik?): Integrasjonstest (ok ev avvik):
Estimat
Grov, ved innleggelse i produktkø, dv ( 60-31, 30-11,10-3, >3): Estimat (sprint til akseptansetest): dv
Prioriteringskriterier produktkø
Funksjonell viktighet (må, bør, vent): Teknisk modenhet (høy, medium, lav): Samarbeidspartnere tilgjengelig (klar, under avklaring, nei, na):
Test (sprint)
Funksjonelt Akseptert (j/n): Avvik:
System Akseptert (j/n): Avvik:
Integrasjon Akseptert (j/n): Avvik: