(-- JanRiis 21-01-2006)

I SAML kapitlet blev komminikationen i forbindelse med rekvirering og returnering af ID-kort gennemgået. I dette kapitel kommer vi lidt nærmere XML formatet i servicekald. Den overordnede struktur af XML'en defineres og der gives eksempler på konkrete XML beskeder. På nær i AuthenticationRequest situationen (dvs. udstedelse af ID-kort) forholder vi os i SOSI kun til, hvad der skal være rundt om det egentlige servicekald, dvs. det der skal være i SOAP headeren. Indholdet af SOAP body'en er op til serviceudbyderen, og vil fremover blive reguleret af "Den Gode Webservice" som MedCom er ved at lægge sidste hånd på.

I dette kapitel vil der både blive vist figurer, der skitserer strukturen af XML beskeden og sektioner med indlejret XML. I flere afsnit redegør vi kun for strukturen uden at vise XML eksempler. Det vil dog altid være muligt at sammensætte et XML dokument ud fra de andre viste eksempler. Derfor er stort set alle XML eksempler på autenticitetsniveau 3 og 4, hvor serviceudbyderen har udbedt sig uafviselighedsdata. Autenticitetsniveau 1 og 2 behandles kort lidt senere i dette kapitel - hvor der typisk er reduceret lidt i indholdet af beskederne.

6.1 XML struktur

Helt overordnet er XML strukturen denne for forespørgsler på niveau 3+4 med bruger-uafviselighedsforsikring:

Nedenfor "zoomer" vi ind på hver del af requestet og gennemgår indholdet i detalje, men den "yderste" konstruktion i SOSI XML er SOAP 1.2 konvolutten:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope ...>
   <soap:Header> ... </soap:Header>
   <soap:Body>   ... </soap:Body>
</soap:Envelope>

De første tre "prikker" dækker over referencer til de anvendte namespaces og skemaer og er her udeladt af simplicitetshensyn. I SOAP headeren finder man de mere teknisk relaterede aspekter af meddelelsen (sikkerhedsdata, afsender- og modtagerdata etc.), mens man i SOAP body'en finder selve meddelelsen. Dette afsnit behandler som tidligere nævnt kun Headeren.

SOAP headeren består af et wsse:Security element, der indeholder 4 vigtige underelementer:

1. Gyldighedsperiode for meddelelsen (01-05 nedenfor)
2. SOSI ID-kortet (som en SAML assertion) (06-09 nedenfor)
3. Konvolutdata (som endnu en SAML assertion) (10-15 nedenfor)
4. En digital signatur af meddelelsen i SOAP body'en og konvolutdata (16-19 nedenfor)

   <soap:Header>
      <wsse:Security soap:mustUnderstand="1">
(01)      <!-- SOAP beskedens gyldighed (5 minutter) -->
(02)      <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
(03)         <wsu:Created>2006-01-04T08:03:46.918Z</wsu:Created>
(04)         <wsu:Expires>2006-01-04T08:08:46.918Z</wsu:Expires>
(05)      </wsu:Timestamp>

(06)      <!-- SOSI ID-kort -->
(07)      <saml:Assertion AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" ...>
(08)         ...
(09)      </saml:Assertion>

(10)      <!-- "Konvolut" data -->
(11)      <saml:Assertion AssertionID="_27akjj-75adf55-01d7-40cc-a78ekdi4bage" ...>
(12)         <saml:AttributeStatement id="EnvelopeToBeSigned">
(13)            ...
(14)         </saml:AttributeStatement>
(15)      </saml:Assertion>

(16)      <!-- Digital signatur af meddelelse og konvolut -->         
(17)      <ds:Signature>
(18)         ...
(19)      </ds:Signature>
      </wsse:Security>
   </soap:Header>

6.2 Meddelelsens gyldighed

Ovenstående eksempel er fyldestgørende og indeholder dermed de eksempeldata på det, som dette underelement i headeren bør indeholde. Meddelelsens gyldighed påstemples af serviceaftageren, når beskeden dannes (enten af klient eller server i serviceaftagersystemet) og sættes til 5 minutter. Tidsangivelserne skal være i Z-tid (GMT/UTC). Hvis en meddelelse modtages af en serviceudbyder efter udløbstid, skal den afvises. Dette stiller et implicit krav om, at alle aktører i føderationen skal være nogenlunde tidsmæssigt synkroniserede. Modtages en besked med en "created" tid, der er efter "nu", betragtes beskeden som værende gyldig. Det er således kun udløbstiden, der kan diskvalificere en besked.

