Page History

...

Ovenstående er et eksempel på strukturen i en DGWS service. En hel del af det, der kan findes her på NSPOP, handler om, hvordan Headeroplysningerne Header oplysningerne og adgangsbilletter er opbygget. Der er lidt forskel på, hvordan et DGWS og et IDWS kald ser ud, men den overordnede struktur er nogenlunde ens.

...

Når den, der har fået fuldmagt (fuldmagtshaveren), logger ind på f.eks. Sundhedsjournalen/Sundhed.dk, så vælger fuldmagtshaveren, hvem vedkommende gerne vil se eller ændre data for (fuldmagtsgiveren). 'Beviset' for at fuldmagtshaver har en fuldmagt til at kunne tilgå en bestemt service, indbygges i adgangsbilletten. Det sker i omvekslingen (step 2 ovenfor), hvor Sundhedsjournalen/Sundhed.dk vedlægger et såkald såkaldt "claim" om, at brugeren har fuldmagt. Det efterprøver STS-servicen, og hvis det er korrekt, så indlejres beviset i adgangsbilletten (identity token).

OIO Identity Token Profile er udformet så smart, at der kan indlejres alle mulige mange forskellige beviser, der kan overholde alle mulige flere forskellige profiler.

Lige netop for den slags særligt basale privilegier, som en fuldmagt jo er, har Digitaliseringsstyrelsen udarbejdet en rammeprofil, der hedder OIO Basic Privilege Profile. Den regulerer hvordan sådan nogle basale privilegier skal udformes i headeren for IDWS kald. Når OIOBPP ikke længere slår til, kan man lokalt i domænet udvikle andre profiler, hvor der kan opnås bedre standardisering og udtrykskraft. Det benyttede vi os af i 2023-2024, hvor de to nederste profiler (Blurring Instructions Profile og Subject Relations Profile) blev udarbejdet og taget i brug (se evt. mere i ID Sløring projektområdet).

...