DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2

Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer... 4 3.1.1 Metode input- og outputstrukturer... 4 3.1.2 DatoTid elementer... 5 3.1.3 ReturnMessage... 7 3.2 Adgangspunkt... 8 3.2.1 Adgangspunkt opret... 11 3.2.2 Adgangspunkt slet... 11 3.2.3 Adgangspunkt hent... 12 3.2.4 Adgangspunkt ret... 12 3.3 Husnummer... 13 3.3.1 Husnummer opret... 15 3.3.2 Husnummer slet... 16 3.3.3 Husnummer hent... 16 3.3.4 Husnummer ret... 16 3.4 Adresse... 17 3.4.1 Adresse opret... 19 3.4.2 Adresse slet... 20 3.4.3 Adresse hent... 20 3.4.4 Adresse ret... 20 4 Adgang og sikkerhed... 22 4.1 Adgang... 22 4.2 Sikkerhed... 22 Version 1.1 Side 1 af 22

1 Ændringer i forhold til forrige version Version Bemærkning 1.0 Første udgave 1.1 Forretningslogikken i DAR tillader ikke, at et husnummer oprettes uden at der samtidig også oprettes en adresse. Derfor er der i opret-husnummer kaldet blevet tilføjet en adressestruktur, som skal udfyldes og som opretter den første adresse under husnummeret sammen med husnummeret. 1.2 Bemærkningsfelt tilføjet til adresse. Nyt endpoint til demoserveren. Version 1.1 Side 2 af 22

2 Introduktion Denne snitfladebeskrivelse beskriver grundlaget for udveksling af data med Danmarks Adresseregister (DAR) via webservicesnitfladen AddressServiceV1. Baggrunden for snitfladen er, at man ønsker at registrere og opdatere adressedata i DAR ved webservicebaseret overførsel fra et eksternt system i OIOXML format. Denne snitfladebeskrivelse svarer til følgende version af webservicen: AddressServiceV1.svc. I produktionsmiljø findes snitfladens endpoint her: Kommer senere. Snitfladens dokumentation, snitfladens wsdl dokumenter for både produktions- og demoversionen vil man kunne finde på DARs demoserver, hvor den kan tilgås uden certifikater. I demomiljøet findes snitfladens endpoint her: https://demodar-services.bbr-kommune.dk/addressservicev1.svc Wsdl'en er ikke eksponeret i produktion. Man skal bruge den fra demomiljøet og erstatte endpointet når man vil køre op mod produktion. Snitfladen giver kort sagt mulighed for oprettelse, nedlægning og opdatering af adressedata i DAR, på entiteterne adgangspunkt, husnummer og adresse. 2.1 Formål Formålet med webservicen er at adressedata kan vedligeholdes af eksterne systemer uden for DAR. For at søge og læse adresser henvises til AWS Suiten. 2.2 Læsevejledning Dokumentet består ud over en introduktion af et afsnit "Beskrivelse", hvor der gives en kort introduktion til entiteternes indbyrdes sammenhæng, samt en beskrivelse af de elementer og karakteristika der er fælles for entiteterne. Senere i afsnittet gives en beskrivelse af alle entiteterne og de metoder, der er knyttet til dem. Afsnit 4 Adgang og sikkerhed beskriver sikkerhedsmodellen og de endpoints hvor servicen er udstillet. 3 Beskrivelse Webservicen indeholder 12 CRUD metoder (operationer). Disse 12 CRUD metoder er fordelt på 3 entiteter hvis indbyrdes relationer fremgår af den logiske model i Figur 1. Version 1.1 Side 3 af 22

Adgangspunkt 1 0..1 Husnummer 1 1..* Adresse Figur 1 Logisk model. Webservicen er opbygget, så man opererer på én entitet type ad gangen. Det betyder, at man bl.a. kan opdatere en adresse uden at skulle forholde sig til dets husnummer eller adgangspunkt. Ved opdatering af en entitet er det vigtigt at medsende alle felter, ellers vil de manglende felter blive nulstillet, hvis det er muligt for valideringsreglerne i DAR. I det efterfølgende er de vigtigste strukturer for de 3 entiteter samt fælles elementer med tilhørende metoder beskrevet. 3.1 Fælles elementer og strukturer I dette afsnit beskrives nogle af de vigtigste elementer og strukturer, som benyttes på tværs af flere metoder og de elementer og strukturer, som har samme karakteristika. 3.1.1 Metode input- og outputstrukturer Alle metoder i webservicen falder i en af følgende kategorier: Hent, Opret, Ret eller Slet. Til hver metode er der unikke strukturer, som definerer henholdsvis input og output til metoden. Disse strukturer er navngivet efter følgende mønster: <entitet><metode>inputstructure og <entitet><metode>-outputstructure. I Figur 2 vises et eksempel på inputstrukturen for opret metoden for et adgangspunkt. Version 1.1 Side 4 af 22