6.3 SOSI ID kortet

SOSI ID-kortet er opbygget som en En saml.Assertion, med:

1. Kortets gyldighed som en saml:Condition
2. Brugeridentifikation og autenticitetsdata som en saml.Subject
3. Andre attributter som en samling af saml.Attribute elementer
4. IdP'ens digitale signatur som et ds:Signature element

      <saml:Assertion
         AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
         IssueInstant="2006-01-05T07:53:00Z"
         Issuer ="www.sundhed.dk"
         MajorVersion="1"
         MinorVersion="1"
         id="SOSIIDCard"
      >
         <!-- ID-kortets gyldighedsperiode -->
(01)     <saml:Conditions
(02)        NotBefore="2006-01-05T07:53:00.000Z"
(03)        NotOnOrAfter="2006-01-06T07:53:00.000Z"
(04)        id="IDCardValidityToBeSignedByIdP"
(05)     />

         <!-- Brugeridentifikation og autenticitetsdata -->
(06)     <saml:AttributeStatement id="IDCardAttributesToBeSignedByIdP">
(07)        <saml:Subject>
(08)           <saml:NameID Format="oces-emp-subject">
(09)              SERIALNUMBER=CVR:12345678-RID:234284, CN=Jan Riis, O=Ribeamt // CVR:12345678, C=DK
(10)           </saml:NameID>
(11)           <saml:SubjectConfirmation>
(12)              <saml:ConfirmationMethod>
(13)                 urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
(14)              </saml:ConfirmationMethod>
(15)              <saml:SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
(16)                 <ds:KeyInfo>
(17)                    <ds:KeyName>CVR:...-UID:...</ds:KeyName>
(18)                 </ds:KeyInfo>
(19)              </saml:SubjectConfirmationData>
(20)           </saml:SubjectConfirmation>
(21)        </saml:Subject>
                  
(22)        <!-- Her følger alle attributterne på "ID-kortet" -->
(23)        <saml:Attribute AttributeName="CPR-nr">
(24)           <saml:AttributeValue>[Brugerens CPR nr.]</saml:AttributeValue>
(25)        </saml:Attribute>
(26)        <saml:Attribute AttributeName="medcom:UserEMailAdress">
(27)           <saml:AttributeValue>jri@lakesiteSTOPSPAM.dk</saml:AttributeValue>
(28)        </saml:Attribute>
(29)        <saml:Attribute>
(30)           <saml:AttrbuteValue>
(31)              <ds:RSAKeyValue>
(32)                 <ds:Modulus>
(33)                    xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
(34)                    jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
(35)                    5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
(36)                 </ds:Modulus>
(37)                 <ds:Exponent>AQAB</ds:Exponent>
(38)              </ds:RSAKeyValue>
(39)           </saml:AttrbuteValue>
(40)        </saml:Attribute>
(41)        <!-- ... osv. -->
(42)     </saml:AttributeStatement>

         <!-- IdP'ens digitale signatur af ID-kortet -->
(43)     <ds:Signature>
(44)        <ds:SignedInfo>
(45)           <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
(46)           <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(47)           <ds:Reference URI="#IDCardAttributesToBeSignedByIdP">
(48)              <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(49)              <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
(50)           </ds:Reference>
(51)           <ds:Reference URI="#IDCardValidityToBeSignedByIdP">
(52)              <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(53)              <ds:DigestValue>EffhQRnIuZYtcQvUp8WhN8DeXtb=</ds:DigestValue>
(54)           </ds:Reference>
(55)        </ds:SignedInfo>
(56)        <ds:SignatureValue>
(57)           zjnZjBi8kI1QVBG8jFkDkvPBEgJXBLaVkHf6oK5iVDUaBY+CxbXfPWoqB0JItwbcDnc8Aj6Od0I1QVBG8jFkDkvPBEgJXBLaVkHf6=
(58)        </ds:SignatureValue>
(59)        <ds:KeyInfo>
(60)           <ds:KeyName>CVR:....-UID:....</ds:KeyName>
(61)        </ds:KeyInfo>
(62)     </ds:Signature>
(63)   </saml:Assertion>

