Page History
...
| attribute | Beskrivelse |
|---|---|
| encryptionKey.xxx | Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. **CHG: Kryptering er her baseret på OCES certifikater og dermed asymetrisk. STS'en skal kunne konfigureres med et nøglepar, hvoraf public key udleveres til anvenderen (som bruger det til kryptering) og STS beholder private key (og benytter det til at dekryptere). Hvad bliver encryptionKey.xxx sat til her??? UPDATE: Er blevet klogere efter dialog med Mads Haargaard: encryptionKey.xxx er private key, men det bør være en indgang med tilhørende public key også - det er jo den der skal udleveres til BST-udstederen |
| tokenProfile | Anvendt tokenprofil. OIOH3BST (lokal IdP udstedt), OIOH2BST (SEB udstedt) eller OIO3BST (NemLog-in3 STS udstedt). |
| validateHOK | Angivelse af om holder-of-key (HoK) validering af requests skal udføres (true, false) |
| certificate.xxx | Angiver SubjectSerialNumber (ssn) for et certifikat der har mulighed for at benytte servicen. Dette certifikat benyttes af anvender til at signere hele beskeden. Sættes issuer til "*" vil certifikatet være gyldigt for alle issuers. Der kan være flere certifikater pr. issuer, hvilket blot betyder at flere anvendere kan tilgå det. Disse skal blot have forskellige xxx navne. Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. Bemærk: Benyttes kun hvis whitelist-checks er slået til (property whitelistValidation) |
| signingKey.xxx | Nøgle til trusted certifikat til signering af BST tokenet **CHG: Uklar tekst: 'Nøglen' her er public key og der jo ikke 'til signering' af BST tokenet. **(en issuer kan have flere trusted certifikater med forskellige xxx navne). |
...