Loading…
Tilbage

Kommentarer til MeMo Betaversion 2


13-06-2019 09:13:09

Følgende høringssvar blev modtaget i forbindelse med offentliggørelsen af MeMo Betaversion 2.

Kommentarer fra DIGST fremgår under hvert punkt i kursiv.

1. Når man ønsker, at MeMo er en fremtidssikret datastandard, bør man så ikke kunne sende krypterede data, bortset for MessageHeader som bruges til rutning (og afregning/statistik).

Dette skal sikre driftspersonalet ikke kan læse indholdet af de enkelte stykker digital post.

Det er en god pointe som har været diskuteret flere gange. Kryptering anvendes på transportlaget, hvilket vurderes at være tilstrækkeligt til at videresende persondata, og er derfor ikke et forretningsmæssigt krav. Det er som udgangspunkt modtageren som har ansvaret for at deres driftsmiljø og processer er tilstrækkeligt sikre.
En routning til det korrekte fagsystem hos modtageren vil som regel kræve at MessageHeader indeholder væsentlige persondata såsom personnummer, modtagepunkt og f.eks. KLE, så selve headeren vil alligevel kunne indeholde personfølsom data.

2. I den strukturerede adresse kan man angive Country men ikke State.

Dette giver ikke mening, hvis man vil sende til USA.

Den strukturerede adresse er defineret med udgangspunkt i danske postadresser og derfor er det ikke indeholdt, hvor udenlandske adresser kan angives i den ustrukturerede adresse. Vi vil medtage det som input.

3. Den strukturerede adresse giver ikke mulighed for C/O.

Det er hensigtsmæssigt at kunne angive en C/O adresse, da ikke alle lejere står på postkassen.

Det er en godt input og medtages i det videre arbejde.

4. Den strukturerede adresse og den ustrukturerede adresse hedder begge Address.

Dette gør det ikke nemmere at forstå.

Dette kunne godt klarificeres og medtages i det videre arbejde.

5. MotorVehicle har licenseNumber, men ikke en landeangivelse, LicenseNumber er ikke globalt unikt.

Klassen tager udgangspunkt i det danske motorregister og derfor er landeangivelse ikke indeholdt. Det kunne være en mulighed at udarbejde en international version af motorregisteret.

6. Der bør angives autoritative kilder til indholdet af felter som PropertyNumber, educationCode.

Det er en godt input og medtages i det videre arbejde. Uddannelseskode og ejendomsnummer er taget fra de respektive registre, men det bør fremgå.

7. replyData1-4, hvorfor 4 og ikke 3 eller 5. Måske kunne en liste med værdipar være en mere fremtidsikret løsning.

Det har været et mål at svar på data primært er struktureret data, og derfor er anvendelse af ustruktureret data begrænset, da det kan medføre at der sendes redundant eller systemspecifikke data tilsvarende de felter som findes i de strukturerede dele. Det kan genovervejes om ustruktureret data skal være mere frit.

8. Man bør kunne angive en checksum for filer, så man kan sikrer at de ikke er blevet forvansket.

Det er tænkt at f.eks. pdf kan signeres således at integritet sikres i filformatet frem for en angivelse i dataforsendelsen.

9. I det fulde eksempel er den ustrukturerede adresse angivet uden linjeskift, hvilket gør at adressen ikke bruges til en adresselabel, med mindre at komma erstattes med linjeskift, hvilket dog giver problemer, da komma kan indgå i adressatens navn f.eks. ”Advokatfirma Kaspersen, Jespersen og Jonathansen”.

Det er en god pointe, og medtages i det videre arbejde.

10. Det bør beskrives hvorledes filer embeddes f.eks. base64 encoded.

Det er tænkt således at filer i xml er base64 encoded. Beskrivelse heraf vil blive præciseret.

11. Der bør være eksempler med filer embedded.

Det er en god pointe, og medtages i det videre arbejde.

12. Der bør være eksempler med en korrekt formateret HTML-fil, inkl. grafik og tabeller. Der er compliant med WAI-ARIA, WCAG og den Uddybende vejledning til brug af HTML.

Det er en god pointe, og medtages i det videre arbejde.