6.3.1 Gyldighedsperioden for ID-kortet

(Linie 01-05)

Som standard sættes gyldighedsperioden ind til næste forventede dopwnload af spærrelister fra TDC (8-24 timer). I modsætning til beskedens gyldighedsperiode, skal både start- og sluttid håndhæves for ID-kortets gyldighedsperiode. Dette indfører et implicit krav om, at alle aktører i integrationen er nogenlunde synkroniserede mht. tiden, og for at undgå, at et ID kort bliver afvist pga. manglende synkronisering på sekund-niveau, skal NotBefore sættes til "nu" minus 1 minut og sættes til 00.000 i sekunder/millisekunder. Eksempel: Modtager en IdP en forespørgsel om udstedelse af et nyt ID-kort kl. 08:54:46.023, skal NotBefore sættes til 08:53:00.000, med udløb lige efter næste opdatering af spærrelister fra TDC (dvs. i praksis ca. 8-24 timer senere).

Som i beskedens tidsangivelse skal der også til ID-kortets gyldighedsperiode benyttes UTC-tid. Bemærk at dette element har et id, som anvendes som reference ved etablering af IdP'ens digitale signatur. #IDCARD

6.3.2 Brugeridentifikation og autenticitetsdata

(Linie 06-62)

I linie 08-10 finder man brugerens identitet (principal) som et saml.NameID. Brugeren identificeres med et RFC2253 ID, hvor indholdet er de obligatoriske elementer for et subject ID i et OCES medarbejdercertifikat, dvs.

• Landekode (c)
• Organisation (o)
• Navn (common name, cn)
• Subject serial number (SERIALNUMBER=CVR+RID)

Se den præcise definition af oces-emp-subject i TDCs "Teknisk om OCES").

Subject ID'et kan i Java trækkes direkte ud fra OCES medarbejdercertifikatet med certificate.getSubjectDN().getName() og det anvendes i SOSI uden yderligere parsning og transformation. ID'et skal bruges som en nøgle til subjektet, og udpeger præcist, hvilket certifikat ID-kortet er blevet udfærdiget på baggrund af. Informationerne i ID'et tænkes ikke anvendt til noget i SOSI sammenhæng, idet det kræver en (ikke-triviel) parsning af ID'et. I SOSI skal alle nødvendige brugeroplysninger derfor fremgå af attributterne (linie 22 og frem i eksemplet).

I linie 11-21 finder man informationer om, hvorledes subjektet kan verificeres. I SOSI benytter vi digitale certifikater, hvor ægtheden verificeres ved at verificere den digitale signatur fra IdP'en, som står inde for brugerens autenticitet. Verifikationsmetoden er derfor urn:oasis:names:tc:SAML:1.0:cm:holder-of-key og verifikationsdata er en reference til IdP'ens OCES Virksomhedscertifikat (CVR+UID), som forventes at være installeret på alle servere i integrationen.

I linie 22-42 finder man alle attributterne, der er relateret til dette personlige ID-kort. Følgende informationer skal som minimum indgå som attributter på ID-kortet (og opfylder dermed også OIOs retningslinier for kerneattributter for brugere):

Fælles attributter:

• sosi:IDCardID - et unikt ID for dette ID-kort (format skal fastlægges. Skal kunne bruges på alle autentifikationsniveauer)
• sosi:IDCardVersion - version af ID-kort (1.0)
• sosi:IDCardType - ID-kort type (user,system)
• sosi:AuthenticationLevel - Autenticitetsniveau (1-4)
• sosi:PublicRSAKey - ds:keyinfo element indeholdende den offentlige RSA nøgle

sosi:IDCardVersion skal indeholde major.minor. Ændres major er kortet ikke bagudcompatibelt. Ændres minor er kortet bagudcompatibelt, men evt. med tilføjelser eller udvidede værdimængder.

sosi:AuthenticationLevel kan enten udelades, eller ignoreres, hvis der er tale om et system ID-kort.

Bemærk: sosi:PublicRSAKey er kun i ID-kortet såfremt kortet er udstedt på baggrund af et digitalt certifikat, dvs. hvor sosi:AuthenticationLevel er 3 eller 4, eller hvis det er et system ID-kort. System ID-kort skal altid indeholde et sosi:PublicRSAKey.

Personlige ID-kort indeholder desuden:

• medcom:UserCivilRegistrationNumber - CPR-nr
• medcom:UserOccupation - Ansættelse
• medcom:UserGivenName - Fornavn
• medcom:UserSurName - Efternavn
• medcom:UserEMailAdress - Email adresse
• medcom:UserRole - Brugerrolle jf. kommende klassifikation fra sundhed.dk's brugerkatalogprojekt
• medcom:UserITSystem - Afsendersystem ID
• medcom:UserOrganisationName - Organisationsnavn
• medcom:UserOrganisationCVR - Organisations CVR nr.

mens System ID-kort indeholder:

• medcom:UserITSystem - Afsendersystem ID
• medcom:UserOrganisationName - Organisationsnavn
• medcom:UserOrganisationCVR - Organisations CVR nr.

Bemærk: Betydning, namespace og valuespace for de MedCom relaterede attributter forventes fastlagt af MedCom i "Den gode webservice".

Bemærk - angivelse af en brugerrolle (medcom:UserRole) kræver en klar definition af roller i domænet (her sundhedssektoren). Rollerne skal være tilstrækkeligt dækkende til, at en vilkårlig serviceudbyder i føderationen på baggrund af en rolleklassifikation kan afgøre om brugeren skal have adgang til en service. I SOSI skal rollerne have de værdier, som fastsættes i brugerkatalogprojektet i Sundhed.dk.

Check: CPR og CVR nummer (og evt. andre attributter) bør ende ud med at være OIOXML compliant!

6.3.3 IdP'ens digitale signatur

I linie 43-62 finder man IdP'ens digitale signatur af ID-kortet. Dette er udformet jf. XML Signature standarden, hvor der dannes digest over de refererede dele af ID-kortet, som så signeres vha. IdP'ens private RSA nøgle. I linierne 47 og 51 kan man se referencer til de afsnit i ID-kortet, der føres under digital signatur.

IdP'ens public key er ikke indlejret af sikkerhedshensyn (i givet fald skulle det have været et certifikat, hvilket fylder unødigt meget). I stedet refereres der igen til IdP'ens OCES virksomhedscertifikat, der forventes at være installeret.

6.3.4 Uafviselighed revisiteret

Hvis serviceudbyderen kræver serviceaftagersystem-uafviselighed (i modsætning til brugeruafviselighed, som i eksemplet ovenfor), vil der være to ID-kort i headeren, en for brugeren og en for systemet.

Den digitale signatur af besked og kuvertdata vil være dannet på baggrund af serviceaftagersystemets private nøgle, og system ID-kortet vil indeholde den offentlige nøgle til verifikation af dette.

Request for comment:
Her går vi ud fra at man enten ønsker systemuafvislighed eller brugeruafviselighed. Kunne man forestille sig, at man kunne ønske sig begge dele?

6.4 MedCom konvolutdata

Hvor ID-kortet indeholder data af relativ statisk karakter, indeholder MedCom konvolutten mere "dynamiske" data, primært data om modtageren og data der vedrører skiftende patienter.

<saml:Assertion
   AssertionID="_27akjj-75adf55-01d7-40cc-a78ekdi4bage"
   IssueInstant="2006-01-05T08:03:00Z"
   Issuer ="www.ribeamt.dk"
   MajorVersion="1"
   MinorVersion="1"
>
(01)   <saml:AttributeStatement id="EnvelopeToBeSigned">
(02)      <!-- Her følger alle attributterne på "konvolutten" -->

(03)      <saml:Attribute AttributeName="sosi:RequireNonRepudiationReceipt"> ... </saml:Attribute>

(04)      <saml:Attribute AttributeName="medcom:SecurityType"> ... </saml:Attribute>
(05)      <saml:Attribute AttributeName="medcom:PatientConsentCode"> ... </saml:Attribute>
(06)      <saml:Attribute AttributeName="medcom:PatientConsentRemark"> ... </saml:Attribute>
(07)      <saml:Attribute AttributeName="medcom:SenderEANIdentifier"> ... </saml:Attribute>
(08)      <saml:Attribute AttributeName="medcom:SenderDepartmentIdentifier"> ... </saml:Attribute>
(09)      <saml:Attribute AttributeName="medcom:SenderPersonIdentifier"> ... </saml:Attribute>
(10)      <saml:Attribute AttributeName="medcom:ReceiverEANIdentifier"> ... </saml:Attribute>
(11)      <saml:Attribute AttributeName="medcom:ReceiverDepartmentIdentifier"> ... </saml:Attribute>
(12)      <saml:Attribute AttributeName="medcom:ReceiverPersonIdentifier"> ... </saml:Attribute>
(13)   </saml:AttributeStatement>
</saml:Assertion>