Figur 2 Grafisk repræsentation af AccessPointCreateInputStructure 3.1.2 DatoTid elementer Hver entitetsstruktur indeholder fire DatoTid elementer. Disse elementer er kun til informations formål og kan ikke opdateres gennem webservicen. De fire elementer er beskrevet i Tabel 1 nedenfor. I den nuværende version af OIO snitfladerne kan kun den aktuelle version hentes, dvs. versionen med VirkningstidSlut og RegistreringstidSlut sat til null. Tabel 1 DatoTid elementer. ActuelFromDateTime/Virkningstid start Beskriver tidspunktet hvorfra at entiteten afspejler virkeligheden. ActuelToDateTime/Virkningstid slut RecordFromDateTime/Registreringstid start RecordToDateTime/Registreringstid slut Beskriver tidspunktet hvorfra at entiteten ikke længere afspejler virkeligheden. Beskriver tidspunktet hvorfra denne entitet reflekterede systemets viden om virkeligheden. Beskriver tidspunktet hvorfra denne entitet ikke længere reflekterede systemets viden om virkeligheden. Version 1.1 Side 5 af 22

Bitemporale egenskaber I DAR er implementeret dobbelthistorik ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter virkningstid og registreringstid håndteres i sammenhæng. Selv om modellen understøtter bitemporale egenskaber så der i nuværende version af DAR ikke er muligt at håndtere/benytte flere virkningstider igennem OIO snitfladerne. I DAR 0.9 vil alle ændringer således blive håndteret som reelle ændringer og der er ingen mulighed for at lave fejlrettelser tilbage i tiden. Når data rettes, gemmes den gamle version med RegisteringsSlut og der oprettes to nye versioner i Version tabellen. Eksempel for et adresselivsforløb I det følgende beskrives et livsforløb for en adresse i DAR 0.9: Adressen oprettes Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV 1.1.2001 1.1.2001 Adressen ændres til gældende Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV 1.1.2001 1.1.2009 1.1.2001 Foreløbig ST TV 1.1.2009 1.1.2001 1.1.2009 Gældende ST TV 1.1.2009 1.1.2009 Adressen nedlægges Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV 1.1.2001 1.1.2009 1.1.2001 Foreløbig ST TV 1.1.2009 1.1.2001 1.1.2009 Gældende ST TV 1.1.2009 1.1.2014 1.1.2009 Gældende ST TV 1.1.2014 1.1.2009 1.1.2014 Nedlagt ST TV 1.1.2014 1.1.2014 Version 1.1 Side 6 af 22

3.1.3 ReturnMessage Alle Hent, Opret, Ret eller Slet metoder returnerer en ReturnMessageStructure, som ses i Figur 3. Figur 3 Grafisk repræsentation af ReturnMessageStructure. Tabel 2 ReturnMessageStructure elementer. ReturnMessageTypeCode Angiver en kode for hvilken type resultatet er af: 0: OK 10: Fejl men statuskode indeholder eventuelt nummer på valideringsfejl, og statustekst indeholder en eventuel tekstuel beskrivelse af valideringsfejlen. 30: Not Found Exceptions hvor statuskode er 0, men statustekst indeholder en eventuel tekstuel beskrivelse af fejlen. ReturnMessageStatusCode ReturnMessageStatusText Angiver en kode for resultatet, som enten er 0: OK eller nummeret på en specifik valideringsfejl. En tekstuel beskrivelse af resultatet. I nogle enkelte tilfælde vil ReturnMessageTypeCode være 0 og ReturnMessageStatusText indeholde en supplerende tekst. Det betyder at opdateringen er gået godt, men at der gøres opmærksom på specielle situationer, som f.eks. at koordinaterne ligger udenfor kommunegrænsen. Version 1.1 Side 7 af 22

