Designet af SOSI er inspireret af fysiske ID-kort, der f.eks. anvendes af medarbejdere i en virksomhed til identifikation: når kortet bæres kan alle se hvem personen er og at denne har ret til at opholde sig i firmaet. ID-kort analogien bruges dels som bevis på at den pågældende part er "logget ind" i føderationen og dels til at autorisere adgangen til tjenester vha. de ekstra oplysninger kortet fik påtrykt under udstedelsesprocessen.

I en SOSI føderation indgår der som minimum følgende parter:

• Serviceudbyder. Et system, der udstiller en web service (tjeneste). Tjenesten kan benyttes af en Serviceaftager for så vidt denne medsender bevis for identitet og kan blive passende autoriseret. Der er typisk mange serviceudbydere i en føderation.
• Serviceaftager. Et system, der benytter en web service med henblik på at få udført et stykke arbejde, f.eks. at hente data eller opdatere et datalager. Der er typisk mange serviceaftagere i en føderation.
• Identity Provider (IdP). Et system, der kan verificere autenticiteten af en brugers akkreditiver, og dermed vedkommendes identitet. Der er typisk kun én eller meget få IdP'er i en føderation.
• Certificate Authority (CA). Et system, der kan udstede certifikater, udlevere oplysninger om personen bag og udlevere certifikater efter ønske. Der er typisk kun én eller meget få CA'er i en føderation.
• Autorisationsservice. Et system, der kan udlevere oplysninger om en bruger, f.eks. dennes organisatoriske tilhørsforhold, offentlige autorisationskode, etc. Bruges til at hente oplysninger der skal påtrykkes et ID-kort. Der kan være flere autorisationsservices i en føderation, men der vil ofte kun være få.

Nu da vi har de centrale aktører på plads, kan vi se lidt på, hvordan udstedelse af ID-kort foregår. I dette tilfælde udstedes der et ID-kort på baggrund af et OCES medarbejdercertifikat:

1. Før en serviceaftager kan begynde at anvende SOSI føderationens tjenester, skal serviceaftageren forbi "portvagten" og have udstedt et ID-kort. Det sker ved at serviceaftager laver en digital signatur med sin private nøgle og sender signaturen til Identity Provideren (IdP).
2. Hvis IdP'en ikke kender det certifikat der skal bruges for at validere signaturen, hentes certifikatet først fra Certifikat Autoriteten (CA). Samtidig kan brugerens CPR-nummer hentes fra CA ved at bruge certifikatets ID som nøgle.
3. Når brugeren og dennes CPR-nummer er kendt, kan yderligere oplysninger som f.eks. autorisationskode fra Sundhedsstyrelsen, organisatorisk tilhørsforhold etc. hentes eller verificeres hos en eller flere Autorisationsservices.
4. De rekvirerede/verificerede oplysninger påtrykkes et digitalt ID-kort, som underskrives af IdP'en og returneres til serviceaftageren.
5. Serviceaftageren er nu klar til at benytte tjenester i SOSI føderationen. Dette gøres ved at serviceaftageren danner en web service forespørgsel og putter den i en "konvolut" sammen med ID-kortet. Alt sammen sendes til serviceudbyderen. Kuverten kan, hvis serviceudbyderen kræver det, krydres med en digital signatur af indholdet.
6. ID-kortet er lavet, så ægthed og gyldighed kan verificeres decentralt, dvs. hos den enkelte serviceudbyder uden at spørge andre parter i føderationen. Serviceudbyderen verificerer nu kortet og autoriserer brugeren til den ønskede funktionalitet på baggrund af kortets oplysninger.
7. Når funktionaliteten er udført, pakkes svaret i en web service svarkonvolut, som returneres til serviceaftageren.

Formelt set er ID-kort mekanismen en overdragelse af tillid, hvor IdP'en overtager ansvaret for og står inde for en brugeres autenticitet. Da tillidsforholdet mellem serviceudbydere og IdP'en er stort, kan alle serviceudbydere i SOSI føderationen, efterfølgende kontrollere den oprindelige tillidsoverdragelse, og dermed brugerens autenticitet, ved at sikre sig at et ID-kort er udstedt af den pågældende IdP. Konkret betyder det, at serviceudbydere udelukkende behøver at kende ét offentligt certifikat, nemlig IdP'ens.

Tillidsoverdragelse vha. ID-kort eller "tickets" har dog en bagside, nemlig at jo længere tid der er gået, siden et ID-kort blev udstedt, desto større er risikoen for, at ID-kortet ikke bliver anvendt af den bruger, som ID-kortet tilhører. Nogle gang glemmer en bruger at logge sig af det lokale system, og dermed kan en anden bruger (mange gange uden at tænke over det) sætte sig til tastaturet og fortsætte med at benytte applikationen i den forrige brugers navn. Et ID-korts "alder" er således en vigtig parameter i sikkerhedsløsningen, og i SOSI forholder vi os til "alderen" ved at lade det være muligt for serviceudbydere at afvise forespørgsler/indberetninger, hvor ID-kortet er for gammelt. Er kravet 8 timer, er der noget større risiko for autenticitetsfejl end hvis kravet er 30 minutter. Er kravet 10 sekunder er det næsten helt sikkert den rigtige bruger, der anvender ID-kortet, men i praksis betyder det også, at brugeren skal afgive sine akkreditiver (f.eks. password) hele tiden.

Et andet aspekt er juridisk uafviselighed. Hvis en serviceudbyder ønsker bevis for, at en bruger har foretaget en given forespørgsel på et givet tidspunkt, kan serviceudbyderen kræve en digital signatur af forespørgslen/indberetningen. I langt de fleste tilfælde vil det dog være tilstrækkeligt med indicier i auditlogs til at godtgøre, at en bruger har foretaget en given forespørgsel. Serviceudbydere kan dog i specialtilfælde kræve en digital signatur.