Bemærk: Betydning, namespace og mulige værdier for MedCom relaterede attributter forventes fastlagt af MedCom i "Den gode webservice".

I linie 03 er der en enkelt SOSI attribut, sosi:RequireNonRepudiationReceipt, som bruges til at kræve digital signatur af svaret fra serviceudbyderen. Værdierne kan her være yes/no. Såfremt en serviceudbyder ikke kan levere en uafviselighedskvitering, må transaktionen ikke gennemføres, og der returneres en fejlbesked.

6.5 Beskedens digitale signatur

Den sidste del af SOAP headeren er den digitale signatur af de vigtigste dele af headeren og selve meddelelsen. Igen er det helt standard XML Signature, hvor der refereres til dele af SOAP Headeren og indholdet af SOAP Body'en.

(01)      <!-- Digital signatur af meddelelse og konvolut -->         
(02)      <ds:Signature>
(03)         <ds:SignedInfo>
(04)            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
(05)            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(06)            <ds:Reference URI="#EnvelopeToBeSigned">
(07)               <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(08)               <ds:DigestValue>VBG8jFkDkvPBEgJXBLaVkHf6oK5i=</ds:DigestValue>
(09)            </ds:Reference>
(10)            <ds:Reference URI="#MessageToBeSigned">
(11)               <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(12)               <ds:DigestValue>vUp8WhN8DeXtbEffhQRnIuZYtcQ=</ds:DigestValue>
(13)            </ds:Reference>
(14)         </ds:SignedInfo>
(15)         <ds:SignatureValue>
(16)            NFAnBZLz/jOaG4RVdBKBKpB5q27OqBhi9NW9n4b5mHhBpoJXKDt8sVF3nT3aRlWklYCyzNO6fiUYqWEJcNFJmFHs
(17)            /9lsORK10zjnZjBi8kI1QVBG8jFkDkvPBEgJXBLaVkHf6oK5iVDUaBY+CxbXfPWo qB0JItwbcDnc8Aj6Od0=
(18)         </ds:SignatureValue>
(19)         <ds:KeyInfo>
(20)            <!-- jf. "SAML Token Profile 3.3.2 SAML Assertion Referenced from KeyInfo" -->
(21)            <wsse:SecurityTokenReference>
(22)               <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">
(23)                   _a75adf55-01d7-40cc-929f-dbd8372ebdfc
(24)               </wsse:KeyIdentifier>
(25)            </wsse:SecurityTokenReference>
(26)         </ds:KeyInfo>
(27)      </ds:Signature>
      </wsse:Security>
</soap:Header>

6.6 Svarbeskeder

Svarbeskeder indeholder stort set de samme data som i forespørgsler, dog er det i sagens natur aldrig personlige ID-kort i SOAP headeren. Overordnet set ser det således ud:

Der indlejres kun en digital signatur såfremt serviceaftageren krævede det i requestet (jf. sosi:RequireNonRepudiationReceipt attributten i kuvertdata).

6.7 Niveau 1 og 2 services

I dette afsnit behandler vi de situationer, hvor serviceudbyderen udstiller services, der ikke kræver autenticitetsniveau 3 eller 4, men hvor servicen kun kræver brugernavn/password beskyttelse (niveau 2) eller hvor brugeren blot skal være kendt (niveau 1). I disse tilfælde kan vi løsne op for kravet om intensiv brug af certifikater ... men desværre ikke uden konsekvenser.

Selv om der er tale om et lavere troværdighedsniveau, holder vi fast i ID-kort mekanismen. Dermed er det de samme komponenter, en given serviceudbyder skal forholde sig til og benytte sig af, hvad enten man opererer på det ene eller det andet niveau. Der skal altså stadig udstedes et ID-kort, som IdP'en beriger med data og underskriver. Der er dog forskel på, hvem der reelt autenticerer brugeren, og hvor godt en serviceudbyder kan stole på brugerens identitet. Envidere er det værd at bemærke, at strukturen af svarbeskeder fra serviceudbydere er helt uafhængige af niveauet af autenticitetssikring.