3.2 Adgangspunkt Et adgangspunkt udpeger en bestemt adgang ind på et areal eller ind i en bygning/teknisk anlæg. Følgende figur viser strukturen for et adgangspunkt: Tabel 3 specifikke felter for adgangspunkt AccessPointEastingMeasure AccessPointNorthingMeasure Elementet beskriver adgangspunktets 'østlige' position. (Xkoordinat) Elementet beskriver adgangspunktets 'nordlige' position. (Ykoordinat) Version 1.1 Side 8 af 22

X- og Y- koordinat er krævede for alle adgangspunkter uanset status. Der må ikke oprettes eller opdateres koordinater med værdien (0,0). x, y koordinater skal normalt ligge i kommunen. Reglen vedligeholdes i DAR 0.9 ved hjælp af webservice kald til GST. Adgangspunktet kan oprettes/opdateres dog selv om GST ikke kan levere et passende kommunenummer eller GST leverer et andet kommunenummer. AccessPointQualityClassCode Elementet beskriver adgangspunktets nøjagtighedsklasse. Værdierne udtrykker et overordnet kvalitetsmål for stedfæstelsen. Kodeværdier: A - Absolutte adressekoordinater - stedfæstelsen bør pege på det rigtige objekt, jf. specifik f. teknisk kort B - Beregnet koordinatsæt, foreløbig, omtrentlig stedfæstelse U - Adresse uden koordinater - stedfæstelse ukendt Feltet er krævet for alle adgangspunkter uanset status. Der må ikke oprettes/opdateres adgangspunkter uden at der er angivet koordinater, derfor er kodeværdien U ikke tilladt ved oprettelser og opdateringer. Ved opdatering kan en dårlig nøjagtighedsklasse ikke overskrive en bedre nøjagtighedsklasse. AccessPointSourceCode Kode til kilde for geometridata på adgangspunktet. Kodeværdier: 1 - Oprettet maskinelt på baggrund af teknisk kort 2 - Oprettet maskinelt på baggrund af matrikelnummer tyngdepunkt 3 - Eksternt indberettet af konsulent på vegne af kommunen 4 - Eksternt indberettet af kommunes GIS- eller kortkontor o.l. 5 - Oprettet af kommunens BBR- eller adresseansvarlige (teknisk forvaltning) Feltet er krævet for alle adgangspunkter uanset status. De gældende kodeværdier skal benyttes. AccessPointStatusCode Beskriver status for adgangspunktet Kodeværdier: 1- Gældende 2- Nedlagt Version 1.1 Side 9 af 22

3- Foreløbig 4- Henlagt Ved oprettelser og opdateringer må status 1 og 3 benyttes. AccessPointTechnicalStandardCode Kode for teknisk standard for geometridata Kodeværdier: TD - Husnummer placeres 3 meter inde i bygningen ved det sted hvor indgangsdør e.l. skønnes placeret, eventuelt med en retningsvinkel der er orienteret i forhold til den adressegivende vejs vejmidte TK - Udtrykkelig TK-standard: 3 meter inde i bygning, midt for længste side mod vej og roteret TN - Alm. teknisk standard: bygningstyngdepunkt eller blot i bygning og roteret UF - Uspecificeret/foreløbig; ikke nødvendigvis placeret i bygning, ikke nødvendigvis roteret Teknisk standard skal angives ved oprettelser og opdateringer og alle kodeværdier kan benyttes. AccessPointTextAngleMeasure Elementet beskriver retningen for et adgangspunkt, retningen kan gå fra 0 til 400 grader. Retning angives ved oprettelser og opdateringer. Hvis feltet ikke angives ved oprettelser, sættes retning til 200.00. AccessPointTextJustificationCode Placering af husnummer i forhold til adgangspunktet på kortet jf. DSFL. Et heltal: 1, 2, 3, 4, 5, 6, 7, 8 eller 9. Placering angives ved oprettelser og opdateringer. Hvis feltet ikke angives ved oprettelser, sættes den til 5. AccessPointUniversalIdentifier ESDHreferenceIdentifier FileNumberIdentifier RevisionDateTime Specificerer en unik ID for et adgangspunkt. Feltet kan ikke indberettes, men sættes automatisk af systemet ESDH reference er et link til sagen i ESDH (Elektronisk sags- og dokumenthåndtering). Journalnummer er et valgfrit felt, hvor kommunen kan indtaste et journalnummer. Revisionsdato: Dato for seneste revision (godkendelse eller ændring) af geometridata (felterne x-koordinat, y-koordinat, retning). Feltet er krævet. Ved opdatering skal revisionsdato være lig med eller nyere end eksisterende revisionsdato. Hvis revisionsdatoen ikke angives eller hvis revisionsdatoen er uændret, men koordinaterne eller retning er ændret, sættes revisionsdatoen automatisk til dagsdato. Version 1.1 Side 10 af 22

