Page History

...

Modellen er mere generel end de nuværende sikkerhedsprotokoller og udfaldrummet for de aktuelle sikkerhedsbilletter giver anledning til. TODO Menes der at modellen er mere generel end de udfaldsrum de nuværende sikkerhedsprotokoller- og billetter giver anledning til, og er derfor godt rystet på til at håndtere fremtidige protokoller?

F.eks. finder findes der i praksis i dag ikke en billet, hvor en sundhedsperson kan arbejde på vegne af en anden sundhedsperson (dvs. både ActingUser og PrincipalUser er tilstede). Dette kan udtrykkes i Security API'ets model og det er meget tænkeligt, at der kommer support for dette i fremtiden (når XUA kommer på banen).

...

Dette betyder dog, at det kan være ligeså vigtigt, at en komponent validerer både attributter der findes, og dem der ikke findes, for at mappe korrekt til de relevante aktører.

I F.eks kan eksemplet fra før, hvor en sundhedsfaglig, der handler på vegne af en anden sundhedsfaglig: Dette kan , udtrykkes i Security API, men der findes ikke (i dag) en sikkerhedsbillet, der kan bærer bære denne information.

Komponenten bør dog forholde sig til, hvad der er muligt i Security API'et ets model, og ikke kun på, hvad der er muligt i de aktuelle sikkerhedsbilletter. Hvis en komponent ikke ekplicit tillader "på-vegne-af" bør den tjekke, at sikkerhedsbilletten ikke er af en sådan type.

...

Det skal dog være tydeligt i dokumentationen og mapningen for den enkelte komponent, hvilke oplysninger, der stammer hvorfra (hvilke, der er en del af de STS-validerede oplysninger og hvilke der er kontekst-oplysninger, der essentielt bare er en udvidelse af det af komponenten udbudte API, med en ekstra kontekst).