På niveau 3+4 afgøres brugerens identitet og autenticitet ved at kontrollere den på "Udsted ID-kort" forespørgslen påførte digitale signatur. Denne mulighed har vi ikke på dette niveau, og IdP'en har derfor ikke andre muligheder, end at stole på, at en anden instans kan eller har autentificeret brugeren. I SAML er der defineret to ConfirmationMethods:

1. urn:oasis:names:tc:SAML:1.0:cm:holder-of-key - f.eks. ved verifikation af en digital signatur. IdP står inde for brugerens autenticitet.
2. urn:oasis:names:tc:SAML:1.0:cm:sender-vouches - afsendersystemet forventes at autenticere brugeren. Afsendersystemet står inde for brugerens autenticitet.

I første omgang understøtter SOSI kun disse to autenticeringsmekanismer, men som tidligere nævnt, vil IdP'en på sigt kunne uddelegere autenticeringsansvaret til en ekstern part, f.eks. hvis der i fremtiden etableres et centralt brugerkatalog i sundhedssektoren eller på landsplan. Dette behandles i en kommende version af SOSI.

Ved anvendelse af sender-vouches opretholdes hemmeligholdelse og meddelelsesintegritet stadig pga. kravet om SSL3.0/TLS1.0 på alle linier, ligesom replay-attacks etc. er forhindret. Til gengæld mistes muligheden for bruger-uafviselighed, dvs. det er ikke længere muligt for en serviceudbyder at bevise at en given bruger har gennemført en given transaktion på et givet tidspunkt.

Request for Comment:
I praksis vil auditlogs hos både serviceaftager og serviceudbyder dog være ganske tyngende beviser. Er der nogen der har viden om, hvad der er nødvendig i juridisk forstand, for at opretholde uafviselighed?

Systemuafviselighed kan stadig (optionelt) kræves som beskrevet tidligere, dvs. selv om sikkerheden for brugerens autenticitet er knapt så høj, kan serviceaftager eller serviceudbyder stadig udbede sig data, der sikrer uafviselighed af hhv. svaret og/eller forespørgslen.

Request for comment:

• Hvor lang skal gyldigheden for ID kort på niveau 1+2 være?
• Skal det være op til serviceudbyderen at kræve, at et ID-kort ikke er "for gammelt", f.eks. at et ID-kort er blevet udstedt senest for 30 minutter siden? Dette kunne give serviceudbyder en indikation af, at det reelt er den rigtige bruger, der sidder ved tastaturet. Dette kunne vel også være relevant på niveau 3+4?

Overordnet set ser XML forespørgsler således ud på niveau 1+2:

Hvis serviceudbyder kræver systemuafviselighed, ser XML forespørgslen således ud:

6.8 Services der kun kræver systemautentifikation

SOSI designet omfatter også de tilfælde, hvor en serviceudbyder kun kræver systemadgang til en service, dvs. der kræves udelukkende autorisation af afsendersystemet og ikke en bruger i dette system. Dette tilfælde er et specialtilfælde af niveau 3, hvor der udelukkende fremsendes ID-kort for afsendersystemet. XML strukturen ser i disse situationer således ud:

Serviceudbyder kan naturligvis stadig kræve uafviselighedsdata, og i dette tilfælde vil beskeden være signeret med serviceaftagersystemets private nøgle.

Request for comment:
Det er lidt svært at indplacere denne situation i 4-trinsmodellen, men da vi i SOSI altid kræver et system-ID-kort på niveau 1+2, og da der øjensynligt ikke findes "kvalificerede virksomhedscertifikater", må det blive niveau 3 ... eller hvad?

6.9 Algoritmevalg i SOSI

I SOSI benyttes flg. algoritmer til dannelse af digital signatur, hvilket er i overensstemmelse med IT-sikkerhedsrådets vejledning om det offentliges brug af digitale signaturer og kryptering:

• Kanoniseringsalgoritme: Canonical XML (REC-xml-c14n-20010315)
• Hashing (digest): SHA-1
• PKCS: RSA

I eksemplerne ovenfor kan du se, hvorledes man udpeger algoritmerne vha. XML-Signature standarden.

6.10 XML eksempler

Følg dette link for et komplet eksempel på en SOSI SOAP Header på autenticitetsniveau 3 med brugeruafviselighedsdata.