Tabel 4 Genbrugte felter fra digitaliser.dk MunicipalityCode En kommunes kode. Klarteksten af en kommune skal findes ved at referere til myndighedstabellerne i Det Centrale Personregister. Koden vil altid være unik. 3.2.1 Adgangspunkt opret Benyttes til at oprette et adgangspunkt. For at oprette adgangspunktet skal strukturen AccessPointCreateInputStructure udfyldes. Denne struktur består af en AccessPointStructure, som udfyldes med alle relevante felter. AccessPointUniversalIdentifier udfyldes ikke ved opret, da DAR angiver adgangspunktets id. Strukturen AccessPointCreateOutputStructure returneres, indeholdende AccessPointStructure med data fra det oprettede adgangspunkt, og en ReturnMessageStructure med status for kaldet. 3.2.2 Adgangspunkt slet Benyttes til at slette et adgangspunkt. Når et adgangspunkt slettes, slettes også det underliggende husnummer og adresserne. For at slette et adgangspunkt skal AccessPointUniversalIdentifier, som er adgangspunktets id, udfyldes: Strukturen AccessPointDeleteOutputStructure returneres, indeholdende en ReturnMessageStructure med status for kaldet. Version 1.1 Side 11 af 22

3.2.3 Adgangspunkt hent Benyttes til at læse et adgangspunkt. For at læse et adgangspunkt skal strukturen AccessPointUniver salidentifier udfyldes: Strukturen AccessPointGetByIdOutputStructure returneres, indeholdende AccessPointStructure med data fra det hentede adgangspunkt, og en ReturnMessageStructure med status for kaldet. 3.2.4 Adgangspunkt ret Benyttes til at opdatere et adgangspunkt. For at opdatere et adgangspunkt skal strukturen AccessPointUpdateInputStructure udfyldes: Vær opmærksom på at alle felter i AccessPointStructure som ikke angives ved ret af et adgangspunkt, vil blive forsøgt nulstillet i DAR, hvis de ikke medsendes. Strukturen AccessPointUpdateOutputStructure returneres, indeholdende AccessPointStructure med data fra det opdaterede adgangspunkt, og en ReturnMessageStructure med status for kaldet. Version 1.1 Side 12 af 22

3.3 Husnummer Et husnummer udpeger et bestemt adgangspunkt, som giver adgang til en eller flere adresser. Følgende figur viser strukturen for et Husnummer: Tabel 5 specifikke felter for husnummer HouseNumberUniversalIdentifier HouseNumberStatusCode Specificerer en Unik ID for et husnummer. Elementet beskriver status for husnummeret. Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Ved oprettelser og opdateringer må status 1 og 3 benyttes. Version 1.1 Side 13 af 22

HouseNumberSourceCode Kode til kilde for husnummeret Kodeværdier: 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l. 11 - Oplysning fra anden kilde Feltet krævet ved oprettelser og opdateringer og alle kodeværdier kan vælges. ValidDateTime Angiver entitetens ikrafttrædelsesdato. Feltet kan indberettes, men hvis det ikke indberettes sættes datoen automatisk til den dato, hvor husnummeret ændrer status fra Foreløbig til Gældende. Ikrafttrædelsesdatoen må ikke fremdateres. AccessPointUniversalIdentifier Fremmednøgle til husnummerets adgangspunkt Tabel 6 Genbrugte felter fra digitaliser.dk StreetCode Erklærer en navngivet gade, vej, plads, sti eller lignende i kode Feltet er krævet for gældende husnumre. Feltet vejkode skal opfylde de officielle definitioner i hvert fald hvis det indberettes. StreetBuildingIdentifier Husnummer inkl. et valgfrit bogstav, der identificerer en bestemt adgang til en bygning, en grund/jordstykke eller en fabrik etc. Feltet er krævet for gældende husnumre. Feltet skal opfylde de officielle definitioner i hvert fald hvis det indberettes. Der gælder følgende ifølge adressebekendtgørelsen: På grund af risikoen for forveksling må bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Version 1.1 Side 14 af 22

