Målet med security API er at gøre det let for services at tjekke sikkerhed - både DGWS, IDWS og eventuelle sikkerhedsprotokoller i fremtiden.
Dette skal gøres på en måde, så det der tilbydes de anvendende services/komponenter de nødvendige abstraktioner/termer og tilbyde en passende mapning fra de konkrete sikkerhedsprotokoller.
Termerne spiller også ind i måden, som SDS ønsker at modellere brugere/aktører i forhold til de user stories som beskriver opførsel og komponenter. Det er op til komponenterne selv at modellere de aktører, som de skal servicere, så security API opererer på et lavere niveau, hvor denne mapning giver mening.
Udtrykker kun den information, som findes i sikkerhedsbilletten - og ikke andet.
Stiller informationen til rådighed for komponenten gennnem SecurityContext hvorfra, der er adgang til alle information bl.a. ActingUser (den bruger, der trykker på knapperne), PrincipalUser (den bruger, der er ansvarlig for handlingen), Organisation, Message og Ticket.
Der anvendes Optionals rundt omkring.
Modellen er mere generel end de nuværende sikkerhedsprotokoller og udfaldrummet for de aktuelle sikkerhedsbilletter giver anledning til.
F.eks. finder der i praksis i dag ikke 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).
Som det blev beskrevet før, så er Security APIs model meget generel og kan udtrykke ting, som der i øjeblikket ikke kan forekomme i praksis.
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 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 denne information.
Komponenten bør dog forholde sig til, hvad der er muligt i Security API'et model, og ikke kun på, hvad der er muligt i de aktuelle sikkerhedsbilletter.
Eksempler på aktører:
Komponenten skal modellere disse aktører på en eller anden måde (f.eks nedarvning eller en simpel enumeration, der lister typerne).
Komponenten skal selv mappe fra security context til sin egen aktørmodel:
I mange komponenter er forretningslogikken og aktør-modelleringen afhængig af oplysninger, der ikke er en del af Security API. Eksempler kan være:
I aktørmodellen må komponenten gerne tage disse oplysninger med i aktørmodelleringen.
Det skal dog være tydligt, 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 ekstra kontekst).