Der gives fejl hvis man prøver at oprette eller ændre et husnummer til et husnummer med de uhensigtsmæssige bogstaver. Det vil dog være muligt at opdatere et eksisterende husnummer som har de uhensigtsmæssige bogstaver. StreetName Det godkendte navn på en vej, et torv, en plads, en sti og lignende. Feltet opdateres automatisk ud fra vejkode og husnummeret. PostCodeIdentifier Postvæsenets landsdækkende postnummerkode. Feltet opdateres automatisk ud fra vejkode og husnummeret. DistrictName Angiver postdistriktets navn i klarskrift. Feltet opdateres automatisk ud fra vejkode og husnummeret. DistrictSubDivisionIdentifier Angiver bynavn. Feltet opdateres automatisk ud fra vejkode og husnummeret. 3.3.1 Husnummer opret Benyttes til at oprette et husnummer. For at oprette husnummeret skal strukturen HouseNumberCreateInputStructure udfyldes. Denne struktur består af en HouseNumberStructure og en AddressStructure, som udfyldes med alle relevante felter. HouseNumberUniversalIdentifier og AddressUniversalIdentifier udfyldes ikke ved opret, da DAR angiver id er. Det er vigtigt at udfylde AddressStructure ved oprettelse af et husnummer, da datamodellen i DAR kræver, at et husnummer har en adresse. Strukturen HouseNumberCreateOutputStructure returneres, indeholdende HouseNumberStructure med data fra det oprettede husnummer, AddressStructure som indeholder data fra det oprettede husnummer, og en ReturnMessageStructure med status for kaldet. Version 1.1 Side 15 af 22

3.3.2 Husnummer slet Benyttes til at slette et husnummer. Når et husnummer slettes, slettes også de underliggende adresser. For at slette et husnummer skal HouseNumberUniversalIdentifier, som er husnummerets id, udfyldes: Strukturen HouseNumberDeleteOutputStructure returneres, indeholdende en ReturnMessageStructure med status for kaldet. 3.3.3 Husnummer hent Benyttes til at læse et husnummer. For at læse et husnummer skal strukturen HouseNumberUniversalIdentifier udfyldes: Strukturen HouseNumberGetByIdOutputStructure returneres, indeholdende HouseNumberStructure med data fra det hentede husnummer, og en ReturnMessageStructure med status for kaldet. 3.3.4 Husnummer ret Benyttes til at opdatere et husnummer. For at opdatere et husnummer skal strukturen HouseNumberUpdateInputStructure udfyldes: Version 1.1 Side 16 af 22

Vær opmærksom på at alle felter i HouseNumberStructure som ikke angives ved ret af et husnummer, vil blive forsøgt nulstillet i DAR, hvis de ikke medsendes. Strukturen HouseNumberUpdateOutputStructure returneres, indeholdende HouseNumberStructure med data fra det opdaterede husnummer, og en ReturnMessageStructure med status for kaldet. 3.4 Adresse En adresse angiver en særskilt adgang til et areal, en bygning eller en del af en bygning, efter reglerne i adressebekendtgørelsen. Følgende figur viser strukturen for en adresse: Version 1.1 Side 17 af 22

Tabel 7 specifikke felter for adresse AddressUniversalIdentifier AddressStatusCode Specificerer en Unik ID for en adresse. Elementet beskriver status for adressen. Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Ved oprettelser og opdateringer må status 1 og 3 benyttes. AddressNoteText ESDHreferenceIdentifier FileNumberIdentifier AddressSourceCode Bemærkningsfelt til adressen. ESDH reference er et link til sagen i ESDH (Elektronisk sags- og dokumenthåndtering). JournalNumber er et valgfrit felt, hvor kommunen kan indtaste det journalnummer, som ESDH har givet sagen. Kode til kilde for adressen Kodeværdier: 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l. 11 - Oplysning fra anden kilde Feltet er krævet ved oprettelser og opdateringer og alle kodeværdier kan vælges. ValidDateTime Angiver entitetens ikrafttrædelsesdato. Feltet kan indberettes, men hvis det ikke indberettes sættes datoen automatisk til den dato, hvor adressen ændrer status fra Foreløbig til Gældende. Ikrafttrædelsesdatoen må ikke fremdateres. HouseNumberUniversalIdentifier Fremmednøgle til husnummerets adgangspunkt Version 1.1 Side 18 af 22

Tabel 8 Genbrugte felter fra digitaliser.dk SuiteIdentifier Identifikation, der beskriver placeringen af en specifik indgangsdør på en etage eller en repos i den opgang der refereres til. Korrekte side/dørbetegnelse kan være følgende BLANK TV, MF, TH, 0001-9999, bogstaver, kombinationer af bogstaver (A-Z) og tal, samt tegnene skråstreg og bindestreg. FloorIdentifier Identifikation, der beskriver etagen eller reposen på hvilken en specifik indgangsdør, lejlighed, eller sidedør er placeret i den opgang der refereres til. Korrekt etagebetegnelse kan være følgende BLANK ST Stuen 01-99 KL Kælder 3.4.1 Adresse opret Benyttes til at oprette en adresse. For at oprette adressen skal strukturen AddressCreateInputStructure udfyldes. Denne struktur består af en AddressStructure, som udfyldes med alle relevante felter. AddressUniversalIdentifier udfyldes ikke ved opret, da DAR angiver adressens id. Strukturen AddressCreateOutputStructure returneres, indeholdende AddressStructure med data fra den oprettede adresse, og en ReturnMessageStructure med status for kaldet. Version 1.1 Side 19 af 22

3.4.2 Adresse slet Benyttes til at slette en adresse. Når den sidste adresse under et husnummer slettes, slettes også husnummeret. For at slette en adresse skal AddressUniversalIdentifier, som er adressens id, udfyldes: Strukturen AddressDeleteOutputStructure returneres, indeholdende en ReturnMessageStructure med status for kaldet. 3.4.3 Adresse hent Benyttes til at læse en adresse. For at læse en adresse skal strukturen AddressUniversalIdentifier udfyldes: Strukturen AddressGetByIdOutputStructure returneres, indeholdende AddressStructure med data fra den hentede adresse, og en ReturnMessageStructure med status for kaldet. 3.4.4 Adresse ret Benyttes til at opdatere en adresse. For at opdatere en adresse skal strukturen AddressUpdateInputStructure udfyldes: Version 1.1 Side 20 af 22

Vær opmærksom på at alle felter i AddressStructure som ikke angives ved ret af en adresse, vil blive forsøgt nulstillet i DAR, hvis de ikke medsendes. Strukturen AddressUpdateOutputStructure returneres, indeholdende AddressStructure med data fra den opdaterede adresse, og en ReturnMessageStructure med status for kaldet. Version 1.1 Side 21 af 22

4 Adgang og sikkerhed 4.1 Adgang Servicen kan tilgås på nedenstående "endpoints". Produktion Demo Kommer senere Kommer senere For at tilgå snitfladen skal rollen DARAjourfoer i BBR tildeles. 4.2 Sikkerhed Sikkerheden i webservicen er baseret på OWSA model T 1, hvor HTTPS benyttes til sikker transport mellem to sikkerhedsdomæner og OCES-certifikater anvendes til autentifikation af Service Aftager. For at benytte webservicen skal Service Aftager : Være autoriseret af BBR til at benytte servicen. BBR skal kende Subject serialnumber fra det OCES virksomheds- eller funktions-certifikat/signatur som serviceaftager ønsker at benytte ved kald af webservicen Benytte et gyldigt OCES virksomheds- eller funktionscertifikat/signatur til autorisationen Medsende ovennævnte certifikat/signatur ved alle webservicekald Have installeret OCES-rodcertifikat 1 OWSA model T er beskrevet på digitaliser.dk: http://digitaliser.dk/resource/4349 Version 1.1 Side 22 af 22