From ec24b9558980c07c39a93a911480cf260c12e9c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Lindstr=C3=B6m?=
 <martin-lindstrom@users.noreply.github.com>
Date: Tue, 3 Dec 2024 18:10:16 +0100
Subject: [PATCH] December 2024 (#231)

* December 2024 release
---
 00 - Swedish eID Framework - Introduction.md  |    2 +-
 00 - Tekniskt ramverk - Introduktion.md       |    2 +-
 ...t Profile for the Swedish eID Framework.md |  116 +-
 03 - Registry for Identifiers.md              |  188 +-
 ...ification for the Swedish eID Framework.md |  418 ++---
 ...ategories for the Swedish eID Framework.md |   98 +-
 ...r using DSS in Central Signing Services.md |   34 +-
 ...xtension for Federated Signing Services.md |   26 +-
 ...D Profile for the Swedish eID Framework.md |   31 +-
 13 - Signature Activation Protocol.md         |   18 +-
 ...tension in SAML Authentication Requests.md |   20 +-
 Identity Binding.md                           |   11 +-
 ...Connect Claims and Scopes Specification.md |   17 +-
 OpenID Connect Profile for Sweden Connect.md  |   11 +-
 ..._Swedish_eID_Framework_-_Introduction.html |  569 ++++++
 .../00_-_Tekniskt_ramverk_-_Introduktion.html |  587 ++++++
 ...Profile_for_the_Swedish_eID_Framework.html | 1594 ++++++++++++++++
 .../03_-_Registry_for_Identifiers.html        | 1204 ++++++++++++
 ...ication_for_the_Swedish_eID_Framework.html | 1222 ++++++++++++
 ...egories_for_the_Swedish_eID_Framework.html |  689 +++++++
 ...using_DSS_in_Central_Signing_Services.html |  683 +++++++
 ..._Profile_for_Central_Signing_Services.html |  350 ++++
 ...ension_for_Federated_Signing_Services.html | 1668 +++++++++++++++++
 ...ication_for_the_Swedish_eID_Framework.html |  648 +++++++
 ...Profile_for_the_Swedish_eID_Framework.html |  487 +++++
 .../13_-_Signature_Activation_Protocol.html   |  489 +++++
 ...ction_in_SAML_Authentication_Requests.html |  234 +++
 ...nsion_in_SAML_Authentication_Requests.html |  220 +++
 ...nnect_Claims_and_Scopes_Specification.html |  381 ++++
 ...ID_Connect_Profile_for_Sweden_Connect.html |  247 +++
 docs/december-2024/index.html                 |  278 +--
 ..._Swedish_eID_Framework_-_Introduction.html |    2 +-
 .../00_-_Tekniskt_ramverk_-_Introduktion.html |    2 +-
 ...Profile_for_the_Swedish_eID_Framework.html |    2 +-
 .../latest/03_-_Registry_for_Identifiers.html |    2 +-
 ...ication_for_the_Swedish_eID_Framework.html |    2 +-
 ...egories_for_the_Swedish_eID_Framework.html |    2 +-
 ...using_DSS_in_Central_Signing_Services.html |    2 +-
 ..._Profile_for_Central_Signing_Services.html |    2 +-
 ...ension_for_Federated_Signing_Services.html |    2 +-
 ...ication_for_the_Swedish_eID_Framework.html |    2 +-
 ...Profile_for_the_Swedish_eID_Framework.html |    2 +-
 .../13_-_Signature_Activation_Protocol.html   |    2 +-
 ...ction_in_SAML_Authentication_Requests.html |    2 +-
 ...nsion_in_SAML_Authentication_Requests.html |    1 +
 ...600_-_Tekniskt_ramverk_-_Introduktion.html |    1 -
 ...Profile_for_the_Swedish_eID_Framework.html |    1 -
 .../ELN-0603_-_Registry_for_Identifiers.html  |    1 -
 ...ication_for_the_Swedish_eID_Framework.html |    1 -
 ...egories_for_the_Swedish_eID_Framework.html |    1 -
 ...using_DSS_in_Central_Signing_Services.html |    1 -
 ..._Profile_for_Central_Signing_Services.html |    1 -
 ...ension_for_Federated_Signing_Services.html |    1 -
 ...ication_for_the_Swedish_eID_Framework.html |    1 -
 ...Profile_for_the_Swedish_eID_Framework.html |    1 -
 ...-0613_-_Signature_Activation_Protocol.html |    1 -
 ...ction_in_SAML_Authentication_Requests.html |    1 -
 ...nnect_Claims_and_Scopes_Specification.html |    1 +
 ...ID_Connect_Profile_for_Sweden_Connect.html |    1 +
 ...using_DSS_in_Central_Signing_Services.html |   48 +-
 ..._Profile_for_Central_Signing_Services.html |   94 +-
 ...ension_for_Federated_Signing_Services.html |   26 +-
 ...ication_for_the_Swedish_eID_Framework.html |  391 ++--
 ...Profile_for_the_Swedish_eID_Framework.html |  441 ++---
 ...ction_in_SAML_Authentication_Requests.html |  122 +-
 ..._Swedish_eID_Framework_-_Introduction.html |  531 +-----
 .../00_-_Tekniskt_ramverk_-_Introduktion.html |  549 +-----
 ...Profile_for_the_Swedish_eID_Framework.html | 1586 +---------------
 .../03_-_Registry_for_Identifiers.html        | 1215 +-----------
 ...ication_for_the_Swedish_eID_Framework.html | 1228 +-----------
 ...egories_for_the_Swedish_eID_Framework.html |  690 +------
 ...using_DSS_in_Central_Signing_Services.html |    2 +-
 ..._Profile_for_Central_Signing_Services.html |    2 +-
 ...ension_for_Federated_Signing_Services.html |    2 +-
 ...ication_for_the_Swedish_eID_Framework.html |    2 +-
 ...Profile_for_the_Swedish_eID_Framework.html |    2 +-
 .../13_-_Signature_Activation_Protocol.html   |  497 +----
 ...ction_in_SAML_Authentication_Requests.html |    2 +-
 .../15_-_Signature_Validation_Token.html      |  726 -------
 ...ofile_for_Signature_Validation_Tokens.html |  215 ---
 ...ofile_for_Signature_Validation_Tokens.html |  247 ---
 ...nsion_in_SAML_Authentication_Requests.html |  221 +--
 ...nnect_Claims_and_Scopes_Specification.html |    1 +
 ...ID_Connect_Profile_for_Sweden_Connect.html |    1 +
 scripts/release.sh                            |   12 +-
 85 files changed, 12486 insertions(+), 8950 deletions(-)
 create mode 100644 docs/december-2024/00_-_Swedish_eID_Framework_-_Introduction.html
 create mode 100644 docs/december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html
 create mode 100644 docs/december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
 create mode 100644 docs/december-2024/03_-_Registry_for_Identifiers.html
 create mode 100644 docs/december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
 create mode 100644 docs/december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
 create mode 100644 docs/december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
 create mode 100644 docs/december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html
 create mode 100644 docs/december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html
 create mode 100644 docs/december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
 create mode 100644 docs/december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
 create mode 100644 docs/december-2024/13_-_Signature_Activation_Protocol.html
 create mode 100644 docs/december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
 create mode 100644 docs/december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
 create mode 100644 docs/december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html
 create mode 100644 docs/december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html
 create mode 120000 docs/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
 delete mode 120000 docs/latest/ELN-0600_-_Tekniskt_ramverk_-_Introduktion.html
 delete mode 120000 docs/latest/ELN-0602_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
 delete mode 120000 docs/latest/ELN-0603_-_Registry_for_Identifiers.html
 delete mode 120000 docs/latest/ELN-0604_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
 delete mode 120000 docs/latest/ELN-0606_-_Entity_Categories_for_the_Swedish_eID_Framework.html
 delete mode 120000 docs/latest/ELN-0607_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
 delete mode 120000 docs/latest/ELN-0608_-_Certificate_Profile_for_Central_Signing_Services.html
 delete mode 120000 docs/latest/ELN-0609_-_DSS_Extension_for_Federated_Signing_Services.html
 delete mode 120000 docs/latest/ELN-0611_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
 delete mode 120000 docs/latest/ELN-0612_-_BankID_Profile_for_the_Swedish_eID_Framework.html
 delete mode 120000 docs/latest/ELN-0613_-_Signature_Activation_Protocol.html
 delete mode 120000 docs/latest/ELN-0614_-_Principal_Selection_in_SAML_Authentication_Requests.html
 create mode 120000 docs/latest/OpenID_Connect_Claims_and_Scopes_Specification.html
 create mode 120000 docs/latest/OpenID_Connect_Profile_for_Sweden_Connect.html
 mode change 100644 => 120000 docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html
 mode change 100644 => 120000 docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html
 mode change 100644 => 120000 docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
 mode change 100644 => 120000 docs/updates/03_-_Registry_for_Identifiers.html
 mode change 100644 => 120000 docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
 mode change 100644 => 120000 docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
 mode change 100644 => 120000 docs/updates/13_-_Signature_Activation_Protocol.html
 delete mode 100644 docs/updates/15_-_Signature_Validation_Token.html
 delete mode 100644 docs/updates/16_-_PDF_Profile_for_Signature_Validation_Tokens.html
 delete mode 100644 docs/updates/17_-_XML_Profile_for_Signature_Validation_Tokens.html
 mode change 100644 => 120000 docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
 create mode 120000 docs/updates/OpenID_Connect_Claims_and_Scopes_Specification.html
 create mode 120000 docs/updates/OpenID_Connect_Profile_for_Sweden_Connect.html

diff --git a/00 - Swedish eID Framework - Introduction.md b/00 - Swedish eID Framework - Introduction.md
index 9992996..25b0c26 100644
--- a/00 - Swedish eID Framework - Introduction.md	
+++ b/00 - Swedish eID Framework - Introduction.md	
@@ -8,7 +8,7 @@
 
 # Introduction to the Sweden Connect Technical Framework
 
-### 2024-12-02
+### 2024-12-04
 
 Registration number: **2019-267**
 
diff --git a/00 - Tekniskt ramverk - Introduktion.md b/00 - Tekniskt ramverk - Introduktion.md
index 144cac2..3078316 100644
--- a/00 - Tekniskt ramverk - Introduktion.md	
+++ b/00 - Tekniskt ramverk - Introduktion.md	
@@ -8,7 +8,7 @@
 
 # En introduktion till Sweden Connect Tekniskt ramverk
 
-### 2024-12-02
+### 2024-12-04
 
 Diarienummer: **2019-267**
 
diff --git a/02 - Deployment Profile for the Swedish eID Framework.md b/02 - Deployment Profile for the Swedish eID Framework.md
index 4726496..beb38fa 100644
--- a/02 - Deployment Profile for the Swedish eID Framework.md	
+++ b/02 - Deployment Profile for the Swedish eID Framework.md	
@@ -8,7 +8,7 @@
 
 # Deployment Profile for the Swedish eID Framework
 
-### Version 1.8 - 2024-12-04 - *Draft version*
+### Version 1.8 - 2024-12-04
 
 Registration number: **2019-308**
 
@@ -141,7 +141,7 @@ by this profile.
 <a name="requirements-notation"></a>
 ### 1.1. Requirements Notation
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in
 \[[RFC2119](http://www.ietf.org/rfc/rfc2119.txt)\].
@@ -279,9 +279,9 @@ messages using both the old and new key.
 <a name="declaring-algorithm-support"></a>
 ##### 2.1.1.3. Declaring Algorithm Support
 
-Services MAY declare encryption and signature capabilities as defined in \[[SAML2MetaAlgSupport](#saml2metaalg)\]. The declared algorithms MUST meet the algorithm requirements defined by the Swedish eID Framework or by the federation operator . Thus, it is not allowed to declare an algorithm, or key size, that is prohibited from use. 
+Services MAY declare encryption and signature capabilities as defined in \[[SAML2MetaAlgSupport](#saml2metaalg)\]. The declared algorithms MUST meet the algorithm requirements defined by the Sweden Connect Framework or by the federation operator . Thus, it is not allowed to declare an algorithm, or key size, that is prohibited from use. 
 
-All services conformant with this specification MUST support the mandatory algorithms defined by the Swedish eID Framework, meaning that a service has no possibility to opt-out from a certain mandatory algorithm by excluding it from the declared capabilities. The main purpose of declaring an algorithm using any of the elements `<md:EncryptionMethod>`, `<alg:SigningMethod>` or `<alg:DigestMethod>` is to declare which algorithm the service prefers.
+All services conformant with this specification MUST support the mandatory algorithms defined by the Sweden Connect Framework, meaning that a service has no possibility to opt-out from a certain mandatory algorithm by excluding it from the declared capabilities. The main purpose of declaring an algorithm using any of the elements `<md:EncryptionMethod>`, `<alg:SigningMethod>` or `<alg:DigestMethod>` is to declare which algorithm the service prefers.
 
 <a name="service-providers"></a>
 #### 2.1.2. Service Providers
@@ -290,7 +290,7 @@ The `<mdattr:EntityAttributes>` element of a Service Provider’s
 entity descriptor SHOULD contain one entity category attribute
 \[[EntCat](#entcat)\] that holds at least
 one attribute value representing a service entity category as defined in
-\[[EidEntCat](#eidentcat)\], identifying the Service Provider requirements in relation to
+\[[SC.EntCat](#sc-entcat)\], identifying the Service Provider requirements in relation to
 identity services concerning attribute release and level of assurance.
 
 The example below illustrates how an entity declares the service entity
@@ -324,7 +324,7 @@ combination with `<md:RequestedAttribute>` elements under the
 Provider metadata. The `<md:RequestedAttribute>` elements in the
 Service Provider metadata, when present, hold a list of requested and/or
 required attributes. This list of attributes MUST be interpreted in the
-context of present service entity categories defined in \[[EidEntCat](#eidentcat)\].
+context of present service entity categories defined in \[[SC.EntCat](#sc-entcat)\].
 
 > Note: Only the requirements for attributes that are not implicitly requested through a declared
 service entity category need to be expressed as `<md:RequestedAttribute>` elements.
@@ -394,7 +394,7 @@ The `<mdattr:EntityAttributes>` element of an Identity Provider’s
 entity descriptor SHOULD contain one entity category attribute
 \[[EntCat](#entcat)\] that holds at least
 one attribute value representing a service entity category as defined in
-\[[EidEntCat](#eidentcat)\], defining the Identity Provider ability to deliver
+\[[SC.EntCat](#sc-entcat)\], defining the Identity Provider ability to deliver
 assertions (defining the level of assurance and attribute release).
 
 If an Identity Provider has the ability to release attributes, other than those
@@ -408,8 +408,8 @@ metadata SHALL contain an attribute according to
 `urn:oasis:names:tc:SAML:attribute:assurance-certification`
 and holding at least one attribute value identifying a Level of Assurance
 (LoA) for which the Identity Provider has been approved. 
-The Swedish eID Framework defines such identifier values in section 3.1.1 of
-\[[SC.Registry](#sc-registry)\] and their meanings are defined in \[[EidTillit](#eidtillit)\].
+The Sweden Connect Framework defines such identifier values in section 3.1.1 of
+\[[SC.Registry](#sc-registry)\] and their meanings are defined in \[[SE.Trust](#se-trust)\].
 
 ```
 <md:Extensions>
@@ -434,7 +434,7 @@ element to a value of `true`. See further section E7, “Metadata for
 Agreeing to Sign Authentication Requests”, of \[[SAML v2.0 Errata
 05](#saml2errata05)\].
 
-Identity Providers SHALL advertise support for the SAP protocol according to \[[SigSAP](#sigsap)\], by including the service property entity category URI
+Identity Providers SHALL advertise support for the SAP protocol according to \[[SC.SAP](#sc-sap)\], by including the service property entity category URI
 `http://id.elegnamnden.se/sprop/1.0/scal2` in its metadata. An Identity Provider that does not advertise support for SAP MAY ignore requests for SAD.
 
 ```
@@ -451,12 +451,12 @@ Identity Providers SHALL advertise support for the SAP protocol according to \[[
 ```
 *Example of how an Identity Provider advertises its support for SCAL2 authentication.*
 
-An Identity Provider that wishes to receive the `<psc:PrincipalSelection>` extension in authentication requests SHOULD include the `<psc:RequestedPrincipalSelection>` extension extending the `<md:IDPSSODescriptor>` element. In this extension the Identity Provider declares which attribute value(s) it wants to receive in authentication requests from requestors using the `<psc:PrincipalSelection>` authentication request extension. See [section 5.3.3](#principal-selection) and \[[PrincipalSel](#principalsel)\].
+An Identity Provider that wishes to receive the `<psc:PrincipalSelection>` extension in authentication requests SHOULD include the `<psc:RequestedPrincipalSelection>` extension extending the `<md:IDPSSODescriptor>` element. In this extension the Identity Provider declares which attribute value(s) it wants to receive in authentication requests from requestors using the `<psc:PrincipalSelection>` authentication request extension. See [section 5.3.3](#principal-selection) and \[[SC.Principal](#sc-principal)\].
 
 <a name="declaring-authorized-scopes"></a>
 ##### 2.1.3.1. Declaring Authorized Scopes
 
-An Identity Provider that releases "scoped attributes", see section 3.1.3 of \[[EidAttributes](#eidattributes)\],
+An Identity Provider that releases "scoped attributes", see section 3.1.3 of \[[SC.Attributes](#sc-attributes)\],
 MUST be authorized to do so by the federation operator. Each authorized scope MUST be declared in the Identity Provider metadata entry using a `<shibmd:Scope>` element, see section 3.5.2, "Scope Filtering", in \[[SAML2SubjIdAttr](#saml2subjidattr)\]. The `<shibmd:Scope>` elements MUST appear within the `<md:Extensions>` element of the `<md:IDPSSODescriptor>`.
 
 ```
@@ -510,13 +510,13 @@ If the Identity Provider also supports authentication according the ordinary Web
 <a name="signature-service"></a>
 #### 2.1.4. Signature Service
 
-A Signature Service within the Swedish eID Framework is a Service
+A Signature Service within the Sweden Connect Framework is a Service
 Provider with specific requirements concerning its representation in
 metadata. 
 
 The `<mdattr:EntityAttributes>` element of a Signature Service SP
 entity descriptor SHALL include the service type entity category
-identifier **`http://id.elegnamnden.se/st/1.0/sigservice`** (\[[EidEntCat](#eidentcat)\])
+identifier **`http://id.elegnamnden.se/st/1.0/sigservice`** (\[[SC.EntCat](#sc-entcat)\])
 as a value to the entity category attribute \[[EntCat](#entcat)\].
 
 ```
@@ -558,8 +558,8 @@ message).
 <a name="attributes"></a>
 ## 4. Attributes
 
-Attribute specifications for the Swedish eID Framework are defined in
-\[[EidAttributes](#eidattributes)\].
+Attribute specifications for the Sweden Connect Framework are defined in
+\[[SC.Attributes](#sc-attributes)\].
 
 The content of `<saml2:AttributeValue>` elements exchanged via any
 SAML 2.0 messages or assertions SHOULD be limited to a single child text
@@ -632,7 +632,7 @@ For the HTTP-POST binding the `<saml2p:AuthnRequest>` element MUST
 be signed using a `<ds:Signature>` element within the
 `<saml2:AuthnRequest>`.
 
-Before signing the authentication request, the Service Provider SHOULD consult the Identity Provider's metadata (`<alg:SigningMethod>` and `<alg:DigestMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory signing and digest algorithms defined in the Swedish eID Framework during the signature operation.
+Before signing the authentication request, the Service Provider SHOULD consult the Identity Provider's metadata (`<alg:SigningMethod>` and `<alg:DigestMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory signing and digest algorithms defined in the Sweden Connect Framework during the signature operation.
 
 > \[\*\]: A Service Provider should be aware of web browser, or web server, size limitations
 of URL:s, and it is RECOMMENDED that a Service Provider use the HTTP-POST binding in cases where 
@@ -692,7 +692,7 @@ one out of a selection of acceptable authentication context URIs, then
 all of these URIs MUST be included in the request.
 
 The requested authentication context SHOULD be consistent with at least
-one of the service entity categories \[[EidEntCat](#eidentcat)\] declared in the
+one of the service entity categories \[[SC.EntCat](#sc-entcat)\] declared in the
 Service Provider’s metadata entry. See further [section 5.4.4](#authentication-context-and-level-of-assurance-handling) below.
 
 ```
@@ -715,7 +715,7 @@ message.*
 *Example of how several Authentication Context URIs are included in an
 authentication request message. In this case, the Service Provider
 states that it requests the authentication to be performed according to
-either the LoA3 URI defined within the Swedish eID Framework or the
+either the LoA3 URI defined within the Sweden Connect Framework or the
 substantial level for notified eIDs defined within the eIDAS Framework.*
 
 <a name="scoping"></a>
@@ -754,7 +754,7 @@ extension of the `AuthnRequest` message, see section [5.3.3](#principal-selectio
 <a name="principal-selection"></a>
 #### 5.3.3. Principal Selection
 
-The specification "Principal Selection in SAML Authentication Requests", \[[PrincipalSel](#principalsel)\], defines the `<psc:PrincipalSelection>` extension that enables a requestor to inform the Identity Provider about known attributes for the principal that is about to be authenticated. 
+The specification "Principal Selection in SAML Authentication Requests", \[[SC.Principal](#sc-principal)\], defines the `<psc:PrincipalSelection>` extension that enables a requestor to inform the Identity Provider about known attributes for the principal that is about to be authenticated. 
 
 This may be relevant for Identity Provider services who prompt users for an identifier in order initiate an authentication process with the user's eID. In such cases, this extension can be used to avoid unnecessary prompting when the user's identity is known in advance to the service requesting authentication, such as when a previously authenticated user is requested to sign a document.
 
@@ -855,7 +855,7 @@ the Identity Provider MAY return the result of a default authentication
 process that is consistent with the Identity Providers metadata.
 
 **Note**: The Identity Provider does not have to consider the service
-entity categories (\[[EidEntCat](#eidentcat)\]) declared in the Service Provider’s
+entity categories (\[[SC.EntCat](#sc-entcat)\]) declared in the Service Provider’s
 metadata entry when determining the requested authentication context
 under which the authentication should be performed. The purpose of the
 service entity categories is primarily to support service matching in
@@ -939,7 +939,7 @@ message. The elements `<saml2:EncryptedID>` and
 `<saml2:EncryptedAttribute>` MUST NOT be used; instead the entire
 assertion MUST be encrypted.
 
-Before performing encryption and signing, the Identity Provider SHOULD consult the Service Provider's metadata (`<md:EncryptionMethod>`, `<alg:SigningMethod>` and `<alg:DigestMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Service Provider prefers. If the intersection is empty, or if the Service Provider has not declared any algorithms, the Identity Provider MUST use algorithms listed as mandatory by the Swedish eID Framework. For encryption, the chosen algorithm MUST also be compatible with the Service Provider's encryption key 
+Before performing encryption and signing, the Identity Provider SHOULD consult the Service Provider's metadata (`<md:EncryptionMethod>`, `<alg:SigningMethod>` and `<alg:DigestMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Service Provider prefers. If the intersection is empty, or if the Service Provider has not declared any algorithms, the Identity Provider MUST use algorithms listed as mandatory by the Sweden Connect Framework. For encryption, the chosen algorithm MUST also be compatible with the Service Provider's encryption key 
 declared in metadata.
 
 Service Providers SHOULD NOT accept unsolicited `<saml2p:Response>`
@@ -968,7 +968,7 @@ especially important in cases of re-use of already established security
 contexts at the Identity Provider side (Single Sign On).
 
 Each identity assertion MUST have a `<saml:Subject>` element that
-specifies the principal that is the subject of all of the statements in
+specifies the principal that is the subject of all the statements in
 the assertion.
 
 The value of the `<saml:NameID>` element under the
@@ -1055,19 +1055,19 @@ An Identity Provider determines which attributes to include in the
 `<saml2:AttributeStatement>` element of an assertion based on the
 Service Provider requirements and its agreements with the user being
 authenticated. Service Provider attribute preferences and requirements
-are specified by the service entity categories \[[EidEntCat](#eidentcat)\] and
+are specified by the service entity categories \[[SC.EntCat](#sc-entcat)\] and
 requested attributes in the `<md:AttributeConsumingService>` element
 declared in the Service Provider metadata. A service entity category
-specifies the attribute set (as defined in \[[EidAttributes](#eidattributes)\]) that is
+specifies the attribute set (as defined in \[[SC.Attributes](#sc-attributes)\]) that is
 requested for the attribute release process.
 
 An Identity Provider declares service entity categories in order to
 publish its ability to deliver attributes according to certain attribute
 sets. For all declared service entity categories, the Identity Provider
 MUST possess the ability to deliver the mandatory attributes of the
-underlying attribute set. See \[[EidEntCat](#eidentcat)\] and \[[EidAttributes](#eidattributes)\] for details.
+underlying attribute set. See \[[SC.EntCat](#sc-entcat)\] and \[[SC.Attributes](#sc-attributes)\] for details.
 
-An Identity Provider releasing scoped attributes, see section 3.1.3 of \[[EidAttributes](#eidattributes)\], MUST be authorized to release attributes with given scopes by the federation operator. An Identity Provider's authorized scopes are published in its metadata according to section [2.1.3.1](#declaring-authorized-scopes), "[Declaring Authorized Scopes](#declaring-authorized-scopes)". 
+An Identity Provider releasing scoped attributes, see section 3.1.3 of \[[SC.Attributes](#sc-attributes)\], MUST be authorized to release attributes with given scopes by the federation operator. An Identity Provider's authorized scopes are published in its metadata according to section [2.1.3.1](#declaring-authorized-scopes), "[Declaring Authorized Scopes](#declaring-authorized-scopes)". 
 
 Consequently, a Service Provider consuming a scoped attribute SHOULD verify that the issuing Identity Provider has been authorized to release attributes for the given scope by asserting its presence in the Identity Provider's metadata, see section [2.1.3.1](#declaring-authorized-scopes) and section 3.5.2 of \[[SAML2SubjIdAttr](#saml2subjidattr)\]. A scoped attribute that fails this check MUST NOT be accepted by the Service Provider.
 
@@ -1279,9 +1279,9 @@ If an Identity Provider detects suspicious fraudulent behaviour or if any of its
 <a name="authentication-for-signature"></a>
 ## 7. Authentication for Signature
 
-“DSS Extension for Federated Central Signing Services”, \[[EidDSS](#eiddss)\],
+“DSS Extension for Federated Central Signing Services”, \[[SC.DSS.Ext](#sc-dss-ext)\],
 defines an extension to the OASIS DSS protocol for providing centralized
-Signature Services within the Swedish eID Framework. This specification
+Signature Services within the Sweden Connect Framework. This specification
 defines the communication between a *Signature Requestor*<sup>*</sup> and a
 Signature Service, but does not cover SAML specific requirements
 regarding the user authentication phase that is part of the signature
@@ -1308,7 +1308,7 @@ following requirements:
     also be indicated in the Signature Service metadata record using the
     `AuthnRequestsSigned` attribute (see [section 2.1.4](#signature-service)).
 
-If the receiving Identity Provider has declared that it wishes to receive principal selection information about the signer (see [section 5.3.3](#principal-selection)), and the Signature Service has received any of the requested attribute values in the `Signer` element of the `SignRequest` (\[[EidDSS](#eiddss)\]), the Signature Service SHOULD include those attribute values in a `<psc:PrincipalSelection>` extension of the authentication request. 
+If the receiving Identity Provider has declared that it wishes to receive principal selection information about the signer (see [section 5.3.3](#principal-selection)), and the Signature Service has received any of the requested attribute values in the `Signer` element of the `SignRequest` (\[[SC.DSS.Ext](#sc-dss-ext)\]), the Signature Service SHOULD include those attribute values in a `<psc:PrincipalSelection>` extension of the authentication request. 
 
 It is RECOMMENDED that the `<saml2p:Scoping>` element containing a `<saml2p:RequesterID>` element holding the entityID of the Service Requestor is included in `<saml2p:AuthnRequest>` messages generated by a Signature Service.
 
@@ -1330,8 +1330,8 @@ end user is performing a signature.
 <a name="requesting-display-of-signature-message"></a>
 #### 7.1.1. Requesting Display of Signature Message
 
-\[[EidDSS\_Profile](#eiddssprofile)\] specifies that a Signature Requestor may include a
-`SignMessage` element (as defined by \[[EidDSS](#eiddss)\]) in a signature request.
+\[[SC.DSS.Profile](#sc-dss-profile)\] specifies that a Signature Requestor may include a
+`SignMessage` element (as defined by \[[SC.DSS.Ext](#sc-dss-ext)\]) in a signature request.
 This element holds a message that the Identity Provider, which is
 responsible for “authentication for signature”, should present to the
 user that is performing the signature.
@@ -1345,7 +1345,7 @@ element in the `<saml2p:AuthnRequest>` message (see section 3.2.1 of
 All Identity Providers compliant with this profile MUST be able to parse and understand
 the `SignMessage` extension.
 
-If the `Message`-element of the `SignMessage` is to be encrypted, the Service Provider SHOULD consult the Identity Provider's metadata (`<md:EncryptionMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory algorithms defined in the Swedish eID Framework during the encryption operation, which is compatible with the Identity Provider's encryption key declared in metadata.
+If the `Message`-element of the `SignMessage` is to be encrypted, the Service Provider SHOULD consult the Identity Provider's metadata (`<md:EncryptionMethod>` elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory algorithms defined in the Sweden Connect Framework during the encryption operation, which is compatible with the Identity Provider's encryption key declared in metadata.
 
 If an Identity Provider that has ways of determining the principal's identity before displaying
 a sign message receives a `<psc:PrincipalSelection>` extension in  the authentication request 
@@ -1372,7 +1372,7 @@ from signature services):
   return an error response.
   
 - If authentication and sign message confirmation by the user was successful, the Identity Provider 
-  MUST include the `signMessageDigest` attribute (see section 3.2.4 of \[[EidAttributes](#eidattributes)\]) 
+  MUST include the `signMessageDigest` attribute (see section 3.2.4 of \[[SC.Attributes](#sc-attributes)\]) 
   in the assertion that is issued.
 
 - The Identity Provider MUST NOT return an assertion without performing an authentication process 
@@ -1383,18 +1383,18 @@ from signature services):
 <a name="requesting-scal2-signature-activation-data"></a>
 #### 7.1.2. Requesting SCAL2 Signature Activation Data
 
-The type of signature requested in a signature request is, according to \[[EidDSS_Profile](#eiddssprofile)\], specified by the `CertType` attribute of the `<CertRequestProperties>` element. When the value of this attribute is set to `QC/SSCD`, the requested signature is a Qualified Signature created in a Qualified Signature Creation Device (QSCD). To achieve this level of signature the Authentication Request MUST include a request for Signature Activation Data (SAD) for Sole Control Assurance Level 2 (SCAL2) in accordance with the "Signature Activation Protocol for Federated Signing" \[[SigSAP](#sigsap)\], and MUST include the `SignMessage` extension (as described above).
+The type of signature requested in a signature request is, according to \[[SC.DSS.Profile](#sc-dss-profile)\], specified by the `CertType` attribute of the `<CertRequestProperties>` element. When the value of this attribute is set to `QC/SSCD`, the requested signature is a Qualified Signature created in a Qualified Signature Creation Device (QSCD). To achieve this level of signature the Authentication Request MUST include a request for Signature Activation Data (SAD) for Sole Control Assurance Level 2 (SCAL2) in accordance with the "Signature Activation Protocol for Federated Signing" \[[SC.SAP](#sc-sap)\], and MUST include the `SignMessage` extension (as described above).
 
 As pointed out in [section 2.1.3](#identity-providers) an Identity Provider that supports processing of SAD requests and issuance of SAD-attributes SHALL advertise this by declaring the service property entity category `http://id.elegnamnden.se/sprop/1.0/scal2` in its metadata. An Identity Provider that has declared this entity category MUST return a SAD attribute in an issued assertion if the corresponding `<saml2p:AuthnRequest>` message contains the `<sap:SADRequest>` extension.
 
 A SAD returned from the Identity Provider MUST have a signature which can be verified using a certificate from the Identity Provider's metadata entry. The signature algorithm used to sign the SAD MUST be equivalent to the algorithm used to sign the responses and assertions from the Identity Provider.
 
-Verification of a received SAD-attribute MUST follow the verification rules specified in section 3.2.3 of \[[SigSAP](#sigsap)\].
+Verification of a received SAD-attribute MUST follow the verification rules specified in section 3.2.3 of \[[SC.SAP](#sc-sap)\].
 
 <a name="authentication-responses2"></a>
 ### 7.2. Authentication Responses
 
-By including the `signMessageDigest` attribute (see section 3.2.4 of \[[EidAttributes](#eidattributes)\]) 
+By including the `signMessageDigest` attribute (see section 3.2.4 of \[[SC.Attributes](#sc-attributes)\]) 
 in the SAML assertion, the Identity Provider asserts that it has successfully displayed the sign message
 received in the request for the user and that the user has accepted to sign under the context of this sign message. This attribute MUST be included in the issued assertion if a sign message was displayed for, and accepted by, the user.
 
@@ -1505,7 +1505,7 @@ A service wishing to receive encrypted messages where SHA-1 is not used as the k
 ```
 *Example of how a service announces that it wishes that the peer uses SHA-256 as the key transport digest when encrypting using RSA-OAEP-MGF1P.*
 
-> \[*\]: Note that the use if SHA-1 in this context (both as digest algoritm and as mask generation function) is limited to providing randomness of padding data and as a hash over optional OAEP parameter data which typically is an empty string. It is not used as a hash function to assert the integrity of the encrypted data. No weaknesses of SHA-1 is is known to be relevant to its use in this context.
+> \[*\]: Note that the use if SHA-1 in this context (both as digest algoritm and as mask generation function) is limited to providing randomness of padding data and as a hash over optional OAEP parameter data which typically is an empty string. It is not used as a hash function to assert the integrity of the encrypted data. No weaknesses of SHA-1 are known to be relevant to its use in this context.
 
 <a name="normative-references"></a>
 ## 9. Normative References
@@ -1604,38 +1604,38 @@ A service wishing to receive encrypted messages where SHA-1 is not used as the k
 **\[SAML2HokAP\]**
 > [OASIS Committee Specification, SAML V2.0 Holder-of-Key Assertion Profile Version 1.0, January 2010](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key.pdf).
 
-<a name="eidtillit"></a>
-**\[EidTillit\]**
+<a name="se-trust"></a>
+**\[SE.Trust\]**
 > [Tillitsramverket för Svensk e-legitimation](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation).
 
 <a name="sc-registry"></a>
 **\[SC.Registry\]**
 > [Sweden Connect - Registry for identifiers](https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html).
 
-<a name="eidattributes"></a>
-**\[EidAttributes\]**
+<a name="sc-attributes"></a>
+**\[SC.Attributes\]**
 > [Attribute Specification for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html).
 
-<a name="eidentcat"></a>
-**\[EidEntCat\]**
+<a name="sc-entcat"></a>
+**\[SC.EntCat\]**
 > [Entity Categories for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html).
 
-<a name="eiddss"></a>
-**\[EidDSS\]**
+<a name="sc-principal"></a>
+**\[SC.Principal\]**
+> [Principal Selection in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html).
+
+<a name="sc-dss-ext"></a>
+**\[SC.DSS.Ext\]**
 > [DSS Extension for Federated Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html).
 
-<a name="seiddssprofile"></a>
-**\[EidDSS\_Profile\]**
+<a name="sc-dss-profile"></a>
+**\[SC.DSS.Profile\]**
 > [Implementation Profile for Using OASIS DSS in Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html).
 
-<a name="sigsap"></a>
-**\[SigSAP\]**
+<a name="sc-sap"></a>
+**\[SC.SAP\]**
 > [Signature Activation Protocol for Federated Signing](https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html).
 
-<a name="principalsel"></a>
-**\[PrincipalSel\]**
-> [Principal Selection in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html).
-
 <a name="rfc4051"></a>
 **\[RFC4051\]**
 > [IETF RFC 4051, Additional XML Security Uniform Resource Identifiers, April 2005](https://www.ietf.org/rfc/rfc4051.txt).
@@ -1650,7 +1650,7 @@ A service wishing to receive encrypted messages where SHA-1 is not used as the k
 
 **Changes between version 1.7 and 1.8:**
 
-- Section 7.1.2 was updated to state that the requirement to include both a SAD and a SignMessage extension only applies when the requested CertType is "QC/SSCD". Voluntary use of SAD for other types of signatures (e.g. non qualified signatures) does not automatically trigger a requirement to include SignMessage.
+- Section 7.1.2 was updated to state that the requirement to include both a SAD and a SignMessage extension only applies when the requested CertType is "QC/SSCD". Voluntary use of SAD for other types of signatures (e.g., nonqualified signatures) does not automatically trigger a requirement to include SignMessage.
 
 **Changes between version 1.6 and 1.7:**
 
@@ -1667,7 +1667,7 @@ A service wishing to receive encrypted messages where SHA-1 is not used as the k
 **Changes between version 1.5 and 1.6:**
 
 - In order to facilitate algorithm interoperability between peers additions concerning "Metadata Profile for Algorithm Support" \[[SAML2MetaAlgSupport](#saml2metaalg)\] was added. Section 2.1.1 was updated with a section defining how preferred algorithms are declared in metadata, and sections 5.2, 6.1 and 7.2.1 was updated with requirements for algorithm selection during signing and encryption.
-- Section 5.3, "Message Content", was re-structured with sub-chapters for requested authentication contexts, scoping and principal selection.
+- Section 5.3, "Message Content", was re-structured with subchapters for requested authentication contexts, scoping and principal selection.
 - The `PrincipalSelection` and `RequestedPrincipalSelection` extensions were introduced to sections 2.1.3, 5.3.3 and 7.2.
 - The link for the "Tillitsramverk för Svensk e-legitimation" specification was updated.
 - This profile is no longer normatively dependent upon SAML2Int. Therefore, the profile has been updated with requirements that previously was implicit (due to the normative dependency to SAML2Int).
@@ -1713,7 +1713,7 @@ and the use of the `signMessageDigest` attribute was introduced.
 -   In section 7.1, a set of authentication context URIs for the eIDAS
     Framework was added.
 
--   In section 6.4, the requirement to use the sub-level status code
+-   In section 6.4, the requirement to use the sublevel status code
     `http://id.elegnamnden.se/status/1.0/cancel` was added. This status
     should be used to indicate a cancelled operation.
 
@@ -1760,7 +1760,7 @@ and the use of the `signMessageDigest` attribute was introduced.
     difficult to make use of the `<saml2:AuthnContextDecl>` element
     to store authentication context parameters, and that no commercial,
     or open source, Identity Provider software had support for this
-    feature. \[EidAttributes\] now describe how the `authContextParams`
+    feature. \[SC.Attributes\] now describe how the `authContextParams`
     attribute may be used for the same purpose, and the examples where
     this information was stored under the `<saml2:AuthnContextDecl>`
     element was removed from chapter 6.2, “Message Content”.
diff --git a/03 - Registry for Identifiers.md b/03 - Registry for Identifiers.md
index 611c2c0..e437af7 100644
--- a/03 - Registry for Identifiers.md	
+++ b/03 - Registry for Identifiers.md	
@@ -8,7 +8,7 @@
 
 # Sweden Connect - Registry for identifiers
 
-### Version 1.8 - 2024-11-26 - *Draft version*
+### Version 1.8 - 2024-12-04
 
 Registration number: **2019-309**
 
@@ -193,14 +193,14 @@ The following category codes are defined:
 #### 3.1.1. Authentication Context URIs
 
 Authentication Context URIs representing assurance levels (Tillitsnivåer) relevant to
-\[[TillitRamv](#tillitramv)\] and \[[EidDeploy](#eiddeploy)\].
+\[[SE.Trust](#se-trust)\] and \[[SC.SAML.Profile](#sc-saml-profile)\].
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/loa/1.0/loa1` | Assurance level 1. | \[[TillitRamv](#tillitramv)\] |
-| `http://id.elegnamnden.se/loa/1.0/loa2` | Assurance level 2. | \[[TillitRamv](#tillitramv)\] |
-| `http://id.elegnamnden.se/loa/1.0/loa3` | Assurance level 3. | \[[TillitRamv](#tillitramv)\] |
-| `http://id.elegnamnden.se/loa/1.0/loa4` | Assurance level 4. | \[[TillitRamv](#tillitramv)\] |
+| `http://id.elegnamnden.se/loa/1.0/loa1` | Assurance level 1. | \[[SE.Trust](#se-trust)\] |
+| `http://id.elegnamnden.se/loa/1.0/loa2` | Assurance level 2. | \[[SE.Trust](#se-trust)\] |
+| `http://id.elegnamnden.se/loa/1.0/loa3` | Assurance level 3. | \[[SE.Trust](#se-trust)\] |
+| `http://id.elegnamnden.se/loa/1.0/loa4` | Assurance level 4. | \[[SE.Trust](#se-trust)\] |
 | `http://id.elegnamnden.se/loa/1.0/eidas-low`<sup>\*</sup> | Authentication accordance to eIDAS assurance level low for non-notified and notified eID schemes. | \[[eIDAS](#eidas)\] |
 | `http://id.elegnamnden.se/loa/1.0/eidas-sub`<sup>\*</sup> | Authentication accordance to eIDAS assurance level substantial for non-notified and notified eID schemes. | \[[eIDAS](#eidas)\] |
 | `http://id.elegnamnden.se/loa/1.0/eidas-high`<sup>\*</sup> | Authentication accordance to eIDAS assurance level high for non-notified and notified eID schemes. | \[[eIDAS](#eidas)\] |
@@ -227,12 +227,12 @@ following `AuthnContextClassRef` URI:s defined by the EU commission:
 > \[*\]: The authentication context URI:s are intended to be used to represent authentication
 over the eIDAS authentication framework using an official eIDAS-connector. Authorization to 
 issue assertions using these authentication context URI:s is determined by declaration of the
-"assurance certification" for the connector (see section 2.1.3 of \[[EidDeploy](#eiddeploy)\]).
+"assurance certification" for the connector (see section 2.1.3 of \[[SC.SAML.Profile](#sc-saml-profile)\]).
 
 <a name="authentication-context-uris-for-swedish-non-residents"></a>
 ##### 3.1.1.1. Authentication Context URIs for Swedish Non-residents
 
-The Swedish assurance framework, \[[TillitRamv](#tillitramv)\], states that a Swedish eID
+The Swedish assurance framework, \[[SE.Trust](#se-trust)\], states that a Swedish eID
 according to any of the defined assurance levels must only be issued to an individual holding
 a Swedish personal identity number (personnummer) or a Swedish coordination number 
 (samordningsnummer).
@@ -240,7 +240,7 @@ a Swedish personal identity number (personnummer) or a Swedish coordination numb
 In some cases, a certified eID-issuer may also issue eIDs to persons that do not hold
 a Swedish identity number (non-residents). If this is the case, and the original 
 identification of the person has a strength that corresponds to the requirements 
-put in \[[TillitRamv](#tillitramv)\], a certified Identity Provider or OpenID Provider MAY use the URIs
+put in \[[SE.Trust](#se-trust)\], a certified Identity Provider or OpenID Provider MAY use the URIs
 defined below:
 
 | **URL** | **Object** | **Reference** |
@@ -255,14 +255,14 @@ This is per definition since these URIs are intended to be used for non-resident
 <a name="authentication-context-uris-for-uncertified-providers"></a>
 ##### 3.1.1.2. Authentication Context URIs for Uncertified Providers
 
-The assurance levels defined in section [3.1.1](#authentication-context-uris) may only be used by Identity Providers, or OpenID Providers, that have been reviewed and approved by the Swedish Agency for Digital Government (Digg) according to \[[TillitRamv](#tillitramv)\]. For providers that have not undergone a review process but make a self declaration to be compliant with \[[TillitRamv](#tillitramv)\] this specification defines the following authentication context URIs:
+The assurance levels defined in section [3.1.1](#authentication-context-uris) may only be used by Identity Providers, or OpenID Providers, that have been reviewed and approved by the Swedish Agency for Digital Government (Digg) according to \[[SE.Trust](#se-trust)\]. For providers that have not undergone a review process but make a self declaration to be compliant with \[[SE.Trust](#se-trust)\] this specification defines the following authentication context URIs:
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
 | `http://id.swedenconnect.se/loa/1.0/`<br/>`uncertified-loa2` | URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 2 - `http://id.elegnamnden.se/loa/1.0/loa2`. | This document |
 | `http://id.swedenconnect.se/loa/1.0/`<br/>`uncertified-loa3` | URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 3 - `http://id.elegnamnden.se/loa/1.0/loa3`. | This document |
 
-Proxy providers that have eIDAS authentication as an option MUST NOT use the eIDAS authentication context URIs defined in section [3.1.1](#authentication-context-uris). Instead they should use:
+Proxy providers that have eIDAS authentication as an option MUST NOT use the eIDAS authentication context URIs defined in section [3.1.1](#authentication-context-uris), instead they should use:
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
@@ -277,12 +277,12 @@ Identifiers for attribute sets defined in the Sweden Connect SAML Attribute Spec
 
 | **Identifier** | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- | :--- |
-| ELN-AP-Pseudonym-01  | `http://id.elegnamnden.se/ap/1.0/pseudonym-01` | Pseudonym identity attribute set.  | \[[EidAttributes](#eidattributes)\] |
-| ELN-AP-NaturalPerson-01 | `http://id.elegnamnden.se/ap/1.0/natural-person-01` | Personal identity without civic registration number attribute set. | \[[EidAttributes](#eidattributes)\] |
-| ELN-AP-Pnr-01 | `http://id.elegnamnden.se/ap/1.0/pnr-01` | Personal identity with civic registration number attribute set. | \[[EidAttributes](#eidattributes)\] |
-| ELN-AP-OrgPerson-01 | `http://id.elegnamnden.se/ap/1.0/org-person-01` | Organizational identity attribute set. | \[[EidAttributes](#eidattributes)\] |
-| ELN-AP-eIDAS-NatPer-01 | `http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01` | Natural person identity for the eIDAS Framework. | \[[EidAttributes](#eidattributes)\] |
-| DIGG-AP-HSAid-01 | `http://id.swedenconnect.se/ap/1.0/hsaid-01` | Natural Person Identity with HSA-ID | \[[EidAttributes](#eidattributes)\] |
+| ELN-AP-Pseudonym-01  | `http://id.elegnamnden.se/ap/1.0/pseudonym-01` | Pseudonym identity attribute set.  | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| ELN-AP-NaturalPerson-01 | `http://id.elegnamnden.se/ap/1.0/natural-person-01` | Personal identity without civic registration number attribute set. | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| ELN-AP-Pnr-01 | `http://id.elegnamnden.se/ap/1.0/pnr-01` | Personal identity with civic registration number attribute set. | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| ELN-AP-OrgPerson-01 | `http://id.elegnamnden.se/ap/1.0/org-person-01` | Organizational identity attribute set. | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| ELN-AP-eIDAS-NatPer-01 | `http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01` | Natural person identity for the eIDAS Framework. | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| DIGG-AP-HSAid-01 | `http://id.swedenconnect.se/ap/1.0/hsaid-01` | Natural Person Identity with HSA-ID | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
 
 <a name="entity-category-identifiers"></a>
 #### 3.1.3. Entity Category Identifiers
@@ -296,20 +296,20 @@ Identifiers for entity categories representing alternative sets of requirements.
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/`<br />`ec/1.0/loa2-pnr` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/`<br />`ec/1.0/loa3-pnr` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.elegnamnden.se/`<br />`ec/1.0/loa2-pnr` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/`<br />`ec/1.0/loa3-pnr` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 | `http://id.swedenconnect.se/`<br />`ec/sc/uncertified-loa3-pnr` | Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | |
-| `http://id.elegnamnden.se/`<br />`ec/1.0/loa4-pnr` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/`<br />`ec/1.0/eidas-naturalperson` | Service consuming/providing assertions based on any eIDAS assurance level, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/`<br />`ec/1.0/eidas-pnr-delivery` | Service providing assertions to eIDAS services via Swedish eIDAS-node | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.elegnamnden.se/`<br />`ec/1.0/loa4-pnr` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/pnr-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/`<br />`ec/1.0/eidas-naturalperson` | Service consuming/providing assertions based on any eIDAS assurance level, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/`<br />`ec/1.0/eidas-pnr-delivery` | Service providing assertions to eIDAS services via Swedish eIDAS-node | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 | `http://id.swedenconnect.se/`<br />`ec/1.0/loa3-hsaid` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.swedenconnect.se/ap/1.0/hsaid-01`. |  |
 | `http://id.swedenconnect.se/`<br />`ec/sc/uncertified-loa3-hsaid` | Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set `http://id.swedenconnect.se/ap/1.0/hsaid-01`. | |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa2-orgid` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa3-orgid` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa4-orgid` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa2-name` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa3-name` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/`<br />`ec/1.0/loa4-name` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa2-orgid` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa3-orgid` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa4-orgid` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/org-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa2-name` | Service consuming/providing assertions based on assurance level 2, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa3-name` | Service consuming/providing assertions based on assurance level 3, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/`<br />`ec/1.0/loa4-name` | Service consuming/providing assertions based on assurance level 4, implementing the attribute set `http://id.elegnamnden.se/ap/1.0/natural-person-01`. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 
 <a name="entity-categories-for-service-properties"></a>
 ##### 3.1.3.2. Entity Categories for Service Properties
@@ -318,8 +318,8 @@ Identifiers for defined service properties.
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/sprop/1.0/mobile-auth` | Service adapted to require/provide user authentication based on mobile devices. | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/sprop/1.0/scal2` | Service adapted to support authentication requests from signature services supporting Sole Control Assurance Level 2 (SCAL2). | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.elegnamnden.se/sprop/1.0/mobile-auth` | Service adapted to require/provide user authentication based on mobile devices. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/sprop/1.0/scal2` | Service adapted to support authentication requests from signature services supporting Sole Control Assurance Level 2 (SCAL2). | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 
 <a name="entity-categories-for-service-type"></a>
 ##### 3.1.3.3. Entity Categories for Service Type
@@ -328,9 +328,9 @@ Identifiers for defined service types.
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/st/1.0/sigservice` | Electronic signature service | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/st/1.0/public-sector-sp` | Public sector Service Provider | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.elegnamnden.se/st/1.0/private-sector-sp` | Private sector Service Provider | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.elegnamnden.se/st/1.0/sigservice` | Electronic signature service | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/st/1.0/public-sector-sp` | Public sector Service Provider | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.elegnamnden.se/st/1.0/private-sector-sp` | Private sector Service Provider | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 
 <a name="entity-categories-for-service-contract"></a>
 ##### 3.1.3.4. Entity Categories for Service Contract
@@ -339,7 +339,7 @@ Service Contract Entity Category identifiers are indented for performing service
 
 All Service Contract identifiers are prefixed with `http://id.swedenconnect.se/contract/<org>`, where `org` is the identifier for the defining organization.
 
-The Sweden Connect Framework specifications do not define any Service Contract identifiers. Instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.
+The Sweden Connect Framework specifications do not define any Service Contract identifiers, instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.
 
 <a name="general-entity-categories"></a>
 ##### 3.1.3.5. General Entity Categories
@@ -350,9 +350,9 @@ General category identifiers are prefixed with `http://id.swedenconnect.se/gener
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.swedenconnect.se/general-ec/`<br />`1.0/secure-authenticator-binding` | Indicator that a secure authenticator binding is required, or supported.  | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/general-ec/`<br />`1.0/accepts-coordination-number` | Category for opt-in for the acceptance of Swedish coordination numbers in the personalIdentityNumber attribute.  | \[[EidEntityCat](#eidentitycat)\] |
-| `http://id.swedenconnect.se/general-ec/`<br />`1.0/supports-user-message` | Indicator that an Identity Provider supports the `UserMessage` authentication request extension, see \[[UserMessageExt](#user-message-ext)\]. | \[[EidEntityCat](#eidentitycat)\] |
+| `http://id.swedenconnect.se/general-ec/`<br />`1.0/secure-authenticator-binding` | Indicator that a secure authenticator binding is required, or supported.  | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/general-ec/`<br />`1.0/accepts-coordination-number` | Category for opt-in for the acceptance of Swedish coordination numbers in the personalIdentityNumber attribute.  | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
+| `http://id.swedenconnect.se/general-ec/`<br />`1.0/supports-user-message` | Indicator that an Identity Provider supports the `UserMessage` authentication request extension, see \[[SC.SAML.UMsg](#sc-saml-umsg)\]. | \[[SC.SAML.EntCat](#sc-saml-entcat)\] |
 
 
 <a name="saml-protocol-status-codes"></a>
@@ -364,9 +364,9 @@ below extends the list of second-level status codes defined in section
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/status/1.0/cancel` | Status code representing a cancelled operation. | \[[EidDeploy](#eiddeploy)\] |
-| `http://id.elegnamnden.se/status/1.0/fraud` | Status code indicating a fraudulent request. | \[[EidDeploy](#eiddeploy)\] |
-| `http://id.elegnamnden.se/status/1.0/possibleFraud` | Status code indicating a possible fraudulent request. | \[[EidDeploy](#eiddeploy)\] |
+| `http://id.elegnamnden.se/status/1.0/cancel` | Status code representing a cancelled operation. | \[[SC.SAML.Profile](#sc-saml-profile)\] |
+| `http://id.elegnamnden.se/status/1.0/fraud` | Status code indicating a fraudulent request. | \[[SC.SAML.Profile](#sc-saml-profile)\] |
+| `http://id.elegnamnden.se/status/1.0/possibleFraud` | Status code indicating a possible fraudulent request. | \[[SC.SAML.Profile](#sc-saml-profile)\] |
 
 <a name="central-signing"></a>
 #### 3.1.5. Central Signing
@@ -377,9 +377,9 @@ Identifiers used in the protocol for requesting services form a central signing
 | :--- | :--- | :--- |
 | `http://id.elegnamnden.se/csig/1.0/dss-ext/ns` | **Deprecated**. XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.0). |  |
 | `http://id.elegnamnden.se/csig/1.0/eid2-dss/profile` | **Deprecated**. Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.0). |  |
-| `http://id.elegnamnden.se/csig/1.1/dss-ext/ns` | XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.1). | \[[EidDSSExt](#eiddssext)\] |
-| `http://id.elegnamnden.se/csig/1.1/dss-ext/profile` | Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.1). | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.elegnamnden.se/csig/1.1/sap/ns` | XML schema name space for the Signature Activation Protocol, extending version 1.1 of the DSS protocol extension | \[[EidSigSAP](#eidsigsap)\] |
+| `http://id.elegnamnden.se/csig/1.1/dss-ext/ns` | XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.1). | \[[SC.DSS.Ext](#sc-dss-ext)\] |
+| `http://id.elegnamnden.se/csig/1.1/dss-ext/profile` | Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.1). | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.elegnamnden.se/csig/1.1/sap/ns` | XML schema name space for the Signature Activation Protocol, extending version 1.1 of the DSS protocol extension | \[[SC.SAP](#sc-sap)\] |
 
 <a name="authentication-context"></a>
 #### 3.1.6. Authentication Context
@@ -389,7 +389,7 @@ Identifiers associated with the Authentication Context X.509 extension
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
 | `http://id.elegnamnden.se/auth-cont/1.0/saci` | XML schema namespace for SAML Authentication Context Information in the Authentication Context X.509 certificate extension | \[[RFC7773](#rfc7773)\] |
-| `http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info` | XML schema namespace for Extended Authentication Information in the Authentication Context X.509 certificate extension | \[[CertProf](#certprof)\] |
+| `http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info` | XML schema namespace for Extended Authentication Information in the Authentication Context X.509 certificate extension | \[[SC.Cert.Profile](#sc-cert-profile)\] |
 
 <a name="sign-response-status-codes"></a>
 #### 3.1.7. Sign Response Status Codes
@@ -398,13 +398,13 @@ Status code identifiers for the DSS Extension for Central Signing services. The
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/sig-status/1.0/req-expired` | The time window for the signature request has expired. | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.elegnamnden.se/sig-status/1.0/user-mismatch` | The authenticated user does not match the signer identity attributes in the request. | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.elegnamnden.se/sig-status/1.0/unsupported-loa` | The requested level of assurance for user authentication is not supported. | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.elegnamnden.se/sig-status/1.0/sigmessage-error` | A requirement to display sign message was included in the sign request, but the sign service could not establish that the sign message was displayed to the user. | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.elegnamnden.se/sig-status/1.0/user-cancel` | The end user cancelled the signature operation. | \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.swedenconnect.se/sig-status/1.1/authn-failed` | The authentication during the signature operation failed. |  \[[EidCSignProf](#eidcsignprof)\] |
-| `http://id.swedenconnect.se/sig-status/1.1/security-violation` | The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud). |  \[[EidCSignProf](#eidcsignprof)\] |
+| `http://id.elegnamnden.se/sig-status/1.0/req-expired` | The time window for the signature request has expired. | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.elegnamnden.se/sig-status/1.0/user-mismatch` | The authenticated user does not match the signer identity attributes in the request. | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.elegnamnden.se/sig-status/1.0/unsupported-loa` | The requested level of assurance for user authentication is not supported. | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.elegnamnden.se/sig-status/1.0/sigmessage-error` | A requirement to display sign message was included in the sign request, but the sign service could not establish that the sign message was displayed to the user. | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.elegnamnden.se/sig-status/1.0/user-cancel` | The end user cancelled the signature operation. | \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.swedenconnect.se/sig-status/1.1/authn-failed` | The authentication during the signature operation failed. |  \[[SC.DSS.Profile](#sc-dss-profile)\] |
+| `http://id.swedenconnect.se/sig-status/1.1/security-violation` | The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud). |  \[[SC.DSS.Profile](#sc-dss-profile)\] |
 
 <a name="name-registration-authorities"></a>
 #### 3.1.8. Name Registration Authorities
@@ -413,7 +413,7 @@ Some protocols require a URI identifier to uniquely identify the entity responsi
 
 | **URL** | **Object** | **Reference** |
 | :--- | :--- | :--- |
-| `http://id.elegnamnden.se/eln/name-registration-authority` | Identifying the Swedish e-Identification Board<sup>*</sup> as name registration authority, responsible for a particular namespace. | \[[CertProf](#certprof)\] |
+| `http://id.elegnamnden.se/eln/name-registration-authority` | Identifying the Swedish e-Identification Board<sup>*</sup> as name registration authority, responsible for a particular namespace. | \[[SC.Cert.Profile](#sc-cert-profile)\] |
 
 > \[*\]: This also covers the Swedish Agency for Digital Government (Digg) which has overtaken the Swedish E-identification Board's assignments.
 
@@ -425,7 +425,7 @@ This section defines identifiers used within the Sweden Connect Framework to int
 <a name="eidas-proxy-service-aliases"></a>
 ##### 3.1.9.1. eIDAS Proxy Service Aliases
 
-Each country within the eIDAS federation provides an eIDAS Proxy Service that is a Proxy Identity Provider for the authentication services within that specific country. The entityID identifier for an eIDAS Proxy Service in another country is not known to a Swedish Service Provider, but there are cases in which the Swedish Service Provider needs to refer to a specific eIDAS Proxy Service. Therefore, this specification defines an URI identifier format for eIDAS Proxy Service aliases. The format is as follows:
+Each country within the eIDAS federation provides an eIDAS Proxy Service that is a Proxy Identity Provider for the authentication services within that specific country. The entityID identifier for an eIDAS Proxy Service in another country is not known to a Swedish Service Provider, but there are cases in which the Swedish Service Provider needs to refer to a specific eIDAS Proxy Service. Therefore, this specification defines a URI identifier format for eIDAS Proxy Service aliases. The format is as follows:
 
 **`http://id.swedenconnect.se/eidas/1.0/proxy-service/{country-code}`**
 
@@ -449,7 +449,7 @@ where `{country-code}` is the country identifier in ISO 3166-1 alpha-2 format \[
 <a name="identity-binding-processes"></a>
 ##### 3.1.9.3. Identity Binding Processes
 
-Section 3.3.2 of \[[EidAttributes](#eidattributes)\] describes how the `personalIdentityNumberBinding` attribute is assigned with one or more "Identity Binding Process URI:s" after an identity binding. The possible values are: 
+Section 3.3.2 of \[[SC.SAML.Attrs](#sc-saml-attrs)\] describes how the `personalIdentityNumberBinding` attribute is assigned with one or more "Identity Binding Process URI:s" after an identity binding. The possible values are: 
 
 | **URI** | **Object** | **Reference** |
 | :--- | :--- | :--- |
@@ -479,22 +479,22 @@ The following OIDs are defined in the ASN.1 declarations in [3.2.1](#asn1-declar
 | 1.2.752.201.5.1 | Authentication Context Extension | \[[RFC7773](#rfc7773)\] |
 | 1.2.752.201.5.2 | Signature Validation Token Extension | \[[SVT-PDF](#svt-pdf)\] |
 | 1.2.752.201.2.1 | Object identifier for the Signature Validation Token RFC 3161 timestamp policy | |
-| 1.2.752.201.3.1 | Organization Affiliation Attribute | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.2 | Transaction Identifier | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.3 | Authentication Context Parameters | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.4 | Provisional ID | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.5 | Provisional ID Persistence Indicator | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.6 | Personal Identity Number Binding URI | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.7 | eIDAS Person Identifier | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.8 | Birth name | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.9 | eIDAS Natural Person Address | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.10 | User Certificate | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.11 | User Signature | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.12 | Signature Activation Data | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.13 | Authentication Server Signature | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.14 | Sign Message Digest | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.15 | Previous Personal Identity Number | \[[EidAttributes](#eidattributes)\] |
-| 1.2.752.201.3.16 | Mapped Personal Identity Number | \[[EidAttributes](#eidattributes)\] |
+| 1.2.752.201.3.1 | Organization Affiliation Attribute | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.2 | Transaction Identifier | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.3 | Authentication Context Parameters | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.4 | Provisional ID | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.5 | Provisional ID Persistence Indicator | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.6 | Personal Identity Number Binding URI | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.7 | eIDAS Person Identifier | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.8 | Birth name | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.9 | eIDAS Natural Person Address | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.10 | User Certificate | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.11 | User Signature | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.12 | Signature Activation Data | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.13 | Authentication Server Signature | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.14 | Sign Message Digest | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.15 | Previous Personal Identity Number | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
+| 1.2.752.201.3.16 | Mapped Personal Identity Number | \[[SC.SAML.Attrs](#sc-saml-attrs)\] |
 
 <a name="asn1-declarations"></a>
 #### 3.2.1. ASN.1 Declarations
@@ -561,49 +561,49 @@ Object Identifier Registry for Sweden Connect<sup>*</sup>
 > [Digital Signature Service Core Protocols, Elements, and Bindings
 > Version 1.0.](http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html)
 
-<a name="tillitramv"></a>
-**\[TillitRamv\]**
+<a name="se-trust"></a>
+**\[SE.Trust\]**
 > [Tillitsramverket för Svensk e-legitimation](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation).
 
 <a name="rfc7773"></a>
 **\[RFC7773\]**
 > [RFC7773: Authentication Context Certificate Extension](https://tools.ietf.org/html/rfc7773).
 
-<a name="eiddeploy"></a>
-**\[EidDeploy\]**
+<a name="sc-saml-profile"></a>
+**\[SC.SAML.Profile\]**
 > [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
 
-<a name="eidentitycat"></a>
-**\[EidEntityCat\]**
+<a name="sc-saml-entcat"></a>
+**\[SC.SAML.EntCat\]**
 > [Entity Categories for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html).
 
-<a name="eiddssext"></a>
-**\[EidDSSExt\]**
+<a name="sc-saml-attrs"></a>
+**\[SC.SAML.Attrs\]**
+> [Attribute Specification for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html).
+
+<a name="sc-saml-umsg"></a>
+**\[SC.SAML.UMsg\]**
+> [User Message Extension in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html).
+
+<a name="sc-dss-ext"></a>
+**\[SC.DSS.Ext\]**
 > [DSS Extension for Federated Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html).
 
-<a name="eidsigsap"></a>
-**\[EidSigSAP\]**
+<a name="sc-sap"></a>
+**\[SC.SAP\]**
 > [Signature Activation Protocol for Federated Signing](https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html).
 
-<a name="eidcsignprof"></a>
-**\[EidCSignProf\]**
+<a name="sc-dss-profile"></a>
+**\[SC.DSS.Profile\]**
 > [Implementation Profile for Using OASIS DSS in Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html).
 
-<a name="certprof"></a>
-**\[CertProf\]**
+<a name="sc-cert-profile"></a>
+**\[SC.Cert.Profile\]**
 > [Certificate profile for certificates issued by Central Signing services](https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html)
 
-<a name="eidattributes"></a>
-**\[EidAttributes\]**
-> [Attribute Specification for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html).
-
-<a name="user-message-ext"></a>
-**\[UserMessageExt\]**
-> [User Message Extension in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html).
-
 <a name="id-binding"></a>
 **\[ID-Binding\]**
-> [Binding eIDAS Identities to Records in the Swedish Population Register](https://docs.swedenconnect.se/technical-framework/Identity_Binding.html)
+> [Binding eIDAS Identities to Records in the Swedish Population Register](https://docs.swedenconnect.se/technical-framework/Identity_Binding.html)
 
 <a name="svt-pdf"></a>
 **\[SVT-PDF\]**
@@ -638,7 +638,7 @@ Object Identifier Registry for Sweden Connect<sup>*</sup>
 
 - Section, 3.1.3.5, "General Entity Categories", was introduced and `http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding` and `http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number` was added.
 
-- In section 3.2, an object identifier (OID) for Signature Validation Token extension was added and one OID for a SVT timestamp policy.
+- In section 3.2, an object identifier (OID) for Signature Validation Token extension was added and one OID for an SVT timestamp policy.
 
 - Added service entity categories `http://id.swedenconnect.se/ec/1.0/loa3-orgid` and `http://id.swedenconnect.se/ec/1.0/loa3-name` to section 3.1.3.1.
 
diff --git a/04 - Attribute Specification for the Swedish eID Framework.md b/04 - Attribute Specification for the Swedish eID Framework.md
index e19dcb8..6434e9e 100644
--- a/04 - Attribute Specification for the Swedish eID Framework.md	
+++ b/04 - Attribute Specification for the Swedish eID Framework.md	
@@ -1,21 +1,21 @@
-<p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
+<p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
 
 # Attribute Specification for the Swedish eID Framework
-
-### Version 1.8 - 2024-12-04 - *Draft version*
-
-Registration number: **2019-310**
-
----
-
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+
+### Version 1.8 - 2024-12-04
+
+Registration number: **2019-310**
+
+---
+
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
 </p>
 
 ## Table of Contents
@@ -24,7 +24,7 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
     1.1. [Terminology](#terminology)
 
-    1.2. [Requirement key words](#requirement-key-words)
+    1.2. [Requirement keywords](#requirement-keywords)
 
     1.3. [Name space references](#name-space-references)
 
@@ -40,19 +40,19 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
     2.4. [Organizational Identity for Natural Persons](#organizational-identity-for-natural-persons)
 
-    2.5. [eIDAS Natural Person Attribute Set](#eidas-natural-person-attribute-set)
-    
+    2.5. [eIDAS Natural Person Attribute Set](#eidas-natural-person-attribute-set)
+    
     2.6. [Natural Person Identity with HSA-ID](#natural-person-identity-with-hsa-id)
 
 3. [**Attribute Definitions**](#attribute-definitions)
 
-    3.1. [Attributes](#attributes)
-    
-    3.1.1. [Attribute String Values](#attribute-string-values)
-
-    3.1.2. [Multi-valued Attributes](#multi-valued-attributes)
-
-    3.1.3. [Scoped Attributes](#scoped-attributes)
+    3.1. [Attributes](#attributes)
+    
+    3.1.1. [Attribute String Values](#attribute-string-values)
+
+    3.1.2. [Multi-valued Attributes](#multi-valued-attributes)
+
+    3.1.3. [Scoped Attributes](#scoped-attributes)
 
     3.2. [SAML Attribute Format](#saml-attribute-format)
 
@@ -62,16 +62,16 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
     3.2.3. [The sad Attribute](#the-sad-attribute)
     
-    3.2.4. [The signMessageDigest Attribute](#the-signmessagedigest-attribute)
-    
-    3.2.5. [The orgAffiliation Attribute](#the-orgaffiliation-attribute)
-    
+    3.2.4. [The signMessageDigest Attribute](#the-signmessagedigest-attribute)
+    
+    3.2.5. [The orgAffiliation Attribute](#the-orgaffiliation-attribute)
+    
     3.2.6. [The previousPersonalIdentityNumber Attribute](#the-previouspersonalidentitynumber-attribute)
 
     3.3. [Attributes for the eIDAS Framework](#attributes-for-the-eidas-framework)
 
     3.3.1. [The prid and pridPersistence Attributes](#the-prid-and-pridpersistence-attributes)
-        
+        
     3.3.2. [The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes](#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute)
 
     3.3.3. [Conversion of eIDAS Attributes](#conversion-of-eidas-attributes)
@@ -105,10 +105,10 @@ release requirements.
 | **Natural person** | Natural person is legal term for a real human being, as opposed to a legal person, which may be a private (i.e., business entity) or public (i.e., government) organization. |
 | **Civic registration number** | A unique identifier assigned to each natural person in a national population register. Within the context of this specification this is a Swedish ”personnummer” or ”samordningsnummer” according to \[SKV704\] and \[SKV707\]. |
 
-<a name="requirement-key-words"></a>
-### 1.2. Requirement key words
+<a name="requirement-keywords"></a>
+### 1.2. Requirement keywords
 
-The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
 “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
 interpreted as described in \[[RFC2119](#rfc2119)\].
 
@@ -122,7 +122,7 @@ not capitalized, they are meant in their natural-language sense.
 
 Conventional XML namespace prefixes are used throughout the listings in
 this specification to stand for their respective namespaces as follows,
-whether or not a namespace declaration is present in the example:
+whether a namespace declaration is present in the example:
 
 | Prefix | XML Namespace | Comments |
 | :---- | :---- | :---- |
@@ -143,7 +143,7 @@ be present more than once. An attribute that has more than one value
 MUST be provided as one attribute with multiple `<AttributeValue>`
 sub-elements in accordance with [section 3.1](#attributes).
 
-An identifier, named “Attribute Set Identifier”, and an URI, are defined
+An identifier, named “Attribute Set Identifier”, and a URI, are defined
 for each attribute set as means for other documents to reference
 specific attribute sets.
 
@@ -156,7 +156,7 @@ the provider.
 **Note**: An Attribute Provider may also release other attributes, not
 specified by the defined attribute sets it supports. See further section
 6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish
-eID Framework” (\[[EidDeployProf](#eiddeployprof)\]).
+eID Framework” (\[[SC.SAML.Profile](#sc-saml-profile)\]).
 
 In order to comply with a defined attribute set, the following attribute
 requirements apply:
@@ -195,7 +195,7 @@ The “Personal Identity without Civic Registration Number” attribute set prov
 | :--- | :--- |
 | **REQUIRED** | `sn` (Surname) <br /> `givenName` (Given name) <br /> `displayName` (Display name) |
 
-**Typical use**: In an attribute release policy that provides basic user name information together with a persistent `NameID` identifier in the assertion.
+**Typical use**: In an attribute release policy that provides basic username information together with a persistent `NameID` identifier in the assertion.
 
 <a name="natural-personal-identity-with-civic-registration-number"></a>
 ### 2.3. Natural Personal Identity with Civic Registration Number
@@ -210,7 +210,7 @@ The “Personal Identity with Civic Registration Number” attribute set provide
 | **REQUIRED** | `sn` (Surname) <br /> `givenName` (Given name) <br /> `displayName` (Display name) <br /> `personalIdentityNumber` (National civic registration number) |
 | **RECOMMENDED** | `dateOfBirth` (Date of birth) |
 
-**Typical use**: In an attribute release policy that provides basic user name information together with the person’s Swedish civic registration number.
+**Typical use**: In an attribute release policy that provides basic username information together with the person’s Swedish civic registration number.
 
 <a name="organizational-identity-for-natural-persons"></a>
 ### 2.4. Organizational Identity for Natural Persons
@@ -226,15 +226,15 @@ The “Organizational Identity for Natural Persons” attribute set provides bas
 | **REQUIRED** | `displayName` (Display name)<sup>\*</sup> <br /> `orgAffiliation` (Personal identifier and organizational identifier code)<sup>\*\*</sup> <br /> `o` (Organization name) |
 | **RECOMMENDED** | `organizationIdentifier` (Organizational identifier code)<sup>\*\*\*</sup> |
 
-**Typical use**: In an attribute release policy that provides basic organizational identity information about a natural person.
-
-The "Organizational Identity for Natural Persons" attribute set defines a minimum set of attributes needed to provide organizational identity information about a person. Should an attribute consumer require additional attributes, such as surname and given name, the personal identity number or an organizational unit name, this can be achieved by either requesting other attribute sets or by explicitly requesting individual attributes. See further section 6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish eID Framework” (\[[EidDeployProf](#eiddeployprof)\]).
-
-> \[*\]: The `displayName` attribute MAY contain personal information such as the given name or surname, but it MAY also be used as an anonymized display name, for example, "Administrator 123". This is decided by the issuing organization.
-
-> \[\*\*\]: See section [3.2.5](#the-orgaffiliation-attribute).
-
-> \[\*\*\*]: The organizational identifier can always be derived from the mandatory `orgAffiliation` attribute, but an attribute provider supporting the "Organizational Identity for Natural Persons" attribute set SHOULD also release the `organizationIdentifier` attribute individually. 
+**Typical use**: In an attribute release policy that provides basic organizational identity information about a natural person.
+
+The "Organizational Identity for Natural Persons" attribute set defines a minimum set of attributes needed to provide organizational identity information about a person. Should an attribute consumer require additional attributes, such as surname and given name, the personal identity number or an organizational unit name, this can be achieved by either requesting other attribute sets or by explicitly requesting individual attributes. See further section 6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish eID Framework” (\[[SC.SAML.Profile](#sc-saml-profile)\]).
+
+> \[*\]: The `displayName` attribute MAY contain personal information such as the given name or surname, but it MAY also be used as an anonymized display name, for example, "Administrator 123". This is decided by the issuing organization.
+
+> \[\*\*\]: See section [3.2.5](#the-orgaffiliation-attribute).
+
+> \[\*\*\*]: The organizational identifier can always be derived from the mandatory `orgAffiliation` attribute, but an attribute provider supporting the "Organizational Identity for Natural Persons" attribute set SHOULD also release the `organizationIdentifier` attribute individually. 
 
 <a name="eidas-natural-person-attribute-set"></a>
 ### 2.5. eIDAS Natural Person Attribute Set
@@ -263,7 +263,7 @@ provider has access to enough information to provide a binding
 between eIDAS attributes and a Swedish identity number (see [section
 3.3.2](#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute)).
 
-The eIDAS attribute set comprises of “added” and “converted” attributes.
+The eIDAS attribute set consists of “added” and “converted” attributes.
 
 **Added attributes**: Attributes that are not provided by the member
 state node, but added by the
@@ -289,23 +289,24 @@ examples of “converted attributes”.
 
 > \[\*\*\]: The transaction identifier attribute will contain the unique ID of the assertion that was issued by the member state node. This information together with the entityID of the member state node (found in the `<saml2:AuthenticatingAuthority>` element of an assertion) give a reference to the original assertion and authentication process.
 
-> \[\*\*\*\]: Converted attributes for the optional attributes of the eIDAS minimum data set for natural persons.
-
-<a name="natural-person-identity-with-hsa-id"></a>
-### 2.6. Natural Person Identity with HSA-ID
-
+> \[\*\*\*\]: Converted attributes for the optional attributes of the eIDAS minimum data set for natural persons.
+
+<a name="natural-person-identity-with-hsa-id"></a>
+### 2.6. Natural Person Identity with HSA-ID
+
 Attribute set identifier: **DIGG-AP-HSAid-01**
 
 URI: `http://id.swedenconnect.se/ap/1.0/hsaid-01`
 
-The “Natural Person Identity with HSA-ID” attribute set provides basic personal identity information including a HSA-ID of the subject (see \[[SambiAttr](#sambiattr)\]).
+The “Natural Person Identity with HSA-ID” attribute set provides basic personal identity information including an HSA-ID of the subject (see \[[SambiAttr](#sambiattr)\]).
 
 | Attribute requirement | Attributes |
 | :--- | :--- |
-| **REQUIRED** | `sn` (Surname) <br /> `givenName` (Given name) <br /> `displayName` (Display name) <br /> `employeeHsaId` (HSA-ID) |
+| **REQUIRED** | `sn` (Surname) <br /> `givenName` (Given name) <br /> `displayName` (Display name) <br /> `employeeHsaId` (HSA-ID) |
 | **RECOMMENDED** | `dateOfBirth` (Date of birth) |
 
-**Typical use**: In an attribute release policy that provides basic user name information together with the person’s HSA-ID.

+**Typical use**: In an attribute release policy that provides basic username information together with the person’s HSA-ID.
+
 
 <a name="attribute-definitions"></a>
 ## 3. Attribute Definitions
@@ -321,7 +322,7 @@ The following attributes are defined for use within the attribute profile for th
 | givenName | urn:oid:2.5.4.42 | Given Name | Registered given name. | No | No | Valfrid |
 | displayName | urn:oid:2.16.840.1.<br/>113730.3.1.241 | Display Name | A name in any preferred presentation format. | No | No | Valfrid Lindeman |
 | gender | urn:oid:1.3.6.1.5.5.7.9.3 | Gender | A one letter representation (“M”/”F”/”U” or “m”/“f”/”u”) representing the subject’s gender, where “M” represents male, “F” represents female and “U” is used for unspecified, or unknown, gender. | No | No | M |
-| personalIdentity-<br/>Number | urn:oid:1.2.752.29.4.13 | National civic registration number/code | Swedish ”personnummer” or ”samordningsnummer” according to [SKV 704](#skv704) and [SKV 707](#skv707). 12 digits without hyphen. | No | No | 195006262546 |
+| personalIdentity-<br/>Number | urn:oid:1.2.752.29.4.13 | National civic registration number/code | Swedish ”personnummer” or ”samordningsnummer” according to [SKV 704](#skv704) and [SKV 707](#skv707). 12 digits without hyphen. | No | No | 195006262546 |
 | previousPersonal-<br/>IdentityNumber | urn:oid:1.2.752.201.3.15 | A user's previous national civic registration number, see [section 3.2.6](#the-previouspersonalidentitynumber-attribute) below. | See `personalIdentityNumber` above. | No | No | 197010632391 |
 | dateOfBirth | urn:oid:1.3.6.1.5.5.7.9.1 | Date of birth | Date of birth expressed using the format YYYY-MM-DD. | No | No | 1950-06-26 |
 | birthName | urn:oid:1.2.752.201.3.8 | Name at the time of birth | Full name of a person at birth. | No | No | Valfrid Danielsson |
@@ -349,36 +350,36 @@ The following attributes are defined for use within the attribute profile for th
 | signMessageDigest | urn:oid:1.2.752.201.3.14 | Sign message digest | Included in assertions as a proof that a user sign message was displayed. | No | No | See [section 3.2.4](#the-signmessagedigest-attribute) below. |
 | prid | urn:oid:1.2.752.201.3.4 | Provisional identifier | Unique identifier for an authentication performed against the eIDAS Framework. See [section 3.3.1](#the-prid-and-pridpersistence-attributes) below. | No | No | NO:5068907693 |
 | pridPersistence | urn:oid:1.2.752.201.3.5 | Provisional identifier persistence indicator | Indicator for the expected persistence of the prid attribute. See [section 3.3.1](#the-prid-and-pridpersistence-attributes) below. | No | No | A |
-| personalIdentity-<br/>NumberBinding | urn:oid:1.2.752.201.3.6 | National civic registration number/code binding URI | URI(s) identifying the binding process(es) performed of the `mappedPersonalIdentityNumber` attribute added by eIDAS connector. See [section 3.3.2](#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute) below. | No | No | `http://id.swedenconnect.se/`<br />`id-binding/process/populationregister` |
+| personalIdentity-<br/>NumberBinding | urn:oid:1.2.752.201.3.6 | National civic registration number/code binding URI | URI(s) identifying the binding process(es) performed of the `mappedPersonalIdentityNumber` attribute added by eIDAS connector. See [section 3.3.2](#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute) below. | No | No | `http://id.swedenconnect.se/`<br />`id-binding/process/populationregister` |
 | mappedPersonal-<br />IdentityNumber | urn:oid:1.2.752.201.3.16 | Mapped national civic registration number | A "mapped" personalIdentityNumber, see [section 3.3.2](#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute). | No | No | 195006262546 |
 | eidasPersonIdentifier | urn:oid:1.2.752.201.3.7 | eIDAS uniqueness identifier for natural persons | Maps the eIDAS PersonIdentifier attribute to a string attribute within the scope of the Swedish eID Framework attribute set. | No | No | ES/AT/02635542Y (Spanish eID number for an Austrian SP) |
-| eidasNatural-<br/>PersonAddress | urn:oid:1.2.752.201.3.9 | eIDAS Natural Person Address | Attribute for converting the eIDAS CurrentAddress attribute into an attribute having a string type value. | No | No | See [section 3.3.3.1](#conversion-of-eidas-currentaddress) below. |
-| employeeHsaId | urn:oid:1.2.752.29.6.2.1 | HSA-ID | Person identifier used by Swedish health care organizations. | No | No | See \[[SambiAttr](#sambiattr)\]. |
-
-> \[\*\]: The `mail` attribute should be regarded as a scoped attribute (see [3.1.3](#scoped-attributes) below) if the attribute release policy in use has stated it as scoped. Such a policy can for example be that the attribute is part of an attribute set (see [section 2](#attribute-sets)) that documents the attribute as scoped. In all other cases the attribute is regarded as non-scoped.
-
-<a name="attribute-string-values"></a>
-#### 3.1.1. Attribute String Values
+| eidasNatural-<br/>PersonAddress | urn:oid:1.2.752.201.3.9 | eIDAS Natural Person Address | Attribute for converting the eIDAS CurrentAddress attribute into an attribute having a string type value. | No | No | See [section 3.3.3.1](#conversion-of-eidas-currentaddress) below. |
+| employeeHsaId | urn:oid:1.2.752.29.6.2.1 | HSA-ID | Person identifier used by Swedish health care organizations. | No | No | See \[[SambiAttr](#sambiattr)\]. |
 
-All attributes, unless stated otherwise in this table, holds string values using the UTF-8 character set using the `xs:string` data type. Certain attributes such as `mail`, `personalIdentityNumber`, `organizationIdentifier`, `telephoneNumber` and `mobile` use a restricted character set according to its defined usage within this specification.
+> \[\*\]: The `mail` attribute should be regarded as a scoped attribute (see [3.1.3](#scoped-attributes) below) if the attribute release policy in use has stated it as scoped. Such a policy can for example be that the attribute is part of an attribute set (see [section 2](#attribute-sets)) that documents the attribute as scoped. In all other cases the attribute is regarded as non-scoped.
+
+<a name="attribute-string-values"></a>
+#### 3.1.1. Attribute String Values
+
+All attributes, unless stated otherwise in this table, hold string values using the UTF-8 character set using the `xs:string` data type. Certain attributes such as `mail`, `personalIdentityNumber`, `organizationIdentifier`, `telephoneNumber` and `mobile` use a restricted character set according to its defined usage within this specification.
 
 All attributes use the “caseIgnoreMatch” matching rule as defined by X.520 \[[X.520](#x520)\]. That is, case-insensitive comparison where insignificant spaces are ignored.
-
-<a name="multi-valued-attributes"></a>
-#### 3.1.2. Multi-valued Attributes
-
-Attributes with a “No” value in the column "Multi-valued" MUST NOT have more than one `<AttributeValue>` sub-element. Attributes with a “Yes” value in the column "Multi-valued" MAY have one or more `<AttributeValue>` sub-elements.
-
-<a name="scoped-attributes"></a>
-#### 3.1.3. Scoped Attributes
-
-Attributes with a "Yes" value in the column "Scoped" are scoped attributes. A scoped attribute expresses values in a string-valued attribute of the form `value@scope`, where `scope` takes the form of a domain name or something similar such as an organizational identifier.
-
-An Identity Provider wishing to release scoped attributes must register the scopes with the federation operator. After the federation operator has authorized the Identity Provider for the given scopes, they are declared in the Identity Provider's metadata entry. See section 2.1.3.1 of \[[EidDeployProf](#eiddeployprof)\] for details.	
-
-A Service Provider consuming a scoped attribute SHOULD assert that the issuing Identity Provider is authorized to issue attributes with the given scope by checking the Identity Provider's metadata entry as described in section 6.2.1 of \[[EidDeployProf](#eiddeployprof)\].
-
-**Note:** The `value` part of a scoped attribute MAY contain a `@`-character, for example when the value part is an email address, or a User Principal Name (UPN). Therefore, consumers of scoped attributes MUST use the last `@`-character as a delimiting character when splitting a scoped attribute into its `value` and `scope` parts.
+
+<a name="multi-valued-attributes"></a>
+#### 3.1.2. Multi-valued Attributes
+
+Attributes with a “No” value in the column "Multi-valued" MUST NOT have more than one `<AttributeValue>` sub-element. Attributes with a “Yes” value in the column "Multi-valued" MAY have one or more `<AttributeValue>` sub-elements.
+
+<a name="scoped-attributes"></a>
+#### 3.1.3. Scoped Attributes
+
+Attributes with a "Yes" value in the column "Scoped" are scoped attributes. A scoped attribute expresses values in a string-valued attribute of the form `value@scope`, where `scope` takes the form of a domain name or something similar such as an organizational identifier.
+
+An Identity Provider wishing to release scoped attributes must register the scopes with the federation operator. After the federation operator has authorized the Identity Provider for the given scopes, they are declared in the Identity Provider's metadata entry. See section 2.1.3.1 of \[[SC.SAML.Profile](#sc-saml-profile)\] for details.	
+
+A Service Provider consuming a scoped attribute SHOULD assert that the issuing Identity Provider is authorized to issue attributes with the given scope by checking the Identity Provider's metadata entry as described in section 6.2.1 of \[[SC.SAML.Profile](#sc-saml-profile)\].
+
+**Note:** The `value` part of a scoped attribute MAY contain a `@`-character, for example when the value part is an email address, or a User Principal Name (UPN). Therefore, consumers of scoped attributes MUST use the last `@`-character as a delimiting character when splitting a scoped attribute into its `value` and `scope` parts.
 
 <a name="saml-attribute-format"></a>
 ### 3.2. SAML Attribute Format
@@ -435,7 +436,7 @@ process.
 
 The `authServerSignature` may be included in assertions in cases where there are requirements to include a digitally signed proof from the authentication server at which the end user authenticated. This is mainly useful in cases where the SAML Identity Provider delegates end user authentication to a subordinate authentication server.
 
-> \[*\]: Note that an authentication process, may be “authentication for signature” as specified in section 7 of \[[EidDeployProf](#eiddeployprof)\].
+> \[*\]: Note that an authentication process, may be “authentication for signature” as specified in section 7 of \[[SC.SAML.Profile](#sc-saml-profile)\].
 
 <a name="the-sad-attribute"></a>
 #### 3.2.3. The sad Attribute
@@ -444,7 +445,7 @@ The `sad` attribute holds Signature Activation Data that is required by a
 signature service in order to service a signature request in accordance
 with CEN EN 419 241-2. The `sad` attribute holds a single string
 attribute value. The format of the string value is defined in the "Signature Activation Protocol 
-for Federated Signing" specification \[[SigSAP](#sigsap)\].
+for Federated Signing" specification \[[SC.SAP](#sc-sap)\].
 
 <a name="the-signmessagedigest-attribute"></a>
 #### 3.2.4. The signMessageDigest Attribute
@@ -452,15 +453,15 @@ for Federated Signing" specification \[[SigSAP](#sigsap)\].
 The `signMessageDigest` attribute is included in an assertion as a proof that an Identity Provider displayed
 a sign message for the user and that the user actively confirmed acceptance of this sign message. This sign 
 message is the `SignMessage` extension that may be included in an authentication request by Signature Service 
-Service Providers. See section 7 of \[[EidDeployProf](#eiddeployprof)\] for details.
+SP:s. See section 7 of \[[SC.SAML.Profile](#sc-saml-profile)\] for details.
 
 The attribute value format for the `signMessageDigest` attribute is `digest-algorithm-identifier;sign-message-digest`, where
 `digest-algorithm-identifier` is the XML Security algorithm URI identifier of the selected digest algorithm and
-`sign-message-digest` is `base64(digest(msg))`. The `msg` is the UTF-8 encoded bytes of the sign message that was displayed. It equals the `csig:Message` element value of the `csig:SignMessage` (\[[DSSExt](#dssext)\]). Thus, if the `csig:Message` element is encrypted into a `csig:EncryptedMessage`, the element value after decryption should be used.
+`sign-message-digest` is `base64(digest(msg))`. The `msg` is the UTF-8 encoded bytes of the sign message that was displayed. It equals the `csig:Message` element value of the `csig:SignMessage` (\[[SC.DSS.Ext](#dssext)\]). Thus, if the `csig:Message` element is encrypted into a `csig:EncryptedMessage`, the element value after decryption should be used.
 
 Entities compliant with this specification MUST use `http://www.w3.org/2001/04/xmlenc#sha256` as the digest algorithm, 
 unless the recipient of the `signMessageDigest` attribute has declared another digest algorithm as preferred in its
-metadata entry (see section 2.1.1.3 of [[EidDeployProf](#eiddeployprof)\]). In those cases this algorithm MAY be used.
+metadata entry (see section 2.1.1.3 of [[SC.SAML.Profile](#sc-saml-profile)\]). In those cases this algorithm MAY be used.
 
 **Example:**
 
@@ -486,43 +487,43 @@ The `signMessageDigest` attribute for the above example will then be:
   </saml2:AttributeValue>
 </saml2:Attribute>
 ```
-
-<a name="the-orgaffiliation-attribute"></a>
-#### 3.2.5. The orgAffiliation Attribute
-
-The `orgAffiliation` attribute is intended to be used as a primary identity attribute for personal organizational identities. It consists of a personal identifier **and** an organizational identifier code (`organizationIdentifier`). 
-
-This specification does not impose any specific requirements concerning the personal identifier part of the attribute other than that it MUST be unique for the given organization.
-
-**Note**: In the general case, an attribute consumer MUST NOT assume a particular format or meaning of the personal identifier part since different organizations may use different formats. An attribute consumer should also be aware that a personal identifier separated from its organizational identifier code can not be regarded as unique. 
-
-**Note**: The `orgAffiliation` is a [scoped attribute](#scoped-attributes) meaning that producing and consuming such an attribute MUST follow the rules given in sections 2.1.3.1 and 6.2.1 of \[[EidDeployProf](#eiddeployprof)\].
-
-<a name="the-previouspersonalidentitynumber-attribute"></a>
-#### 3.2.6. The previousPersonalIdentityNumber Attribute
-
-The `personalIdentityNumber` attribute can contain a Swedish personal identity number (personnummer), \[[SKV704](#skv704)\], or a Swedish coordination number (samordningsnummer), \[[SKV707](#skv707)\]. All individuals born in Sweden or moving to Sweden with the intention 
-of staying one year or longer is assigned a personal identity number and registered in the
-population register. A coordination number may be assigned to a person that is not registered, 
-but has the need to communicate with various government authorities, healthcare institutions,
-higher education and banks.
-
-In some cases a person may hold a coordination number during a period before he or she is
-assigned a personal identity number. A typical use case is a person that seeks asylum and
-later is given a residence permit. In this case the person first may hold a coordination number
-and if a residence permit is given a personal identity number will be assigned.
-
-For a service provider this may lead to problems since the primary identifier for a person
-has changed. A login with the newly assigned identifier will not match the user account
-previously used by this individual.
-
-This profile defines the `previousPersonalIdentityNumber` attribute to enable matching a
-previously held identity number to a newly assigned identity number. The `previousPersonalIdentityNumber` attribute is typically released together with the "new" 
-`personalIdentityNumber` attribute in order to facilitate account matching at a service provider.
-
-This attribute is not part of any attribute sets defined in the profile. Attribute consumers
-wishing to receive the attribute should declare the these requirement in their metadata entries
-(using a `<md:RequestedAttribute>` element).
+
+<a name="the-orgaffiliation-attribute"></a>
+#### 3.2.5. The orgAffiliation Attribute
+
+The `orgAffiliation` attribute is intended to be used as a primary identity attribute for personal organizational identities. It consists of a personal identifier **and** an organizational identifier code (`organizationIdentifier`). 
+
+This specification does not impose any specific requirements concerning the personal identifier part of the attribute other than that it MUST be unique for the given organization.
+
+**Note**: In the general case, an attribute consumer MUST NOT assume a particular format or meaning of the personal identifier part since different organizations may use different formats. An attribute consumer should also be aware that a personal identifier separated from its organizational identifier code can not be regarded as unique. 
+
+**Note**: The `orgAffiliation` is a [scoped attribute](#scoped-attributes) meaning that producing and consuming such an attribute MUST follow the rules given in sections 2.1.3.1 and 6.2.1 of \[[SC.SAML.Profile](#sc-saml-profile)\].
+
+<a name="the-previouspersonalidentitynumber-attribute"></a>
+#### 3.2.6. The previousPersonalIdentityNumber Attribute
+
+The `personalIdentityNumber` attribute can contain a Swedish personal identity number (personnummer), \[[SKV704](#skv704)\], or a Swedish coordination number (samordningsnummer), \[[SKV707](#skv707)\]. All individuals born in Sweden or moving to Sweden with the intention 
+of staying one year or longer is assigned a personal identity number and registered in the
+population register. A coordination number may be assigned to a person that is not registered, 
+but has the need to communicate with various government authorities, healthcare institutions,
+higher education and banks.
+
+In some cases a person may hold a coordination number during a period before he or she is
+assigned a personal identity number. A typical use case is a person that seeks asylum and
+later is given a residence permit. In this case the person first may hold a coordination number
+and if a residence permit is given a personal identity number will be assigned.
+
+For a service provider this may lead to problems since the primary identifier for a person
+has changed. A login with the newly assigned identifier will not match the user account
+previously used by this individual.
+
+This profile defines the `previousPersonalIdentityNumber` attribute to enable matching a
+previously held identity number to a newly assigned identity number. The `previousPersonalIdentityNumber` attribute is typically released together with the "new" 
+`personalIdentityNumber` attribute in order to facilitate account matching at a service provider.
+
+This attribute is not part of any attribute sets defined in the profile. Attribute consumers
+wishing to receive the attribute should declare the these requirement in their metadata entries
+(using a `<md:RequestedAttribute>` element).
 
 <a name="attributes-for-the-eidas-framework"></a>
 ### 3.3. Attributes for the eIDAS Framework
@@ -533,7 +534,7 @@ wishing to receive the attribute should declare the these requirement in their m
 Assertions (with attribute statements) issued from a member state eIDAS
 node contain a set of attributes identifying the authenticated subject.
 Attributes obtained from other conformant eIDAS nodes will provide an
-eIDAS unique identifier but it can not be ruled out that the Swedish
+eIDAS unique identifier, but it can not be ruled out that the Swedish
 eIDAS node may be adopted to accept authentication from non eIDAS
 compliant nodes, such as when accepting authentication from countries
 outside of EU such as the USA.
@@ -547,7 +548,7 @@ the user in a common format regardless of the composition of the
 original attributes received from the authenticating source. The `prid`
 attribute value is not stored in any registry, but derived from the
 received attributes at each authentication instant according to defined
-algorithms specified in \[[ConstructedAttr](#constructedattr)\]. The algorithm ensures that
+algorithms specified in \[[SC.Constructed](#sc-constructed)\]. The algorithm ensures that
 each `prid` is unique for each authenticated entity, but does not ensure
 persistence. If the attributes received for an entity changes over time,
 the `prid` attribute may also change dependent on the defined `prid`
@@ -565,31 +566,35 @@ This may assist users with low persistence expectancy to regain control
 of their user account, should their `prid` change in the future.
 
 The specification “eIDAS Constructed Attributes Specification for the
-Swedish eID Framework”, \[[ConstructedAttr](#constructedattr)\], declares the details for
+Swedish eID Framework”, \[[SC.Constructed](#sc-constructed)\], declares the details for
 how the `prid` and `pridPersistence` attributes are generated and how they
 should be processed.
 
 <a name="the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute"></a>
 #### 3.3.2. The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes
-
-When an authentication for a natural person is performed against the
eIDAS Framework, the Swedish eIDAS connector will query the Identity Binding Service
-for a binding between the attributes found in the assertion received from the foreign
-eIDAS-node and a Swedish personal identity number.  If such a mapping exists, and the user consents to it being used, the assertion will be extended with a `mappedPersonalIdentityNumber` attribute holding the "mapped" Swedish civic registration number ("personnummer" or "samordningsnummer").

This mapping, or binding, can be performed using a number of different processes,
each identified by a URI. Therefore, if the eIDAS connector extends an assertion with a 
-`mappedPersonalIdentityNumber` attribute, it MUST also include the `personalIdentityNumberBinding` attribute. This attribute contains a semicolon separated list of URI:s that identify the binding process applied to obtain the binding. See \[[ID-Binding](#id-binding)\] for the possible values.
-
-If these bindings are acceptable for a Service Provider processing an assertion (containing the `mappedPersonalIdentityNumber` attribute), the Service Provider MAY treat the contents of the `mappedPersonalIdentityNumber` attribute as it would have received the `personalIdentityNumber` attribute, otherwise the Service Provider SHOULD NOT use the identity found in the `mappedPersonalIdentityNumber` attribute to login the user.
-
-> **Note**: The reason that an ordinary `personalIdentityNumber` attribute is not
-used to represent a mapped civic registration number is that it is essential that
-the consuming entity always verifies that the binding process under which the 
-mapping was performed is acceptable, before proceeding with the authentication 
+
+When an authentication for a natural person is performed against the
+eIDAS Framework, the Swedish eIDAS connector will query the Identity Binding Service
+for a binding between the attributes found in the assertion received from the foreign
+eIDAS-node and a Swedish personal identity number.  If such a mapping exists, and the user consents to it being used, the assertion will be extended with a `mappedPersonalIdentityNumber` attribute holding the "mapped" Swedish civic registration number ("personnummer" or "samordningsnummer").
+
+This mapping, or binding, can be performed using a number of different processes,
+each identified by a URI. Therefore, if the eIDAS connector extends an assertion with a 
+`mappedPersonalIdentityNumber` attribute, it MUST also include the `personalIdentityNumberBinding` attribute. This attribute contains a semicolon separated list of URI:s that identify the binding process applied to obtain the binding. See \[[ID-Binding](#id-binding)\] for the possible values.
+
+If these bindings are acceptable for a Service Provider processing an assertion (containing the `mappedPersonalIdentityNumber` attribute), the Service Provider MAY treat the contents of the `mappedPersonalIdentityNumber` attribute as it would have received the `personalIdentityNumber` attribute, otherwise the Service Provider SHOULD NOT use the identity found in the `mappedPersonalIdentityNumber` attribute to log in the user.
+
+> **Note**: The reason that an ordinary `personalIdentityNumber` attribute is not
+used to represent a mapped civic registration number is that it is essential that
+the consuming entity always verifies that the binding process under which the 
+mapping was performed is acceptable, before proceeding with the authentication 
 process.
 
 <a name="conversion-of-eidas-attributes"></a>
 #### 3.3.3. Conversion of eIDAS Attributes
 
-The attributes specified within eIDAS (\[[eIDAS\_Attr](#eidas-attr)\]) does not use
-simple string type values. Instead each attribute is represented using
+The attributes specified within eIDAS (\[[eIDAS.Attributes](#eidas-attr)\]) does not use
+simple string type values, instead each attribute is represented using
 its own dedicated XML data type. This affects interoperability in a
 negative way since most standard SAML software need to be modified to
 support these attributes. Therefore, the Swedish eID Framework defines
@@ -609,16 +614,16 @@ Swedish eID Framework.
 | BirthName <br /> `http://eidas.europa.eu/attributes/naturalperson/BirthName` | birthName <br /> urn:oid:1.2.752.201.3.8 |
 | PlaceOfBirth <br /> `http://eidas.europa.eu/attributes/naturalperson/PlaceOfBirth` | placeOfBirth <br /> urn:oid:1.3.6.1.5.5.7.9.2 |
 | CurrentAddress <br /> `http://eidas.europa.eu/attributes/naturalperson/CurrentAddress` | eidasNaturalPersonAddress <br /> urn:oid:1.2.752.201.3.9 <br /> See [section 3.3.3.1](#conversion-of-eidas-currentaddress) below. |
-| Gender <br /> `http://eidas.europa.eu/attributes/naturalperson/Gender` | gender <br /> urn:oid:1.3.6.1.5.5.7.9.3 |
-| Nationality<br />`http://eidas.europa.eu/attributes/naturalperson/Nationality` | countryOfCitizenship<br />urn:oid:1.3.6.1.5.5.7.9.4 |
-| CountryOfBirth<br />`http://eidas.europa.eu/attributes/naturalperson/CountryOfBirth` | Will be added as the last element of placeOfBirth (see above) |
-| TownOfBirth<br />`http://eidas.europa.eu/attributes/naturalperson/TownOfBirth` | Ignored if the eIDAS attribute PlaceOfBirth is assigned. Otherwise placed as first element of placeOfBirth. |
-| CountryOfResidence<br />`http://eidas.europa.eu/attributes/naturalperson/CountryOfResidence` | countryOfResidence<br />urn:oid:1.3.6.1.5.5.7.9.5 |
-| PhoneNumber<br />`http://eidas.europa.eu/attributes/naturalperson/PhoneNumber` | telephoneNumber<br />urn:oid:2.5.4.20 |
+| Gender <br /> `http://eidas.europa.eu/attributes/naturalperson/Gender` | gender <br /> urn:oid:1.3.6.1.5.5.7.9.3 |
+| Nationality<br />`http://eidas.europa.eu/attributes/naturalperson/Nationality` | countryOfCitizenship<br />urn:oid:1.3.6.1.5.5.7.9.4 |
+| CountryOfBirth<br />`http://eidas.europa.eu/attributes/naturalperson/CountryOfBirth` | Will be added as the last element of placeOfBirth (see above) |
+| TownOfBirth<br />`http://eidas.europa.eu/attributes/naturalperson/TownOfBirth` | Ignored if the eIDAS attribute PlaceOfBirth is assigned. Otherwise placed as first element of placeOfBirth. |
+| CountryOfResidence<br />`http://eidas.europa.eu/attributes/naturalperson/CountryOfResidence` | countryOfResidence<br />urn:oid:1.3.6.1.5.5.7.9.5 |
+| PhoneNumber<br />`http://eidas.europa.eu/attributes/naturalperson/PhoneNumber` | telephoneNumber<br />urn:oid:2.5.4.20 |
 | EmailAddress<br />`http://eidas.europa.eu/attributes/naturalperson/EmailAddress` | mail<br />urn:oid:0.9.2342.19200300.100.1.3 |
 
 **Note**: When converting an eIDAS attribute that makes use of
-“transliteration” (as described in section 2.4 of \[[eIDAS\_Attr](#eidas-attr)\])
+“transliteration” (as described in section 2.4 of \[[eIDAS.Attributes](#eidas-attr)\])
 attribute values having the `LatinScript` attribute set to `false` will not
 be part of the resulting attribute.
 
@@ -626,7 +631,7 @@ be part of the resulting attribute.
 ##### 3.3.3.1. Conversion of eIDAS CurrentAddress
 
 The eIDAS attribute `CurrentAddress` is defined in section 2.2.9 of
-\[[eIDAS\_Attr](#eidas-attr)\]. Its value is a Base64-encoding of an XML-structure of
+\[[eIDAS.Attributes](#eidas-attr)\]. Its value is a Base64-encoding of an XML-structure of
 the type CurrentAddressStructuredType.
 
     <xsd:complexType name="CurrentAddressStructuredType">
@@ -707,10 +712,10 @@ following attribute:
 **\[SAML2Core\]**
 > [OASIS Standard, Assertions and Protocols for the OASIS Security
 > Assertion Markup Language (SAML) V2.0, March
-> 2005](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
-
-<a name="saml2subjattr"></a>
-**\[SAML2SubjAttr\]**
+> 2005](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
+
+<a name="saml2subjattr"></a>
+**\[SAML2SubjAttr\]**
 > [OASIS Standard, SAML V2.0 Subject Identifier Attributes Profile Version 1.0, January 2019](https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf).
 
 <a name="skv704"></a>
@@ -725,11 +730,11 @@ following attribute:
 
 <a name="skv709"></a>
 **\[SKV709\]**
-> [Skatteverket, SKV 709, Utgåva 8, Organisationsnummer](https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf).
-
-<a name="id-binding"></a>
-**\[ID-Binding\]**
-> [Binding of eIDAS Attributes to Swedish Personal Identity Numbers](https://docs.swedenconnect.se/technical-framework/Identity_Binding.html)
+> [Skatteverket, SKV 709, Utgåva 8, Organisationsnummer](https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf).
+
+<a name="id-binding"></a>
+**\[ID-Binding\]**
+> [Binding eIDAS Identities to Records in the Swedish Population Register](https://docs.swedenconnect.se/technical-framework/Identity_Binding.html)
 
 <a name="x520"></a>
 **\[X.520\]**
@@ -749,64 +754,60 @@ following attribute:
 <a name="iso3166"></a>
 **\[ISO3166\]**
 > Codes for the representation of names of countries and their
-> subdivisions Part 1: Country codes, ISO standard, ISO 3166-1.
-
-<a name="sambiattr"></a>
-**\[SambiAttr\]**
-> [Sambi Attributspecifikation](https://wiki.federationer.internetstiftelsen.se/pages/viewpage.action?pageId=46465316).
-
-<a name="tillitramv"></a>
-**\[TillitRamv\]**
-> [Tillitsramverket för Svensk e-legitimation](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation).
-
-<a name="eiddeployprof"></a>
-**\[EidDeployProf\]**
+> subdivisions Part 1: Country codes, ISO standard, ISO 3166-1.
+
+<a name="sambiattr"></a>
+**\[SambiAttr\]**
+> [Sambi Attributspecifikation](https://wiki.federationer.internetstiftelsen.se/pages/viewpage.action?pageId=46465316).
+
+<a name="sc-saml-profile"></a>
+**\[SC.SAML.Profile\]**
 > [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
 
-<a name="constructedattr"></a>
-**\[ConstructedAttr\]**
+<a name="sc-constructed"></a>
+**\[SC.Constructed\]**
 > [eIDAS Constructed Attributes Specification for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html).
 
 <a name="eidas-attr"></a>
-**\[eIDAS\_Attr\]**
-> [eIDAS SAML Attribute Profile, version 1.2, 21 May 2019](https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.2-FINAL.pdf).
+**\[eIDAS.Attributes\]**
+> [eIDAS SAML Attribute Profile, version 1.4, 31 October 2023](https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.4_final.pdf).
 
-<a name="sigsap"></a>
-**\[SigSAP\]**
+<a name="sc-sap"></a>
+**\[SC.SAP\]**
 > [Signature Activation Protocol for Federated Signing](https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html).
 
 <a name="dssext"></a>
-**\[DSSExt\]**
+**\[SC.DSS.Ext\]**
 > [DSS Extension for Federated Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html).
 
 <a name="changes-between-versions"></a>
 ## 5. Changes between versions
-
-**Changes between version 1.7 and version 1.8:**
-
-- In section 3.1.3, "Scoped Attributes", a note about `@`-characters in scoped values was added.
-
-- Updated link to Sambi attribute specification.
-
-- Section 3.3.2, "The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes", was updated.
-
-- Section 3.3.3, "Conversion of eIDAS Attributes", was extended to contain mappings for the optional eIDAS attributes: Nationality, CountryOfBirth, TownOfBirth, CountryOfResidence, PhoneNumber and EmailAddress.
-
-**Changes between version 1.6 and version 1.7:**
-
-- Section 2.4, "Organizational Identity for Natural Persons", was updated to define a minimum set of attributes for providing personal orgazational identity information.
-
-- Section 3.2.5, "The orgAffiliation Attribute", was introduced.
-
-- The concept of "scoped attributes" was introduced, see section 3.1.3.
-
-- The `previousPersonalIdentityNumber` attribute was added, see section 3.2.6.
-
-- The `mappedPersonalIdentityNumber` attribute was added (see section 3.3.2), and the
-  attribute set "eIDAS Natural Person Attribute Set" (section 2.5) was changed so that
-  a `mappedPersonalIdentityNumber` attribute is delivered instead of a 
-  `personalIdentityNumber` attribute if the eIDAS identity can be mapped to a Swedish 
-  identity number.
+
+**Changes between version 1.7 and version 1.8:**
+
+- In section 3.1.3, "Scoped Attributes", a note about `@`-characters in scoped values was added.
+
+- Updated link to Sambi attribute specification.
+
+- Section 3.3.2, "The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes", was updated.
+
+- Section 3.3.3, "Conversion of eIDAS Attributes", was extended to contain mappings for the optional eIDAS attributes: Nationality, CountryOfBirth, TownOfBirth, CountryOfResidence, PhoneNumber and EmailAddress.
+
+**Changes between version 1.6 and version 1.7:**
+
+- Section 2.4, "Organizational Identity for Natural Persons", was updated to define a minimum set of attributes for providing personal orgazational identity information.
+
+- Section 3.2.5, "The orgAffiliation Attribute", was introduced.
+
+- The concept of "scoped attributes" was introduced, see section 3.1.3.
+
+- The `previousPersonalIdentityNumber` attribute was added, see section 3.2.6.
+
+- The `mappedPersonalIdentityNumber` attribute was added (see section 3.3.2), and the
+  attribute set "eIDAS Natural Person Attribute Set" (section 2.5) was changed so that
+  a `mappedPersonalIdentityNumber` attribute is delivered instead of a 
+  `personalIdentityNumber` attribute if the eIDAS identity can be mapped to a Swedish 
+  identity number.
 
 **Changes between version 1.5 and version 1.6:**
 
@@ -814,9 +815,9 @@ following attribute:
 
 - Section 2.5, "eIDAS Natural Person Attribute Set", was updated so that the `c` (country) attribute is a required attribute for this attribute set.
 
-- The attribute `signMessageDigest` was introduced (see section 3.2.4).
-
-- The HSA-ID attribute was specified.
+- The attribute `signMessageDigest` was introduced (see section 3.2.4).
+
+- The HSA-ID attribute was specified.
 
 **Changes between version 1.4 and version 1.5:**
 
@@ -845,7 +846,7 @@ following attribute:
 **Changes between version 1.2 and version 1.3:**
 
 -   This specification no longer uses the term “attribute profile” for
-    named collections of attributes for different scenarios. Instead the
+    named collections of attributes for different scenarios, instead the
     term “attribute set” is used.
 
 -   Definitions of attribute sets (profiles) have been changed to be
@@ -885,4 +886,3 @@ following attribute:
 -   In chapter 3.4, “Organizational Identity for Natural Persons”, some
     attributes were listed as both prohibited and allowed. This has been
     fixed.
-
diff --git a/06 - Entity Categories for the Swedish eID Framework.md b/06 - Entity Categories for the Swedish eID Framework.md
index cc88561..c6c5e65 100644
--- a/06 - Entity Categories for the Swedish eID Framework.md	
+++ b/06 - Entity Categories for the Swedish eID Framework.md	
@@ -8,7 +8,7 @@
 
 # Entity Categories for the Swedish eID Framework
 
-### Version 1.9 - 2024-12-04 - *Draft version*
+### Version 1.9 - 2024-12-04
 
 
 Registration number: **2019-311**
@@ -144,7 +144,7 @@ Five types of Entity Categories are used within the federation:
 <a name="requirements-notation"></a>
 ### 1.1. Requirements Notation
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in \[[RFC2119](#rfc2119)\].
 
@@ -225,7 +225,7 @@ a plausible choice, if and only if, the following conditions apply;
 -   if the Identity Provider declares at least one Service Contract identifier,
     the Service Provider must declare at least one of declared identifiers, and,
 
--   all of the Service Property identifiers declared by the Service
+-   all the Service Property identifiers declared by the Service
     Provider must be declared by the Identity Provider.
 
 <a name="representation-of-entity-categories-in-metadata"></a>
@@ -270,7 +270,7 @@ may define additional categories.
 All service entity category identifiers are prefixed with
 `http://id.elegnamnden.se/ec` or `http://id.swedenconnect.se/ec` (defined after Aug. 2018).
 
-A service entity category identifies an arbitrary set of requirements and conditions that is required by the consuming service and provided by the providing service. Each service entity category specifies its own set of requirements and conditions. Typically such requirements and conditions include requirements on level of assurance (LoA) and requirements on mandatory attributes. For contract- or business agreement requirements [Service Contract Categories](#service-contract-categories) should be used.
+A service entity category identifies an arbitrary set of requirements and conditions that is required by the consuming service and provided by the providing service. Each service entity category specifies its own set of requirements and conditions. Typically, such requirements and conditions include requirements on level of assurance (LoA) and requirements on mandatory attributes. For contract or business agreement requirements [Service Contract Categories](#service-contract-categories) should be used.
 
 A providing service declaring a service entity category that consists of both a level of assurance requirement and an attribute set MUST guarantee that the release of the given attributes are consistent with the level of assurance requirement.
 
@@ -284,7 +284,7 @@ This specification does not impose any other limitations on what requirements or
 This section define Service Entity Categories that has attribute requirements 
 according to the "Natural Personal Identity with Civic Registration Number" 
 (`http://id.elegnamnden.se/ap/1.0/pnr-01`) attribute set as defined in section 2.3 
-of \[[EidAttributes](#eidattributes)\].
+of \[[SC.SAML.Attrs](#sc-saml-attrs)\].
 
 **Note**: The `http://id.elegnamnden.se/ap/1.0/pnr-01` attribute set includes the `personalIdentityNumber` attribute. See section [6.2](#accepts-coordination-number), "[accepts-coordination-number](#accepts-coordination-number)", for specific requirements concerning delivering a coordination number in this attribute. 
 
@@ -293,10 +293,10 @@ of \[[EidAttributes](#eidattributes)\].
 
 **URL**: `http://id.elegnamnden.se/ec/1.0/loa2-pnr`
 
-**Description**: User authentication according to assurance level 2 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
+**Description**: User authentication according to assurance level 2 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa2`
-> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/pnr-01`
 
@@ -305,10 +305,10 @@ of \[[EidAttributes](#eidattributes)\].
 
 **URL**: `http://id.elegnamnden.se/ec/1.0/loa3-pnr`
 
-**Description**: User authentication according to assurance level 3 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
+**Description**: User authentication according to assurance level 3 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa3`
-> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/pnr-01`
 
@@ -317,7 +317,7 @@ of \[[EidAttributes](#eidattributes)\].
 
 **URL**: `http://id.elegnamnden.se/ec/1.0/loa4-pnr`
 
-**Description**: User authentication according to assurance level 4 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
+**Description**: User authentication according to assurance level 4 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa4`
 
@@ -335,7 +335,7 @@ Attribute release is based on the "Natural Personal Identity with Civic Registra
 It is the responsibility of the Swedish eIDAS Proxy Service to transform these attributes into eIDAS attributes.
 
 **LoA-identifier**: Not applicable
-> An Identity Provider delivering assertions to the eIDAS framework is obliged to announce which levels that it supports by including the corresponding eIDAS authentication context URIs defined in section 3.1.1 of \[[SC.Registry](#sc-registry)\] as assurance certification attributes in its metadata as described in section 2.1.3 of \[[EidDeploy](#eiddeploy)\].
+> An Identity Provider delivering assertions to the eIDAS framework is obliged to announce which levels that it supports by including the corresponding eIDAS authentication context URIs defined in section 3.1.1 of \[[SC.Registry](#sc-registry)\] as assurance certification attributes in its metadata as described in section 2.1.3 of \[[SC.SAML.Profile](#sc-saml-profile)\].
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/pnr-01` where the `dateOfBirth` attribute (`urn:oid:1.3.6.1.5.5.7.9.1`) is mandatory.
 
@@ -347,7 +347,7 @@ It is the responsibility of the Swedish eIDAS Proxy Service to transform these a
 
 **URL**: `http://id.elegnamnden.se/ec/1.0/eidas-naturalperson`
 
-**Description**: User authentication according to any of the eIDAS assurance levels and attribute release according to “eIDAS Natural Person Attribute Set” (see section 2.5 of \[[EidAttributes](#eidattributes)\]).
+**Description**: User authentication according to any of the eIDAS assurance levels and attribute release according to “eIDAS Natural Person Attribute Set” (see section 2.5 of \[[SC.SAML.Attrs](#sc-saml-attrs)\]).
 
 **LoA-identifier**:   Not applicable
 > It does not make sense to specify the level of assurance for a Service
@@ -364,17 +364,17 @@ It is the responsibility of the Swedish eIDAS Proxy Service to transform these a
 This section define Service Entity Categories that has attribute requirements 
 according to the "Organizational Identity for Natural Persons" 
 (`http://id.elegnamnden.se/ap/1.0/org-person-01`) attribute set as defined in section 2.4 
-of \[[EidAttributes](#eidattributes)\].
+of \[[SC.SAML.Attrs](#sc-saml-attrs)\].
 
 <a name="loa2-orgid"></a>
 #### 2.3.1. loa2-orgid
 
 **URL**: `http://id.swedenconnect.se/ec/1.0/loa2-orgid`
 
-**Description**: User authentication according to assurance level 2 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
+**Description**: User authentication according to assurance level 2 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa2`
-> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/org-person-01`
 
@@ -383,10 +383,10 @@ of \[[EidAttributes](#eidattributes)\].
 
 **URL**: `http://id.swedenconnect.se/ec/1.0/loa3-orgid`
 
-**Description**: User authentication according to assurance level 3 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
+**Description**: User authentication according to assurance level 3 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa3`
-> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/org-person-01`
 
@@ -395,10 +395,10 @@ of \[[EidAttributes](#eidattributes)\].
 
 **URL**: `http://id.swedenconnect.se/ec/1.0/loa4-orgid`
 
-**Description**: User authentication according to assurance level 4 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
+**Description**: User authentication according to assurance level 4 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa4`
-> Or a corresponding LoA 4 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 4 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/org-person-01`
 
@@ -408,39 +408,45 @@ of \[[EidAttributes](#eidattributes)\].
 This section define Service Entity Categories that has attribute requirements 
 according to the "Natural Personal Identity without Civic Registration Number" 
 (`http://id.elegnamnden.se/ap/1.0/natural-person-01`) attribute set as defined in section 2.2 
-of \[[EidAttributes](#eidattributes)\].
+of \[[SC.SAML.Attrs](#sc-saml-attrs)\].
 
 <a name="loa2-name"></a>
 ### 2.4.1. loa2-name
 
-**URL**: `http://id.swedenconnect.se/ec/1.0/loa2-name`

**Description**: User authentication according to assurance level 2 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
+**URL**: `http://id.swedenconnect.se/ec/1.0/loa2-name`
+
+**Description**: User authentication according to assurance level 2 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa2`
-> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 2 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
-**Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/natural-person-01`
+**Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/natural-person-01`
 
 <a name="loa3-name"></a>
 ### 2.4.2. loa3-name
 
-**URL**: `http://id.swedenconnect.se/ec/1.0/loa3-name`

**Description**: User authentication according to assurance level 3 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
+**URL**: `http://id.swedenconnect.se/ec/1.0/loa3-name`
+
+**Description**: User authentication according to assurance level 3 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa3`
-> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 3 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
-**Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/natural-person-01`
+**Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/natural-person-01`
 
 <a name="loa4-name"></a>
 ### 2.4.3. loa4-name
 
-**URL**: `http://id.swedenconnect.se/ec/1.0/loa4-name`

**Description**: User authentication according to assurance level 4 \[[EidTillit](#eidtillit)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
+**URL**: `http://id.swedenconnect.se/ec/1.0/loa4-name`
+
+**Description**: User authentication according to assurance level 4 \[[SE.Trust](#se-trust)\] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.
 
 **LoA-identifier**: `http://id.elegnamnden.se/loa/1.0/loa4`
-> Or a corresponding LoA 4 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\].
+> Or a corresponding LoA 4 URI (see section 3.1.1 of \[[SC.Registry](#sc-registry)\]).
 
 **Attribute requirements**: `http://id.elegnamnden.se/ap/1.0/natural-person-01`
 
-
+
 <a name="definitions-for-service-property-categories"></a>
 ## 3. Definitions for Service Property Categories
 
@@ -480,7 +486,7 @@ authentication using mobile devices.
 
 **URL**: `http://id.elegnamnden.se/sprop/1.0/scal2`
 
-**Description**: A service property declaring that the service is adapted to support Sole Control Assurance Level 2 (SCAL2) in accordance with \[[SigSAP](#sigsap)\]. 
+**Description**: A service property declaring that the service is adapted to support Sole Control Assurance Level 2 (SCAL2) in accordance with \[[SC.SAP](#sc-sap)\]. 
 
 For a providing service, i.e. an Identity Provider, inclusion of the
 scal2 service property states that the Identity Provider will return a "SAD" in response to a `SADRequest` in an authentication requests from a signing service.
@@ -527,7 +533,7 @@ Service Contract Entity Category identifiers are indented for performing service
 
 All Service Contract identifiers are prefixed with `http://id.swedenconnect.se/contract/<org>`, where `org` is identifier for the defining organization.
 
-The meaning of different contracts and business agreements are out of scope for this specification. Instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.
+The meaning of different contracts and business agreements are out of scope for this specification, instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.
 
 
 <a name="general-entity-categories"></a>
@@ -557,7 +563,7 @@ person who opens, and performs the authentication in the app.
 
 In order to prevent attacks of this type many authentication schemes offer alternative ways
 of initiating authentication (or signature) sessions, where some sort of binding between the
-user agent and the authentication device is performed. An good example of this is when 
+user agent and the authentication device is performed. A good example of this is when 
 Identity Providers prompt the user to scan a QR-code displayed in the web browser using the 
 authentication app instead of prompting for the user identity. This effectively binds the
 user agent to the same physical location as the authentication device, and in practice
@@ -583,7 +589,7 @@ from Service Providers that have declared this entity category in their metadata
 **Description**: A special purpose entity category that is declared by Service Providers
 to announce that they accept a Swedish coordination number (samordningsnummer), \[[SKV707](#skv707)\], being delivered in the `personalIdentityNumber` (`urn:oid:1.2.752.29.4.13`) attribute.
 
-The `personalIdentityNumber` is defined in section 3.1 of \[[EidAttributes](#eidattributes)\] to contain either a Swedish personal identity number, \[[SKV704](#skv704)\], or a Swedish coordination number, \[[SKV707](#skv707)\]. However, how to utilize coordination numbers in
+The `personalIdentityNumber` is defined in section 3.1 of \[[SC.SAML.Attrs](#sc-saml-attrs)\] to contain either a Swedish personal identity number, \[[SKV704](#skv704)\], or a Swedish coordination number, \[[SKV707](#skv707)\]. However, how to utilize coordination numbers in
 electronic services is, or has been, unclear. Not all Service Providers want, or are able to, use these types of identifiers. Therefore, this specification defines the "accepts coordination
 number" category as an opt-in feature for those Service Providers that can accept a `personalIdentityNumber` attribute to contain a coordination number as well as a personal identity number.
 
@@ -593,7 +599,7 @@ the `http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number` enti
 in its metadata.
 
 **Note**: This entity category does **not** apply to the eIDAS specific attribute
-`mappedPersonalIdentityNumber`, see section 3.3.2 of \[[EidAttributes](#eidattributes)\].
+`mappedPersonalIdentityNumber`, see section 3.3.2 of \[[SC.SAML.Attrs](#sc-saml-attrs)\].
 Thus, a coordination number may be included in this attribute even if the Service Provider
 has not declared the entity category. 
 
@@ -602,7 +608,7 @@ has not declared the entity category.
 
 **URL**: `http://id.swedenconnect.se/general-ec/1.0/supports-user-message`
 
-**Description**: Service Providers may include the `<umsg:UserMessage>` extension in authentication requests for the purpose of displaying a custom "user message" for the authentication users, see \[[UserMessageExt](#user-message-ext)\]. An Identity Provider announces support for this extension by declaring the `http://id.swedenconnect.se/general-ec/1.0/supports-user-message` entity category.
+**Description**: Service Providers may include the `<umsg:UserMessage>` extension in authentication requests for the purpose of displaying a custom "user message" for the authentication users, see \[[SC.SAML.UMsg](#sc-saml-umsg)\]. An Identity Provider announces support for this extension by declaring the `http://id.swedenconnect.se/general-ec/1.0/supports-user-message` entity category.
 
 
 <a name="references"></a>
@@ -645,29 +651,29 @@ has not declared the entity category.
 > [Skatteverket, SKV 707, Utgåva 2,
 > Samordningsnummer](https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf).
 
-<a name="eidtillit"></a>
-**\[EidTillit\]**
+<a name="se-trust"></a>
+**\[SE.Trust\]**
 > [Tillitsramverket för Svensk e-legitimation](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation).
 
-<a name="eiddeploy"></a>
-**\[EidDeploy\]**
+<a name="sc-saml-profile"></a>
+**\[SC.SAML.Profile\]**
 > [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
 
 <a name="sc-registry"></a>
 **\[SC.Registry\]**
 > [Sweden Connect - Registry for identifiers](https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html).
 
-<a name="eidattributes"></a>
-**\[EidAttributes\]**
+<a name="sc-saml-attrs"></a>
+**\[SC.SAML.Attrs\]**
 > [Attribute Specification for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html).
 
-<a name="sigsap"></a>
-**\[SigSAP\]**
+<a name="sc-sap"></a>
+**\[SC.SAP\]**
 > [Signature Activation Protocol for Federated Signing](https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html).
 
-<a name="user-message-ext"></a>
-**\[UserMessageExt\]**
-> [User Message Extension in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html).
+<a name="sc-saml-umsg"></a>
+**\[SC.SAML.UMsg\]**
+> [User Message Extension in SAML Authentication Requests](https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html).
 
 <a name="changes-between-versions"></a>
 ## 8. Changes between versions
diff --git a/07 - Implementation Profile for using DSS in Central Signing Services.md b/07 - Implementation Profile for using DSS in Central Signing Services.md
index 41bf041..9fae671 100644
--- a/07 - Implementation Profile for using DSS in Central Signing Services.md	
+++ b/07 - Implementation Profile for using DSS in Central Signing Services.md	
@@ -8,7 +8,7 @@
 
 #  Implementation Profile for using OASIS DSS in Central Signing Services
 
-### Version 1.6 - 2024-12-04 - *Draft version*
+### Version 1.6 - 2024-12-04
 
 Registration number: **2019-312**
 
@@ -24,7 +24,7 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
     1.1. [Terminology](#terminology)
 
-    1.2. [Requirement key words](#requirement-key-words)
+    1.2. [Requirements Notation](#requirements-notation)
 
     1.3. [Namespace references](#namespace-references)
 
@@ -123,10 +123,10 @@ Term | Defined meaning
 **Requesting Service** | The service requesting the signature on a particular document by a particular user.
 **Signing Service** | A centralized service that manages the process to authenticate the user that has been requested to sign a document, and the process to obtain the user’s signature on the requested document.
 
-<a name="requirement-key-words"></a>
-### 1.2. Requirement key words
+<a name="requirements-notation"></a>
+### 1.2. Requirements Notation
 
-The key words **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
+The keywords **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
 **SHALL** **NOT**, **SHOULD**, **SHOULD** **NOT**, **RECOMMENDED**,
 **MAY**, and **OPTIONAL** are to be interpreted as described in
 \[[RFC2119](#rfc2119)\].
@@ -321,7 +321,7 @@ attributes for each tag other than those listed in the following table:
 Allowed HTML entities for character replacement SHALL be restricted to
 `amp`, `gt`, `lt`, `quot` and `nbsp` (in the form `&entity-name;`).
 
-HTML messages MUST NOT contain any URI references to data outside of the
+HTML messages MUST NOT contain any URI references to data outside the
 message and MUST NOT contain any JavaScript in any form.
 
 <a name="requesting-identity-provider-to-display-signmessage"></a>
@@ -329,9 +329,9 @@ message and MUST NOT contain any JavaScript in any form.
 
 The means through which the Service Provider requests the Identity
 Provider to display a sign message is defined in section 7.1.1 of “Deployment Profile
-for the Swedish eID Framework” \[[Eid-Profile](#eid-profile)\].
+for the Swedish eID Framework” \[[SC.SAML.Profile](#sc-saml-profile)\].
 
-In addition to the requirements in section 7.1.1 of \[[Eid-Profile](#eid-profile)\] the 
+In addition to the requirements in section 7.1.1 of \[[SC.SAML.Profile](#sc-saml-profile)\] the 
 Signature Service MUST apply the following process regarding the inclusion of the
 `AuthnContextClassRef` URI to include in the `AuthnRequest` sent to the Identity Provider 
 when authenticating the user for signing:
@@ -349,9 +349,9 @@ when authenticating the user for signing:
 ##### 2.1.3.9. CertRequestProperties
 
 This element MAY be present to provide requested properties of generated
-signature certificates according with section 3.1.1 of \[[DSS-Ext](#dss-ext)\].
+signature certificates according to section 3.1.1 of \[[DSS-Ext](#dss-ext)\].
 
-When the `CertType` attribute is present with a value of `QC/SSCD` the signature service MUST request authentication in accordance with section 7.1.2 of “Deployment Profile for the Swedish eID Framework” \[[Eid-Profile](#eid-profile)\], or reject the request.
+When the `CertType` attribute is present with a value of `QC/SSCD` the signature service MUST request authentication in accordance with section 7.1.2 of “Deployment Profile for the Swedish eID Framework” \[[SC.SAML.Profile](#sc-saml-profile)\], or reject the request.
 
 <a name="authncontextclassref"></a>
 ###### 2.1.3.9.1. AuthnContextClassRef
@@ -467,7 +467,7 @@ request was processed and response was constructed. This version MUST be the sam
 version as given in the `SignRequestExtension` (see section [2.1.3.1](#version), "[Version](#version))".
 
 For backwards compatibility reasons that attribute MAY be absent if version "1.1" was requested. 
-Otherwise it MUST be set.
+Otherwise, it MUST be set.
 
 <a name="responsetime"></a>
 ##### 2.2.4.2. ResponseTime
@@ -478,7 +478,7 @@ The `<ResponseTime>` element MUST be present in the response.
 ##### 2.2.4.3. Request
 
 The `<Request>` element MAY be present in a response. However, it is RECOMMENDED not to include this
-element since it makes the response message unnecessary large. Instead the requester of a sign operation
+element since it makes the response message unnecessary large, instead the requester of a sign operation
 is expected to save the request message in its session for later use when processing a response message.
 
 <a name="signerassertioninfo"></a>
@@ -658,14 +658,14 @@ EidSignResponse | Base64 encoded sign response.
 **[XMLSig-XSD]**
 > XML Signature Schema. World Wide Web Consortium. See <https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd>.
 
-<a name="eid-profile"></a>
-**[Eid-Profile]**
-> [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
-
 <a name="dss-ext"></a>
 **[DSS-Ext]**
 > [DSS Extension for Federated Central Signing Services](https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html).
 
+<a name="sc-saml-profile"></a>
+**[SC.SAML.Profile]**
+> [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
+
 <a name="sc-registry"></a>
 **[SC.Registry]**
 > [Sweden Connect - Registry for identifiers](https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html).
@@ -703,7 +703,7 @@ EidSignResponse | Base64 encoded sign response.
 
 **Changes between version 1.2 and version 1.3:**
 
-- In section 2.1.3.9, "CertRequestProperties", an requirement to adapt authentication request procedures when the requested signature is a qualified electronic signature was added.
+- In section 2.1.3.9, "CertRequestProperties", a requirement to adapt authentication request procedures when the requested signature is a qualified electronic signature was added.
 
 **Changes between version 1.1 and version 1.2:**
 
diff --git a/09 - DSS Extension for Federated Signing Services.md b/09 - DSS Extension for Federated Signing Services.md
index 8465fde..311f147 100644
--- a/09 - DSS Extension for Federated Signing Services.md	
+++ b/09 - DSS Extension for Federated Signing Services.md	
@@ -8,7 +8,7 @@
 
 # DSS Extension for Federated Central Signing Services
 
-### Version 1.5 - 2024-11-25 - *Draft version*
+### Version 1.5 - 2024-12-04
 
 Registration number: **2019-314**
 
@@ -24,7 +24,7 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
     1.1. [Terminology](#terminology)
 
-    1.1.1. [Key words](#key-words)
+    1.1.1. [Keywords](#keywords)
 
     1.1.2. [Structure](#structure)
 
@@ -85,7 +85,7 @@ Appendix A. [**XML Schema**](#appendix-a.xml-schema)
 <a name="introduction"></a>
 ## 1. Introduction
 
-This specifications defines elements that extend the
+This specification defines elements that extend the
 `<dss:SignRequest>` and `<dss:SignResponse>` elements of
 \[[OASIS-DSS](#dss)\].
 
@@ -126,10 +126,10 @@ request.
 <a name="terminology"></a>
 ### 1.1. Terminology
 
-<a name="key-words"></a>
-#### 1.1.1.  Key words
+<a name="keywords"></a>
+#### 1.1.1.  Keywords
 
-The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
+The keywords *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
 *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* are to be
 interpreted as described in \[[RFC 2119](#rfc2119)\].
 
@@ -150,7 +150,7 @@ This specification uses the following typographical conventions in text:
 Listings of DSS schemas appear like this.
 
 <a name="definitions"></a>
-#### 1.1.3.  Definitions
+#### 1.1.3. Definitions
 
 **Identity Provider**
 
@@ -187,7 +187,7 @@ different namespace.
 
 Conventional XML namespace prefixes are used in the schema:
 
--   The prefix `csig`: stands for the this specification's XML schema
+-   The prefix `csig`: stands for this specification's XML schema
     namespace \[[Csig-XSD](#csig-xsd)\].
 
 -   The prefix `dss`: stands for the DSS core namespace
@@ -245,7 +245,7 @@ Recommendation \[[XML](#xml)\] Section 2.3).
 Unless otherwise noted in this specification, all elements that have the
 XML Schema **xs:string** type, or a type derived from that, MUST be
 compared using an exact binary comparison. In particular,
-implementations MUST NOT depend on case insensitive string comparisons,
+implementations MUST NOT depend on case-insensitive string comparisons,
 normalization or trimming of whitespace, or conversion of
 locale-specific formats such as numbers or currency. This requirement is
 intended to conform to the W3C working group note "Requirements for String
@@ -716,7 +716,7 @@ attributes and elements:
 > The MIME type defining the message format. This is an enumeration of
 > the valid attribute values `text` (plain text), `text/html` (html) or
 > `text/markdown` (markdown). This specification does not specify any
-> particular restrictions on the provided message but it is RECOMMENDED
+> particular restrictions on the provided message, but it is RECOMMENDED
 > that sign message content is restricted to a limited set of valid tags
 > and attributes, and that the display entity performs filtering to
 > enforce these restrictions before displaying the message. The means
@@ -966,7 +966,7 @@ This complex type can be used to hold a sequence of X.509 certificates.
 Certificates MUST be provided in sequence with the end-entity
 certificate first in the sequence followed by any CA certificates that
 can be used to verify the previous certificate in the sequence, ending
-with a self signed root certificate.
+with a self-signed root certificate.
 
 The **CertificateChainType** complex type has the following elements:
 
@@ -1224,7 +1224,7 @@ be signed to the signer. Implementers of this specification MUST sign
 requests and responses for signature creation to protect against
 spoofing and substitution attacks. If a hash of the document to be
 signed is replaced in a sign request, the signer may end up signing
-something completely different than what the requesting service
+something completely different from what the requesting service
 presented to the signer.
 
 When a `<dss:SignRequest>` is signed, the signature of that request
@@ -1244,7 +1244,7 @@ signature and MUST check that the signature covers all data in the
 
 <a name="csig-xsd"></a>
 **\[Csig-XSD\]**
-> This specification's DSS Extensions schema Version 1.1.3, https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd, November, 2024.
+> This specification's DSS Extensions schema Version 1.1.3, https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd, November 2024.
 
 <a name="dss"></a>
 **\[OASIS-DSS\]**
diff --git a/12 - BankID Profile for the Swedish eID Framework.md b/12 - BankID Profile for the Swedish eID Framework.md
index f27f758..1a02b1c 100644
--- a/12 - BankID Profile for the Swedish eID Framework.md	
+++ b/12 - BankID Profile for the Swedish eID Framework.md	
@@ -166,7 +166,7 @@ For Identity Providers implementing BankID support in **one** Identity Provider
 <a name="relying-party-configuration"></a>
 ### 1.4. Relying Party Configuration
 
-When a Relying Party uses the BankID Relying Party API directly in order to implement BankID services, it has a set of configuration settings to choose from (see `requirements` object under the [Auth](https://developers.bankid.com/api-references/auth--sign/auth) and [Sign API](https://developers.bankid.com/api-references/auth--sign/sign). Examples are:
+When a Relying Party uses the BankID Relying Party API directly in order to implement BankID services, it has a set of configuration settings to choose from (see `requirements` object under the [Auth](https://developers.bankid.com/api-references/auth--sign/auth) and [Sign API](https://developers.bankid.com/api-references/auth--sign/sign)). Examples are:
 
 - Should fingerprints be allowed instead of the user entering his or hers security code?
 
@@ -174,9 +174,9 @@ When a Relying Party uses the BankID Relying Party API directly in order to impl
 
 - Smart card reader preferences.
 
-However, the services of a BankID Identity Provider are used by several parties within the federation and it is thus harder to maintain a per Service Provider configuration. Therefore, a BankID Identity Provider compliant with this profile SHOULD use the same configuration defaults as stated in [Auth](https://developers.bankid.com/api-references/auth--sign/auth) and [Sign API](https://developers.bankid.com/api-references/auth--sign/sign).
+However, the services of a BankID Identity Provider are used by several parties within the federation, and it is thus harder to maintain a per-Service Provider configuration. Therefore, a BankID Identity Provider compliant with this profile SHOULD use the same configuration defaults as stated in [Auth](https://developers.bankid.com/api-references/auth--sign/auth) and [Sign API](https://developers.bankid.com/api-references/auth--sign/sign).
 
-> **Note:** It is of course allowed for a BankID Identity Provider to maintain specific Service Provider configurations, but this is outside of the scope for this profile, and there will be no specification support to accomplish this.
+> **Note:** It is of course allowed for a BankID Identity Provider to maintain specific Service Provider configurations, but this is outside the scope for this profile, and there will be no specification support to accomplish this.
 
 <a name="attributes"></a>
 ## 2. Attributes
@@ -222,7 +222,7 @@ The attribute is used by attribute providers to release data from an authenticat
 <a name="identity-provider-user-interface"></a>
 ## 3. Identity Provider User Interface
 
-This profile does not state any requirements on how the user interface for an Identity Provider implementing BankID services should be implemented other than the statements listed in the sub sections below.
+This profile does not state any requirements on how the user interface for an Identity Provider implementing BankID services should be implemented other than the statements listed in the subsections below.
 
 <a name="general-requirements"></a>
 ### 3.1. General Requirements
@@ -266,14 +266,16 @@ An Identity Provider conformant with this profile MUST require `<saml2p:AuthnReq
 <a name="handling-of-principal-selection"></a>
 ### 4.2. Handling of Principal Selection
 
-An Identity Provider that has declared support for the `<psc:PrincipalSelection>` extension (see see section [6](#metadata)) MUST assign the `requirement.personalNumber` field of [/auth](https://developers.bankid.com/api-references/auth--sign/auth) or [/sign](https://developers.bankid.com/api-references/auth--sign/sign) if a Swedish personal identity number is received in the `<psc:PrincipalSelection>` extension.
+An Identity Provider that has declared support for the `<psc:PrincipalSelection>` extension (see section [6](#metadata)) MUST assign the `requirement.personalNumber` field of [/auth](https://developers.bankid.com/api-references/auth--sign/auth) or [/sign](https://developers.bankid.com/api-references/auth--sign/sign) if a Swedish personal identity number is received in the `<psc:PrincipalSelection>` extension.
 
 See \[[SC.SAML.Principal](#sc-saml-principal)\] for further requirements concerning the principal selection extension.
 
 <a name="authentication-for-signature"></a>
 ### 4.3. Authentication for Signature
 
-An Identity Provider conforming to the Sweden Connect Framework is obliged to handle requests received from Signature Services as described in section 7, “Authentication for Signature”, of \[[SC.SAML.Profile](#sc-saml-profile)\]. This section further specifies how a BankID Identity Provider should support “authentication for signature”.

A BankID Identity Provider that receives an `<saml2p:AuthnRequest>` message from a Signature Service MUST initiate a BankID **signature** operation. It MUST NOT initiate a BankID authentication operation for several reasons: 
+An Identity Provider conforming to the Sweden Connect Framework is obliged to handle requests received from Signature Services as described in section 7, “Authentication for Signature”, of \[[SC.SAML.Profile](#sc-saml-profile)\]. This section further specifies how a BankID Identity Provider should support “authentication for signature”.
+
+A BankID Identity Provider that receives an `<saml2p:AuthnRequest>` message from a Signature Service MUST initiate a BankID **signature** operation. It MUST NOT initiate a BankID authentication operation for several reasons: 
 
 * the user interface in the BankID client (app or Desktop program) during authentication indicates that the user is logging on (and not signing which is the case when a request from a Signature Service is being processed), 
 * the user expects to be displayed a text describing what he or she is signing,
@@ -286,19 +288,22 @@ The BankID client (app or desktop program) comprises a text box in which the sig
 
 An Identity Provider that processes an `<saml2p:AuthnRequest>` from a Signature Service is not given the actual data that is being signed by the user via the Signature Service. However, in order to invoke the BankID signature function, the Identity Provider must supply the BankID-server with data to be signed. This section specifies the input to the BankID signature operation.
 
-The "To-be-signed" data that is passed as input the the BankID Sign-method (`/sign`) is a combination of the data from the `userVisibleData` and `userNonVisibleData` parameters (<https://developers.bankid.com/api-references/auth--sign/sign>).
+The "To-be-signed" data that is passed as input the BankID Sign-method (`/sign`) is a combination of the data from the `userVisibleData` and `userNonVisibleData` parameters (<https://developers.bankid.com/api-references/auth--sign/sign>).
 
 <a name="uservisibledata"></a>
 ##### 4.3.1.1. userVisibleData - Signature Message
 
-The Sign-method parameter `userVisibleData` holds data that will be signed by the user but it is also displayed in the BankID application text box.
+The Sign-method parameter `userVisibleData` holds data that will be signed by the user, but it is also displayed in the BankID application text box.
 
 If the `<saml2p:AuthnRequest>` message contains a `SignMessage` extension, the contents of this message MUST be assigned to the `userVisibleData` parameter (after necessary encoding).
 
-A BankID Identity Provider MUST support `SignMessage` elements having their `MimeType` attribute set to `text`, and SHOULD support Markdown (`text/markdown`) according to [BankID - Guidelines for Formatted Text](#bankid-md), \[[BankID.MD](#bankid-md)\]. For other values (`text/html`), the Identity Provider MUST respond with an error.

If the `<saml2p:AuthnRequest>` message does not contain a `SignMessage` extension, the Identity Provider MUST assign a sensible default signature message to the `userVisibleData` parameter. How this message is constructed is the responsibility of the Identity Provider, but it must be obvious for the user who is the requesting party, i.e., the Service Provider that has ordered the signature operation<sup>2</sup>.
-
> \[1\]: If the `MimeType` attribute is not set, `text` is the default value.
+A BankID Identity Provider MUST support `SignMessage` elements having their `MimeType` attribute set to `text`, and SHOULD support Markdown (`text/markdown`) according to [BankID - Guidelines for Formatted Text](#bankid-md), \[[BankID.MD](#bankid-md)\]. For other values (`text/html`), the Identity Provider MUST respond with an error.
+
+If the `<saml2p:AuthnRequest>` message does not contain a `SignMessage` extension, the Identity Provider MUST assign a sensible default signature message to the `userVisibleData` parameter. How this message is constructed is the responsibility of the Identity Provider, but it must be obvious for the user who is the requesting party, i.e., the Service Provider that has ordered the signature operation<sup>2</sup>.
+
+> \[1\]: If the `MimeType` attribute is not set, `text` is the default value.
 > 
-> \[2\]: For this purpose, the `<mdui:DisplayName>` element of the Signature Service’s metadata entry, is a good and generic choice.
+> \[2\]: For this purpose, the `<mdui:DisplayName>` element of the Signature Service’s metadata entry, is a good and generic choice.
 
 <a name="usernonvisibledata"></a>
 ##### 4.3.1.2. userNonVisibleData
@@ -343,7 +348,7 @@ If the user cancels a BankID operation, either by clicking the Cancel-button in
 
 In cases where the Identity Provider receives the BankID error code `ALREADY_IN_PROGRESS` in response to an Auth- or Sign-call the Identity Provider MAY display a warning to the user that someone may have initiated a BankID operation using their personal identity number<sup>1</sup>. If this warning is displayed, it is RECOMMENDED that the second level status code `http://id.elegnamnden.se/status/1.0/possibleFraud` is included in the error response message posted back to the Service Provider.
 
-> \[1\]: There have been reports where fraudsters remotely try to convince people of using their Mobile BankID to log in to a service. In these cases, the fraudster initiates a BankID authentication prior to the person he tries to trick into logging in to the service, and is waiting for the user to enter his or hers personal code, thus authenticating the fraudsters session. 
+> \[1\]: There have been reports where fraudsters remotely try to convince people of using their Mobile BankID to log in to a service. In these cases, the fraudster initiates a BankID authentication prior to the person he tries to trick into logging in to the service, and is waiting for the user to enter his or hers personal code, thus authenticating the fraudster's session. 
 
 <a name="metadata"></a>
 ## 6. Metadata
@@ -508,4 +513,4 @@ using the `secure-authenticator-binding` entity category, may request that QR co
 **Changes between version 1.0 and 1.1:**
 
 - Section 3.4, "Cancelling an Operation" was extended with a suggestion of how to avoid dangling sessions after user cancel.
-- The profile now references the BankID Relying Party Guidelines that makes use of JSON.
\ No newline at end of file
+- The profile now references the BankID Relying Party Guidelines that makes use of JSON.
diff --git a/13 - Signature Activation Protocol.md b/13 - Signature Activation Protocol.md
index b047f41..4227c76 100644
--- a/13 - Signature Activation Protocol.md	
+++ b/13 - Signature Activation Protocol.md	
@@ -8,21 +8,21 @@
 
 # Signature Activation Protocol for Federated Signing
 
-### Version 1.2 - 2022-12-20 - *Draft version*
+### Version 1.2 - 2024-12-04
 
 Registration number: **2019-317**
 
 ---
 
 <p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2022. All Rights Reserved.
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
 </p>
 
 ## Table of Contents
 
 1. [**Introduction**](#introduction)
 
-    1.1. [Requirement key words](#requirement-key-words)
+    1.1. [Requirement keywords](#requirement-keywords)
 
     1.2. [XML namespace references](#xml-namespace-references)
 
@@ -72,10 +72,10 @@ The Signature Activation Protocol (SAP) defined in this document is used to exch
 
 The SAP specified in this document is specifically designed to be used with a signing service operating in accordance with the federated signing specification \[[DSS-Ext](#dss-ext)\].
 
-<a name="requirement-key-words"></a>
-### 1.1. Requirement key words
+<a name="requirement-keywords"></a>
+### 1.1. Requirement keywords
 
-The key words **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
+The keywords **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
 **SHALL** **NOT**, **SHOULD**, **SHOULD** **NOT**, **RECOMMENDED**,
 **MAY**, and **OPTIONAL** are to be interpreted as described in
 \[[RFC2119](#rfc2119)\].
@@ -127,7 +127,7 @@ This document specifies exchange of two data elements:
 - `SADRequest`
 - `SAD`
 
-The `SADRequest` SHALL have the format defined in section [3.1](#sadrequest). When a Remote Signing Service request a SAD from the Identity Provider, it MUST include the `SADRequest` element as an request extension by including it as a child element to a `<saml2p:Extensions>` element in the `<saml2p:AuthnRequest>`.
+The `SADRequest` SHALL have the format defined in section [3.1](#sadrequest). When a Remote Signing Service request a SAD from the Identity Provider, it MUST include the `SADRequest` element as a request extension by including it as a child element to a `<saml2p:Extensions>` element in the `<saml2p:AuthnRequest>`.
 
 When an Identity Provider returns a SAD, as defined in section [3.2](#signature-activation-data), in a SAML Assertion, it MUST be included as a single string value of a `sad` attribute identified by the attribute name `urn:oid:1.2.752.201.3.12` as defined in the attribute specification [[EidAttributes](#eidattributes)].
 
@@ -174,7 +174,7 @@ The SAD Request is provided in a `<sap:SADRequest>` element. The element has the
 
 `ID` \[Required\]
 
-> Attribute holding an unique identifier for the `SADRequest`.
+> Attribute holding a unique identifier for the `SADRequest`.
 
 The following schema fragment defines the `<sap:SADRequest>` element:
 
@@ -426,7 +426,7 @@ Protection profile for QSCD for Server Signing
 
 **Changes between version 1.1 and 1.2:**
 
-- The protocol logic was clarified by removing references to sign message (which was never present in the actual protocol) and replacing this with a clarification of the semantics of including the the Sign Request ID in SAD to assert the acceptance to sign the documents referenced in that Sign Request.
+- The protocol logic was clarified by removing references to sign message (which was never present in the actual protocol) and replacing this with a clarification of the semantics of including the Sign Request ID in SAD to assert the acceptance to sign the documents referenced in that Sign Request.
 
 - Updated examples where the use of "signmessage" LoA URI:s was removed.
 
diff --git a/18 - User Message Extension in SAML Authentication Requests.md b/18 - User Message Extension in SAML Authentication Requests.md
index 01ae508..3775f74 100644
--- a/18 - User Message Extension in SAML Authentication Requests.md	
+++ b/18 - User Message Extension in SAML Authentication Requests.md	
@@ -8,14 +8,14 @@
 
 # User Message Extension in SAML Authentication Requests
 
-### Version 1.0 - 2024-04-15 - *Draft version*
+### Version 1.0 - 2024-12-04
 
-Registration number: TBD
+Registration number: **2024-7673**
 
 ---
 
 <p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2024. All Rights Reserved.
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
 </p>
 
 ## Table of Contents
@@ -56,7 +56,7 @@ This specification defines the `<umsg:UserMessage>` element that may be included
 <a name="requirements-notation"></a>
 ### 1.1. Requirements Notation
 
-The key words **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
+The keywords **MUST**, **MUST** **NOT**, **REQUIRED**, **SHALL**,
 **SHALL** **NOT**, **SHOULD**, **SHOULD** **NOT**, **RECOMMENDED**,
 **MAY**, and **OPTIONAL** are to be interpreted as described in
 \[[RFC2119](#rfc2119)\].
@@ -86,7 +86,7 @@ This specification uses the following typographical conventions in text:
 
 This specification defines the element `<UserMessage>` to be included in the `<Extensions>` element of an `AuthnRequest`. 
 
-This element MAY included by a Service Provider asking the Identity Provider to display a given message for the user during the authentication phase. The element has the following elements and attributes:
+This element MAY be included by a Service Provider asking the Identity Provider to display a given message for the user during the authentication phase. The element has the following elements and attributes:
 
 `<Message>` \[One or more\]
 > Element that holds the user message for a specific language. See below.
@@ -137,7 +137,7 @@ The required `xml:lang` attribute contains the language tag for the message's la
 <a name="identity-provider-requirements"></a>
 ### 3.1. Identity Provider Requirements
 
-An Identity Provider that supports the `<umsg:UserMessage>` extension MUST declare this support in its metadata entry by declaring the `http://id.swedenconnect.se/general-ec/1.0/supports-user-message` entity category (see section 6.3 of \[[EidEntCat](#eidentcat)\]).
+An Identity Provider that supports the `<umsg:UserMessage>` extension MUST declare this support in its metadata entry by declaring the `http://id.swedenconnect.se/general-ec/1.0/supports-user-message` entity category (see section 6.3 of \[[SC.SAML.EntCat](#sc-saml-entcat)\]).
 
 Identity Providers compliant with this specification MUST support the `text/plain` and `text/markdown` MIME types.
 
@@ -162,7 +162,7 @@ A Service Provider MUST NOT supply user messages that contains integrity sensiti
 ## 4. Examples
 
 Example of supplying a user message in Swedish ("Jag vill logga in till example.com") and in
-English ("I wish to login to example.com"):
+English ("I wish to log in to example.com"):
 
 ```
 ...
@@ -251,9 +251,9 @@ The following XML schema defines the `http://id.swedenconnect.se/authn/1.0/user-
 > Assertion Markup Language (SAML) V2.0, March
 > 2005](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
 
-<a name="eidentcat"></a>
-**\[EidEntCat\]**
-> [Entity Categories for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html).
+<a name="sc-saml-entcat"></a>
+**\[SC.SAML.EntCat\]**
+> [Entity Categories for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html).
 
 <a name="changes-between-versions"></a>
 ## 7. Changes between versions
diff --git a/Identity Binding.md b/Identity Binding.md
index 9cbdd95..a8569d3 100644
--- a/Identity Binding.md	
+++ b/Identity Binding.md	
@@ -11,6 +11,8 @@
 
 ### 2024-11-22
 
+Registration number: **2024-7672**
+
 This document outlines the process for binding an eIDAS-notified electronic identity (eID) to an individual's personal identification number in the Swedish Population Register.
 
 ---
@@ -81,7 +83,7 @@ See also sections 2.5, "eIDAS Natural Person Attribute Set", and 3.3.2, "The map
 <a name="identity-binding-processes"></a>
 ## 3. Identity Binding Processes
 
-This section contains a detailed description of the binding processes that are used by the Identity Binding Service. Each process is identified with an URI.
+This section contains a detailed description of the binding processes that are used by the Identity Binding Service. Each process is identified with a URI.
 
 To perform the identity binding process, a user must meet the following requirements:
 
@@ -95,7 +97,7 @@ To perform the identity binding process, a user must meet the following requirem
 
 - The user must accept the terms of use and consent to creation of a private storage area that belongs to the user.
 
-**Note:** If the above steps uniquely corresponds to exactly one record in the Swedish population register, the binding `http://id.swedenconnect.se/id-binding/process/populationregister` ([3.1](#population-register)) will be created, but, if the birth date and name information from the eIDAS assertion matches more than one record from the population register, other processes (as described below) need to be applied for a binding to be completed.
+**Note:** If the above steps uniquely corresponds to exactly one record in the Swedish population register, the binding `http://id.swedenconnect.se/id-binding/process/populationregister` ([3.1](#population-register)) will be created, but, if the birthdate and name information from the eIDAS assertion matches more than one record from the population register, other processes (as described below) need to be applied for a binding to be completed.
 
 <a name="population-register"></a>
 ### 3.1. Unique Record in the Population Register
@@ -111,7 +113,7 @@ A detailed search in the population register confirms that there is a low risk o
 
 **URI:** `http://id.swedenconnect.se/id-binding/process/swedish-eid`
 
-**Description:** The user has digitally signed an attestation connecting an eIDAS identity number to a record retrieved from the Swedish population register using a Swedish eID. Using this process the user proves the he or she holds both the eIDAS identity (received from the eIDAS-notified eID) and the Swedish identity number (received from the digital signature).
+**Description:** The user has digitally signed an attestation connecting an eIDAS identity number to a record retrieved from the Swedish population register using a Swedish eID. Using this process the user proves that he or she holds both the eIDAS identity (received from the eIDAS-notified eID) and the Swedish identity number (received from the digital signature).
 
 **Additional requirements:** Assurance level for the Swedish eID must be minimum at level 3 in accordance of the [Swedish Trust Framework](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation) (a.k.a. [Tillitsramverk för Svensk e-legitimation](https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation)). Using the eID for this purpose must also be approved by the eID provider.
 
@@ -120,7 +122,6 @@ A detailed search in the population register confirms that there is a low risk o
 
 - 2024-11-22: Updated version where the bindings for Nordic eID:s and relative confirmation were removed due to legal reasons.
 
-- 2024-05-08: Updated according to the latest legal agreements. The binding level is no longer used. Instead a set of identity binding process URL:s represent the binding.
+- 2024-05-08: Updated according to the latest legal agreements. The binding level is no longer used, instead a set of identity binding process URL:s represent the binding.
 
 - 2023-06-09: First version.
-
diff --git a/OpenID Connect Claims and Scopes Specification.md b/OpenID Connect Claims and Scopes Specification.md
index 419626b..ea83171 100644
--- a/OpenID Connect Claims and Scopes Specification.md	
+++ b/OpenID Connect Claims and Scopes Specification.md	
@@ -8,9 +8,9 @@
 
 # OpenID Connect Claims and Scopes Specification for Sweden Connect
 
-### Version 1.0 - 2024-11-28 - *Draft version*
+### Version 1.0 - 2024-12-04
 
-Registration number: **TBD**
+Registration number: **2024-7704**
 
 ---
 
@@ -54,6 +54,8 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
 4. [**References**](#references)
 
+5. [**Changes between versions**](#changes-between-versions)
+
 Appendix A: [**Conversion of eIDAS Attributes**](#conversion-of-eidas-attributes)
 
 ---
@@ -82,7 +84,7 @@ The claims defined in this specification are named in a collision-resistant mann
 
 This section defines how identity attributes received from, or in conjunction with, an eIDAS authentication is represented as OpenID claims within the Sweden Connect federation. 
 
-[Appendix A: Conversion of eIDAS Attributes](#conversion-of-eidas-attributes) presents a full listing of all eIDAS attributes and how they map to OpenID Connect claims. The sub-sections below define additional claims that may be added by the Swedish eIDAS-node.
+[Appendix A: Conversion of eIDAS Attributes](#conversion-of-eidas-attributes) presents a full listing of all eIDAS attributes and how they map to OpenID Connect claims. The subsections below define additional claims that may be added by the Swedish eIDAS-node.
 
 <a name="provisional-identifier"></a>
 #### 2.1.1. Provisional Identifier
@@ -180,7 +182,7 @@ The scopes defined in this specification are named in a collision-resistant mann
 
 Section 3 of \[[OIDC.Sweden.Claims](#oidc-sweden-claims)\] states the following:
 
-> Many Relying Parties that use OpenID Connect to authenticate users cannot solely depend on the user's session at the OpenID Provider and the `sub` claim to log in the user to the RP application. In the context of Swedish eID there are some obvious claims that are regarded to be "primary" identity claims by Relying Parties, for example, a Swedish personal identity number. Such claims are needed by the Relying Party in order to log in a user to its application. Therefore, this specification's scope definitions will define that some claims are to be delivered in the ID Token so that a Relying Party can fully log in a user without having to make a, potentially, unnecessary call to the UserInfo endpoint.
+> Many Relying Parties that use OpenID Connect to authenticate users cannot solely depend on the user's session at the OpenID Provider and the `sub` claim to log in the user to the RP application. In the context of Swedish eID there are some obvious claims that are regarded to be "primary" identity claims by Relying Parties, for example, a Swedish personal identity number. Such claims are needed by the Relying Party in order to log in a user to its application. Therefore, this specification's scope definitions will define that some claims are to be delivered in the ID Token so that a Relying Party can fully log in a user without having to make a potentially unnecessary call to the UserInfo endpoint.
 
 The above is true also for Relying Parties authenticating users against the Swedish eIDAS Connector.
 
@@ -259,7 +261,7 @@ Not all eIDAS attributes/claims listed in [Appendix A](#conversion-of-eidas-attr
 
 - For all other optional eIDAS attributes (see [Appendix A](#conversion-of-eidas-attributes)), an explicit claim request should be included. These claims SHOULD NOT be marked as "essential" since they are not mandatory according to \[[eIDAS.Attributes](#eidas-attr)\]. 
 
-> Section 2.2.1 of \[[eIDAS.Attributes](#eidas-attr)\] defines the eIDAS Minimum Dataset for Natural Persons. This set comprises of the eIDAS attributes FamilyName, FirstName, DateOfBirth and PersonIdentifier. In order for a Relying Party to obtain the corresponding OpenID Connect claims from an eIDAS authentication it should specify the `https://id.oidc.se/scope/naturalPersonInfo` and `https://id.swedenconnect.se/scope/eidasNaturalPersonIdentity` scopes in an authentication request sent to the Swedish eIDAS Connector.
+> Section 2.2.1 of \[[eIDAS.Attributes](#eidas-attr)\] defines the eIDAS Minimum Dataset for Natural Persons. This set consists of the eIDAS attributes FamilyName, FirstName, DateOfBirth and PersonIdentifier. In order for a Relying Party to obtain the corresponding OpenID Connect claims from an eIDAS authentication it should specify the `https://id.oidc.se/scope/naturalPersonInfo` and `https://id.swedenconnect.se/scope/eidasNaturalPersonIdentity` scopes in an authentication request sent to the Swedish eIDAS Connector.
 
 
 <a name="references"></a>
@@ -317,6 +319,11 @@ Not all eIDAS attributes/claims listed in [Appendix A](#conversion-of-eidas-attr
 **\[ISO3166-3\]**
 > [ISO, "ISO 3166-3:2020. Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries", 2020](https://www.iso.org/standard/72482.html).
 
+<a name="changes-between-versions"></a>
+## 5. Changes between versions
+
+This is the first version of this specification.
+
 <a name="conversion-of-eidas-attributes"></a>
 ## Appendix A: Conversion of eIDAS Attributes
 
diff --git a/OpenID Connect Profile for Sweden Connect.md b/OpenID Connect Profile for Sweden Connect.md
index 5edc35a..ebe6757 100644
--- a/OpenID Connect Profile for Sweden Connect.md	
+++ b/OpenID Connect Profile for Sweden Connect.md	
@@ -8,9 +8,9 @@
 
 # OpenID Connect Profile for Sweden Connect
 
-### Version 1.0 - 2024-12-02 - *Draft version*
+### Version 1.0 - 2024-12-04
 
-Registration number: **TBD**
+Registration number: **2024-7674**
 
 ---
 
@@ -54,6 +54,8 @@ Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Go
 
 4. [**References**](#references)
 
+5. [**Changes between versions**](#changes-between-versions)
+
 ---
 
 <a name="introduction"></a>
@@ -271,3 +273,8 @@ See further requirements concerning client metadata in section 2 of \[[OpenID.Re
 <a name="sc-saml-profile"></a>
 **\[SC.SAML.Profile\]**
 > [Deployment Profile for the Swedish eID Framework](https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html).
+
+<a name="changes-between-versions"></a>
+## 5. Changes between versions
+
+This is the first version of this specification.
diff --git a/docs/december-2024/00_-_Swedish_eID_Framework_-_Introduction.html b/docs/december-2024/00_-_Swedish_eID_Framework_-_Introduction.html
new file mode 100644
index 0000000..8f73e60
--- /dev/null
+++ b/docs/december-2024/00_-_Swedish_eID_Framework_-_Introduction.html
@@ -0,0 +1,569 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Introduction to the Sweden Connect Technical Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="introduction-to-the-sweden-connect-technical-framework">Introduction to the Sweden Connect Technical Framework</h1>
+<h3 id="2024-12-04">2024-12-04</h3>
+<p>Registration number: <strong>2019-267</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#overview">Overview</a></p>
+<p> 1.2. <a href="#the-assurance-framework-and-levels-of-assurance">The Assurance Framework and Levels of Assurance</a></p>
+<p> 1.3. <a href="#service-for-collection-administration-and-publishing-of-metadata">Service for Collection, Administration and Publishing of Metadata</a></p>
+<p> 1.4. <a href="#discovery-service">Discovery Service</a></p>
+<p> 1.5. <a href="#relying-party-integration">Relying Party Integration</a></p>
+<p> 1.6. <a href="#signatures">Signatures</a></p>
+<p> 1.7. <a href="#the-technical-framework-and-eidas">The Technical Framework and eIDAS</a></p>
+<p> 1.7.1. <a href="#foreign-eid-authentication">Foreign eID Authentication</a></p>
+<p> 1.7.2. <a href="#signing-using-a-foreign-eid">Signing using a Foreign eID</a></p>
+<p> 1.7.3. <a href="#handling-of-identities">Handling of Identities</a></p>
+<p> 1.7.4. <a href="#swedish-eids-in-foreign-services">Swedish eID:s in Foreign Services</a></p>
+</li>
+<li><p><a href="#technical-specifications"><strong>Technical Specifications</strong></a></p>
+<p> 2.1. <a href="#profiles-and-specifications-for-saml">Profiles and Specifications for SAML</a></p>
+<p> 2.1.1. <a href="#deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</a></p>
+<p> 2.1.2. <a href="#swedish-eid-framework-registry-for-identifiers">Swedish eID Framework - Registry for identifiers</a></p>
+<p> 2.1.3. <a href="#attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</a></p>
+<p> 2.1.4. <a href="#entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</a></p>
+<p> 2.1.5. <a href="#eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a></p>
+<p> 2.1.6. <a href="#bankid-profile">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a></p>
+<p> 2.1.7. <a href="#principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</a></p>
+<p> 2.1.8. <a href="#user-message-extension-in-saml-authentication-requests">User Message Extension in SAML Authentication Requests</a></p>
+<p> 2.2. <a href="#profiles-and-specifications-for-openid-connect">Profiles and Specifications for OpenID Connect</a></p>
+<p> 2.2.1. <a href="#openid-connect-profile-for-sweden-connect">OpenID Connect Profile for Sweden Connect</a></p>
+<p> 2.2.2. <a href="#openid-connect-claims-and-scopes-specification-for-sweden-connect">OpenID Connect Claims and Scopes Specification for Sweden Connect</a></p>
+<p> 2.3. <a href="#signature-specifications">Signature Specifications</a></p>
+<p> 2.3.1. <a href="#implementation-profile-oasis-dss">Implementation Profile for using OASIS DSS in Central Signing Services</a></p>
+<p> 2.3.2. <a href="#dss-extensions">DSS Extension for Federated Central Signing Services</a></p>
+<p> 2.3.3. <a href="#certificate-profile-css">Certificate Profile for Certificates Issued by Central Signing Services</a></p>
+<p> 2.3.4. <a href="#signature-activation">Signature Activation Protocol for Federated Signing</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+<p> 3.1. <a href="#digg">DIGG</a></p>
+<p> 3.2. <a href="#other-references">Other References</a></p>
+</li>
+</ol>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p><a name="overview"></a></p>
+<h3 id="11-overview">1.1. Overview</h3>
+<p>The Swedish eID Framework (Sweden Connect Technical Framework) is adapted for identity federations based on SAML 2.0.</p>
+<blockquote>
+<p>In the latest version of the framework, specifications for OpenID Connect have been introduced. Currently, there is no federation support for OpenID Connect. This will be introduced during 2025.</p>
+</blockquote>
+<blockquote>
+<p>Currently, the document only describes the Sweden Connect SAML-federation. When support for an OpenID Connect-federation has been fully implemented, this document will be updated to describe this technique as well.</p>
+</blockquote>
+<p>Relying parties receive identity assertions in a standardized format
+from an identity provider.</p>
+<p>Service providers that require electronic signatures do not need to be adapted to different
+signature techniques based on different types of eID:s. Instead, a service provider makes 
+use of a signature service where users with the support of authenticating at an identity 
+provider are given the possibility to sign digital documents.</p>
+<p>Within the federation, e-services and relying parties are taking the roles of 
+Service Providers (SP), and authenticating services issuing identity assertions assume 
+the roles of Identity Providers (IdP).</p>
+<p>In cases where the service provider needs more information about the user, for example its
+legal authority, an attribute service (<em>Attribute Authority</em>) within the federation can be queried, if such a service exists. Through an attribute 
+request a service provider can obtain the necessary supplementary information in order to
+authorize the user and provide access to its service.</p>
+<p>As both personal identity information and other attributes linked to
+users are provided through identity assertions, all types of eID:s that have 
+an identity provider within the federation can be used by a service provider
+that requires specific identity attributes, even if a particular eID does not
+hold this information.</p>
+<p class="img-container"><img src="img/sweeid-overview1-en.png" alt=""></p>
+<p>Figure 1: <em>Illustration of the communication between the different services within an identity federation.</em></p>
+<p><a name="the-assurance-framework-and-levels-of-assurance"></a></p>
+<h3 id="12-the-assurance-framework-and-levels-of-assurance">1.2. The Assurance Framework and Levels of Assurance</h3>
+<p>The basis for the level of security applied when a user authenticates is the 
+<em>level of assurance</em> for the eID required by the service provider. In order for
+these levels to be comparable within the federation, four assurance levels are defined (1 to
+ 4) in the Swedish eID Assurance Framework [<a href="#trustframework">TrustFramework</a>] and three
+assurance levels (low, substantial, high) are defined by the EU regulation eIDAS. 
+Any service issuing identity assertions must prove that the process of issuing
+identity assertions meets the requirements of a given level. This includes:</p>
+<ul class="list">
+<li><p>  Requirements for the creation of an identity assertion.</p>
+</li>
+<li><p>  Requirements for electronic authentication.</p>
+</li>
+<li><p>  Requirements for the issuing process.</p>
+</li>
+<li><p>  Requirements for the actual eID and its use.</p>
+</li>
+<li><p>  Requirements on the issuer of the eID.</p>
+</li>
+<li><p>  Requirements for establishing the identity of the eID applicant.</p>
+</li>
+</ul>
+<p><a name="service-for-collection-administration-and-publishing-of-metadata"></a></p>
+<h3 id="13-service-for-collection-administration-and-publishing-of-metadata">1.3. Service for Collection, Administration and Publishing of Metadata</h3>
+<p>A SAML federation provides information about the federation
+participants through SAML metadata. Participants of a federation comprises of
+services providing identity and attributes assertions and relying parties, i.e., 
+service providers that consume these services.</p>
+<p>Through the federation&#39;s metadata, participants obtain information about others
+participants&#39; services, including the information required for a safe
+exchange of information between services. Metadata needs to be updated
+by each party and conform to agreed conditions.</p>
+<p>The main purpose of metadata is to provide the keys/certificates
+required for secure communication and information exchange between services.
+In addition to keys, metadata also contain other important information
+for collaboration between services, for example, addresses of required functions,
+information on assurance levels, service categories, user interface information, etc.</p>
+<p>An identity federation is defined by a register in XML format that is
+signed with the federation operator certificate. The file contains
+information on identity federation members including their
+certificates. Because the metadata file is signed, it is sufficient to
+compare a certificate with its equivalent in metadata. An
+infrastructure based on a central federation register requires
+that the register is constantly updated and that the members of the federation
+always use the latest version of the file.</p>
+<p><a name="discovery-service"></a></p>
+<h3 id="14-discovery-service">1.4. Discovery Service</h3>
+<p>Within an identity federation, it is possible to offer and consume a common
+Discovery Service, that lists which identity providers (or eID:s) that are 
+available for a user to choose from to authenticate. The purpose of such a
+service is to relieve the individual service providers that are part of the 
+identity federation from implementing support for how users choose how to
+authenticate.</p>
+<p>By making the discovery service available within the identity federation,
+service providers may direct its users there for the choice of how to authenticate.
+The discovery service interacts with the user who makes the choice and is
+directed back to the service provider, along with the selected authentication choice. 
+The service provider now knows to which identity provider the user should be directed
+to for authentication.</p>
+<blockquote>
+<p>Currently, there is no common discovery service available within the Sweden Connect federation.</p>
+</blockquote>
+<p><a name="relying-party-integration"></a></p>
+<h3 id="15-relying-party-integration">1.5. Relying Party Integration</h3>
+<p>Relying parties, e.g., service providers, integrate towards identity providers using
+standardized messages and consume identity assertions that also have a standardized
+format.</p>
+<p>The Swedish eID Framework is influenced by the interoperability profile
+”SAML V2.0 Deployment Profile for Federation Interoperability”
+[<a href="#saml2int">SAML2Int</a>]. This profile is supported by several commercial
+products and vendors as well as open source libraries. This facilitates
+the integration at the relying party side.</p>
+<p>Most relying parties use stand-alone authentication servers which means that
+the integration adaptation for supporting the Swedish eID Framework usually
+is limited to the authentication solution used.</p>
+<p><a name="signatures"></a></p>
+<h3 id="16-signatures">1.6. Signatures</h3>
+<p>The Swedish eID Framework enables digital signatures using any type of eID, even
+those not based on certificates, as long as there is an identity provider for 
+the particular eID. The reason for this is that the identity assertion that is
+used during authentication for signature is standardized.</p>
+<p>A Signature Service has as its purpose to offer digital signature services
+within identity federations that follows the Swedish eID Framework.</p>
+<p>By procuring<sup>1</sup> and introducing a signature service, a relying party within the 
+federation can offer users to sign electronic documents with the support
+of the signature service. The user signature, and associated signature certificate,
+is created by the signature service after the user has accepted to sign the
+document by authenticating for the signature service<sup>2</sup>.</p>
+<blockquote>
+<p>[1]: It is also possible for a relying party to implement a signature service based on the specifications.</p>
+</blockquote>
+<blockquote>
+<p>[2]: It is important to point out that it is of the utmost importance that the user 
+experiences that he or she is signing a document. Therefore, a signature flow should be 
+used for the eID types that support this during &quot;authentication for signature&quot;.</p>
+</blockquote>
+<p><a name="the-technical-framework-and-eidas"></a></p>
+<h3 id="17-the-technical-framework-and-eidas">1.7. The Technical Framework and eIDAS</h3>
+<p>The EU regulation (<a href="https://ec.europa.eu/futurium/en/system/files/ged/eidas_regulation.pdf">910/2014</a>)
+on electronic identification and trust services, eIDAS, places demands on Swedish 
+public bodies to recognize the eID:s that other eIDAS countries have notified. 
+This means that a public Swedish e-service based on certain rules must be able
+to accept a login that is performed with an eID issued in another country.</p>
+<p><a name="foreign-eid-authentication"></a></p>
+<h4 id="171-foreign-eid-authentication">1.7.1. Foreign eID Authentication</h4>
+<p>The eIDAS technical specifications is built, as for the Swedish eID
+Framework, upon SAML standards and profiles, and even though the
+similarities are many, there are also differences between the specifications.
+However, a Swedish service provider does not have top directly relate to
+the eIDAS specifications. The figure below illustrates how the Swedish
+eIDAS node (<em>eIDAS connector</em>) acts as a proxy between other countries
+and the Swedish federation when a person is authenticated using a foreign
+eID at a Swedish service provider.</p>
+<p class="img-container"><img src="img/eidas-flow-en.png" alt=""></p>
+<p>The flow is as follows:</p>
+<ol class="list">
+<li><p>A user with a foreign eID requests access to a Swedish service provider (i.e., wants to log in).</p>
+</li>
+<li><p>The service provider lets the user select the login method using a
+ discovery service. In this case the user chooses the &quot;Foreign eID&quot; option.</p>
+</li>
+<li><p>The service provider creates an authentication request according to
+ the Swedish eID Framework and directs the user to the Swedish eIDAS
+ node (<em>connector</em>). The eIDAS node acts as an identity provider within
+ the federation, which implies that the interaction with this service is
+ performed in the same way as for other identity providers that comply
+ with the Swedish eID Framework.</p>
+</li>
+<li><p>The received request is processes and the eIDAS node displays a page
+ where the user chooses his or hers country<sup>1</sup>. The Swedish
+ eIDAS node now transforms the received authentication request into an
+ authentication request according to the eIDAS format, and directs the
+ user to the selected country&#39;s <em>eIDAS Proxy Service</em>.</p>
+</li>
+<li><p>When the authentication request is processed by the eIDAS proxy service
+ of the selected country, this country&#39;s technique for authentication will
+ be used. Not all countries within eIDAS use SAML for authentication, but
+ if that was the case in our example, the user would be directed to a
+ national identity provider, and before that, maybe also a discovery service
+ where the eID to use would be selected.</p>
+</li>
+<li><p>When the user has authenticated an identity assertion, according to the
+ eIDAS specifications, is created. This assertion contains eIDAS specific
+ attribute that identify the user. This assertion is now posted back to the 
+ Swedish eIDAS node.</p>
+</li>
+<li><p>The node receives the assertion and validates its validity. The assertion is
+ transformed from eIDAS format to an assertion according to the Swedish eID Framework
+ and is posted back to the service provider.</p>
+</li>
+<li><p>The service provider may now complement the data with additional information
+ in order to decide whether the user should be granted access to the service.</p>
+</li>
+</ol>
+<p>Thus, Swedish services only have to implement support according to the Swedish eID
+Framework also when authenticating foreign users. However, in order for the service
+to fully accept the authenticated user it must also be able to handle the identity 
+presented, and this is most likely not a  Swedish personal identity number. See further
+section 1.7.3 below.</p>
+<blockquote>
+<p>[1]: The correct way to describe this would be to ask the user to which eIDAS Proxy
+Service to send the request to. This is dependent on the nationality of the user&#39;s
+eID issuer.</p>
+</blockquote>
+<p><a name="signing-using-a-foreign-eid"></a></p>
+<h4 id="172-signing-using-a-foreign-eid">1.7.2. Signing using a Foreign eID</h4>
+<p>As already described, a model for digital signatures named &quot;federated signatures&quot;
+is used within the context of the Swedish eID Framework. A server based signature
+service is associated with the e-service that is the requestor of signatures.
+When a user signs a document the e-service directs the user along with a signature 
+request to the signature service. The signature service now requests that the
+user authenticate (at an identity provider). In conjunction with the authentication
+the user approves the signature. The signature service then sends the user back to
+the e-service along with the signature data, and the e-service stores the signature
+as a signed document.</p>
+<p>This procedure makes it possible for Swedish e-services to offer signing för users
+having foreign eID:s, since a signature service can choose to authenticate the user
+having a foreign eID in accordance with the process described in section 1.7.1 above.</p>
+<p>In this case, the Swedish eIDAS node is responsible of informing the user that
+the purpose of the authentication is to approve the signature of a document,
+and displays information about the requestor of the signature and information
+about what is being signed. When the user has authenticated an identity assertion
+is issued and sent back to the signature service who now generates the signature.</p>
+<p><a name="handling-of-identities"></a></p>
+<h4 id="173-handling-of-identities">1.7.3. Handling of Identities</h4>
+<p>Identity assertions from other countries follow common technical
+specifications within the framework of the eIDAS regulations. These
+specifications define a <em>Minimum Dataset</em> (MDS) which is the a set of
+attributes that every country must supply for authenticated users and 
+legal entities. Each country must provide an unique identifier per eID
+that represents a natural person. For some countries, these identifiers
+will be unique and persistent per person in the same way as a Swedish
+personal identity number is, but identifiers may have different compositions
+and properties. A property that may vary is the persistence of an
+person identifier, i.e., whether such an identifier is unchanged during
+a person&#39;s lifetime, or whether it is changed because the user moves to
+another region, changes name, or simply obtains a new eID. For some
+countries (for example, Great Britain) the identifier will be different
+depending on which of the country&#39;s eID:s that user is currently using.</p>
+<p>In order to simplify the handling of users and identities in Swedish services
+the Swedish eIDAS node generates a standardized identity attribute for
+users that have been authenticated using a foreign eID, a so called 
+<em>Provisional ID</em> (PRID). The eIDAS node will also create an attribute
+that declares which persistence, or lifetime, the PRID attribute has.
+The PRID attribute is generated based on attributes values received from
+the foreign authentication according to specific methods for each country.
+Every combination of country and method a graded based on expected persistence,
+i.e., how likely it is that an identity for a person is changed over time.
+This makes it possible for Swedish services to customize the communication
+with the user and to proactively provide features for a user whose identity
+has changed, and make it possible for this user to access his or hers account.</p>
+<p>In some cases, a person that has been authenticated using a foreign eID may
+hold a Swedish personal identity number. It can, for example, be a Swedish
+citizen that has moved abroad and obtained a foreign eID, or a foreign
+citizen that is, or has been, registered (folkbokförd) in Sweden and has been
+assigned a Swedish personal identity number.</p>
+<p>The fact that a person holding a foreign eID possesses a Swedish personal identity
+number is normally not known to the foreign identity provider, and this information
+will not be part of the identity assertion from the foreign country. However, the
+Swedish eIDAS node has the possibility to query an attribute authority in Sweden<sup>1</sup>
+whether there exists a registered Swedish personal identity number for the person
+being authenticated, and may, if this is the case, add this information to the identity
+assertion that is sent back to the Swedish service provider.</p>
+<blockquote>
+<p>[1]: At the time of writing there is no attribute authority available
+providing Swedish personal identity numbers based on eIDAS attributes.</p>
+</blockquote>
+<p><a name="swedish-eids-in-foreign-services"></a></p>
+<h4 id="174-swedish-eids-in-foreign-services">1.7.4. Swedish eID:s in Foreign Services</h4>
+<p>Sweden has notified Swedish eID:s according to the assurance levels substantial and high. </p>
+<p>A request for authentication from a foreign service provider is sent to the Swedish 
+eIDAS node (<em>eIDAS proxy service</em>) via an eIDAS connector in the service provider country. 
+At the Swedish eIDAS node, the user chooses which Swedish eID he or she wants to use 
+to authenticate, and an authentication request is sent to the identity provider that
+offers authentication for the selected eID. This request is according to the Swedish
+eID Framework which means that a Swedish identity provider does not have to conform to
+the eIDAS technical specifications.</p>
+<p>The user is authenticated by the Swedish identity provider and an identity assertion
+is issued (according to the Swedish eID Framework). This assertion is received by the
+Swedish eIDAS node (proxy service), and transformed to an assertion according to the
+eIDAS specifications before being sent to the foreign eIDAS connector, and then to the
+initiating foreign service provider.</p>
+<p><a name="technical-specifications"></a></p>
+<h2 id="2-technical-specifications">2. Technical Specifications</h2>
+<p>This chapter contains specifications and profiles for identity federations and 
+related services that conforms to the Swedish eID Framework (Sweden Connect 
+Technical Framework). These documents are normative for the delivery of services 
+within identity federations that implement the Swedish eID Framework, unless 
+otherwise stated.</p>
+<p><a name="profiles-and-specifications-for-saml"></a></p>
+<h3 id="21-profiles-and-specifications-for-saml">2.1. Profiles and Specifications for SAML</h3>
+<p>Identity federations conforming to the Swedish eID Framework are built around
+”Deployment Profile for the Swedish eID Framework”, [<a href="#saml-profile">SAML.Profile</a>].
+This profile is influenced by, but not normatively dependent on, ”SAML V2.0 Deployment Profile for Federation Interoperability” [<a href="#saml2int">SAML2Int</a>]. [<a href="#saml-profile">SAML.Profile</a>] also contains rules and guidelines specific for the Swedish eID Framework.</p>
+<p><a name="deployment-profile-for-the-swedish-eid-framework"></a></p>
+<h4 id="211-deployment-profile-for-the-swedish-eid-framework">2.1.1. Deployment Profile for the Swedish eID Framework</h4>
+<p>The ”Deployment Profile for the Swedish eID Framework” specification, [<a href="#saml-profile">SAML.Profile</a>], 
+is the main specification of the eID Framework and comprises of:</p>
+<ul class="list">
+<li><p>How SAML metadata is constructed and interpreted.</p>
+</li>
+<li><p>How the format of an authentication request should be compiled.</p>
+</li>
+<li><p>How an authentication request should be processed, and how an identity assertion should be constructed, verified and processed.</p>
+</li>
+<li><p>Security requirements.</p>
+</li>
+<li><p>Specific SAML requirements for signature services and &quot;authentication for signature&quot;.</p>
+</li>
+</ul>
+<p><a name="swedish-eid-framework-registry-for-identifiers"></a></p>
+<h4 id="212-swedish-eid-framework---registry-for-identifiers">2.1.2. Swedish eID Framework - Registry for identifiers</h4>
+<p>The implementation of an infrastructure for Swedish eID:s demand different forms
+of identifiers to represent objects in data structures. The document
+”Sweden Connect - Registry for identifiers”, [<a href="#sc-registry">SC.Registry</a>],
+defines the structure for identifiers that are assigned within the scope of
+the Swedish eID Framework, and contains a registry of defined identifiers.</p>
+<p><a name="attribute-specification-for-the-swedish-eid-framework"></a></p>
+<h4 id="213-attribute-specification-for-the-swedish-eid-framework">2.1.3. Attribute Specification for the Swedish eID Framework</h4>
+<p>The specification ”Attribute Specification for the Swedish eID Framework”,
+[<a href="#saml-attributes">SAML.Attributes</a>], declares the SAML attribute profiles
+that are used within identity federations that follow the Swedish eID
+Framework, including services that connect to eIDAS using the Swedish eID
+node.</p>
+<p><a name="entity-categories-for-the-swedish-eid-framework"></a></p>
+<h4 id="214-entity-categories-for-the-swedish-eid-framework">2.1.4. Entity Categories for the Swedish eID Framework</h4>
+<p>Entity Categories are used within the federation for different purposes:</p>
+<ul class="list">
+<li><p>Service Entity Categories – Are used in metadata to represent service
+  provider requirements regarding assurance levels and attributes,
+  and identity provider declarations for supported assurance levels
+  and attribute release capabilities.</p>
+</li>
+<li><p>Service Property Categories – Are used to represent certain properties
+  of services within the federation.</p>
+</li>
+<li><p>Service Type Entity Categories – Represents different service types
+  within the federation.</p>
+</li>
+<li><p>Service Contract Entity Categories - Are used by services to declare
+  legal and business agreements.</p>
+</li>
+<li><p>General Entity Categories - Entity categories that do not fall within
+  the scope of any of the other types.</p>
+</li>
+</ul>
+<p>The specification ”Entity Categories for the Swedish eID Framework”
+[<a href="#saml-entcat">SAML.EntCat</a>] specifies the entity categories that are defined in
+the Swedish eID Framework and describes their meaning.</p>
+<p><a name="eidas-constructed-attributes-specification-for-the-swedish-eid-framework"></a></p>
+<h4 id="215-eidas-constructed-attributes-specification-for-the-swedish-eid-framework">2.1.5. eIDAS Constructed Attributes Specification for the Swedish eID Framework</h4>
+<p>The specification ”eIDAS Constructed Attributes Specification for the Swedish
+eID Framework”, [<a href="#sc-eidas-attrs">SC.eIDAS.Attrs</a>], defines processes and
+rules for how an identity attribute are constructed based on the attributes that are
+received during an eIDAS authentication.</p>
+<p><a name="bankid-profile"></a></p>
+<h4 id="216-implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">2.1.6. Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h4>
+<p>The specification &quot;Implementation Profile for BankID Identity Providers within the Swedish eID Framework&quot;, [<a href="#saml-bankid">SAML.BankID</a>], defines rules for identity providers that implement
+support for the Swedish BankID eID.</p>
+<blockquote>
+<p><strong>Note:</strong> This specification is not normative for conformance to the Swedish eID Framework.
+It is only relevant for identity providers implementing support for BankID and for service
+providers using those identity providers. However, an identity provider that implements BankID and wants to join the Sweden Connect federation must follow this specification.</p>
+</blockquote>
+<p><a name="principal-selection-in-saml-authentication-requests"></a></p>
+<h4 id="217-principal-selection-in-saml-authentication-requests">2.1.7. Principal Selection in SAML Authentication Requests</h4>
+<p>The specification &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#saml-principal">SAML.Principal</a>], defines an extension to SAML making it possible for a relying party
+to inform an identity provider about the identity of the user that it wishes to be authenticated.</p>
+<p><a name="user-message-extension-in-saml-authentication-requests"></a></p>
+<h4 id="218-user-message-extension-in-saml-authentication-requests">2.1.8. User Message Extension in SAML Authentication Requests</h4>
+<p>The specification &quot;User Message Extension in SAML Authentication Requests&quot;, [<a href="#saml-umessage">SAML.UMessage</a>], defines an extension to SAML making it possible for a relying party to pass along a display message in the authentication request being sent to the identity provider. The identity provider can then display a custom message for the user during the authentication phase.</p>
+<p><a name="profiles-and-specifications-for-openid-connect"></a></p>
+<h3 id="22-profiles-and-specifications-for-openid-connect">2.2. Profiles and Specifications for OpenID Connect</h3>
+<p><a name="openid-connect-profile-for-sweden-connect"></a></p>
+<h4 id="221-openid-connect-profile-for-sweden-connect">2.2.1. OpenID Connect Profile for Sweden Connect</h4>
+<p>The specification &quot;OpenID Connect Profile for Sweden Connect&quot;, [<a href="#oidc-profile">OIDC.Profile</a>], extends the <a href="https://www.oidc.se/specifications/swedish-oidc-profile-1_0.html">The Swedish OpenID Connect Profile</a> which is an OpenID Connect-profile published by <a href="https://www.oidc.se">OIDC Sweden</a> in order to facilitate interoperability and security for Swedish OIDC-deployments.</p>
+<p>[<a href="#oidc-profile">OIDC.Profile</a>] adds additional requirements for the Sweden Connect federation.</p>
+<p><a name="openid-connect-claims-and-scopes-specification-for-sweden-connect"></a></p>
+<h4 id="222-openid-connect-claims-and-scopes-specification-for-sweden-connect">2.2.2. OpenID Connect Claims and Scopes Specification for Sweden Connect</h4>
+<p>The specification &quot;OpenID Connect Claims and Scopes Specification for Sweden Connect&quot;, [<a href="#oidc-claims">OIDC.Claims</a>], extends the <a href="https://www.oidc.se/specifications/swedish-oidc-claims-specification-1_0.html">Claims and Scopes Specification for the Swedish OpenID Connect Profile</a> specification published by <a href="https://www.oidc.se">OIDC Sweden</a>. Specifically, the [<a href="#oidc-claims">OIDC.Claims</a>] add claims and scopes definitions for eIDAS.</p>
+<p><a name="signature-specifications"></a></p>
+<h3 id="23-signature-specifications">2.3. Signature Specifications</h3>
+<p>This section contains references to the documents that define signature services
+within federations conformant to the Swedish eID Framework.</p>
+<p><a name="implementation-profile-oasis-dss"></a></p>
+<h4 id="231-implementation-profile-for-using-oasis-dss-in-central-signing-services">2.3.1. Implementation Profile for using OASIS DSS in Central Signing Services</h4>
+<p>The implementation profile ”Implementation Profile for Using OASIS DSS in
+Central Signing Services”, [<a href="#sign-dss-profile">Sign.DSS.Profile</a>], specifies a profile
+for signature requests and responses according to the OASIS standard
+”Digital Signature Service Core Protocols, Elements, and Bindings”,
+[<a href="#dss">DSS</a>].</p>
+<p><a name="dss-extensions"></a></p>
+<h4 id="232-dss-extension-for-federated-central-signing-services">2.3.2. DSS Extension for Federated Central Signing Services</h4>
+<p>”DSS Extension for Federated Central Signing Services”, [<a href="#sign-dss-ext">Sign.DSS.Ext</a>], is an
+extension to the OASIS standard ”Digital Signature Service Core Protocols, Elements, and Bindings”, [<a href="#dss">DSS</a>], where definitions required for signatures according to the Swedish 
+eID Framework are specified.</p>
+<p><a name="certificate-profile-css"></a></p>
+<h4 id="233-certificate-profile-for-certificates-issued-by-central-signing-services">2.3.3. Certificate Profile for Certificates Issued by Central Signing Services</h4>
+<p>The certificate profile ”Certificate profile for certificates issued by Central Signing services”, [<a href="#sign-cert-profile">Sign.Cert.Profile</a>], specifies the contents of a signature certificate. This profile
+defines a certificate extension for use by signature services.</p>
+<p>This profile refers to &quot;Authentication Context Certificate Extension&quot;, [<a href="#authcontext">AuthContext</a>], 
+that describes how an ”Authentication Context” is represented in X.509 certificates.</p>
+<p><a name="signature-activation"></a></p>
+<h4 id="234-signature-activation-protocol-for-federated-signing">2.3.4. Signature Activation Protocol for Federated Signing</h4>
+<p>The specification &quot;Signature Activation Protocol for Federated Signing&quot;, [<a href="#sign-activation">Sign.Activation</a>], 
+defines a &quot;Signature Activation Protocol&quot; (SAP) for implementation of &quot;Sole Control Assurance Level 2&quot; (SCAL2) according to the standard &quot;prEN 419241 - Trustworthy Systems Supporting Server Signing&quot;.</p>
+<p><a name="references"></a></p>
+<h2 id="3-references">3. References</h2>
+<p><a name="digg"></a></p>
+<h3 id="31-digg">3.1. DIGG</h3>
+<p><a name="trustframework"></a>
+<strong>[TrustFramework]</strong></p>
+<blockquote>
+<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverk för Svensk e-legitimation</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
+</blockquote>
+<p><a name="saml-profile"></a>
+<strong>[SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-attributes"></a>
+<strong>[SAML.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-entcat"></a>
+<strong>[SAML.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-eidas-attrs"></a>
+<strong>[SC.eIDAS.Attrs]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID
+Framework</a>.</p>
+</blockquote>
+<p><a name="saml-bankid"></a>
+<strong>[SAML.BankID]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-principal"></a>
+<strong>[SAML.Principal]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="saml-umessage"></a>
+<strong>[SAML.UMessage]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="oidc-profile"></a>
+<strong>[OIDC.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/OIDC_-_Sweden_Connect_-_OpenID_Connect_Profile.html">OpenID Connect Profile for Sweden Connect</a>.</p>
+</blockquote>
+<p><a name="oidc-claims"></a>
+<strong>[OIDC.Claims]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/OIDC_-_Sweden_Connect_-_Claims_and_Scopes_Specification.html">OpenID Connect Claims and Scopes Specification for Sweden Connect</a>.</p>
+</blockquote>
+<p><a name="sign-dss-profile"></a>
+<strong>[Sign.DSS.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing
+Services</a>.</p>
+</blockquote>
+<p><a name="sign-dss-ext"></a>
+<strong>[Sign.DSS.Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sign-cert-profile"></a>
+<strong>[Sign.Cert.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing
+services</a>.</p>
+</blockquote>
+<p><a name="sign-activation"></a>
+<strong>[Sign.Activation]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="other-references"></a></p>
+<h3 id="32-other-references">3.2. Other references</h3>
+<p><a name="saml2int"></a>
+<strong>[SAML2Int]</strong></p>
+<blockquote>
+<p><a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML V2.0 Deployment Profile for Federation Interoperability</a>.</p>
+</blockquote>
+<p><a name="dss"></a>
+<strong>[DSS]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc">OASIS Standard – Digital Signature Service Core Protocols, Elements,
+and Bindings Version 1.0, April 11,
+2007</a>.</p>
+</blockquote>
+<p><a name="authcontext"></a>
+<strong>[AuthContext]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7773">RFC-7773: Authentication Context Certificate Extension</a>.</p>
+</blockquote>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html b/docs/december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html
new file mode 100644
index 0000000..ad1944b
--- /dev/null
+++ b/docs/december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html
@@ -0,0 +1,587 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>En introduktion till Sweden Connect Tekniskt ramverk</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="en-introduktion-till-sweden-connect-tekniskt-ramverk">En introduktion till Sweden Connect Tekniskt ramverk</h1>
+<h3 id="2024-12-04">2024-12-04</h3>
+<p>Diarienummer: <strong>2019-267</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">Myndigheten för digital förvaltning (Digg)</a>, 2015-2024.
+</p>
+
+<h2 id="innehållsförteckning">Innehållsförteckning</h2>
+<ol class="list">
+<li><p><a href="#introduktion"><strong>Introduktion</strong></a></p>
+<p> 1.1. <a href="#oeversikt">Översikt</a></p>
+<p> 1.2. <a href="#tillitsramverk-och-saekerhetsnivaaer">Tillitsramverk och säkerhetsnivåer</a></p>
+<p> 1.3. <a href="#tjaenst-foer-insamling-administration-och-publicering-av-metadata">Tjänst för insamling, administration och publicering av metadata</a></p>
+<p> 1.4. <a href="#anvisningstjaenst">Anvisningstjänst</a></p>
+<p> 1.5. <a href="#integration-hos-foerlitande-part">Integration hos förlitande part</a></p>
+<p> 1.6. <a href="#underskrift">Underskrift</a></p>
+<p> 1.7. <a href="#tekniskt-ramverk-och-eidas">Tekniskt ramverk och eIDAS</a></p>
+<p> 1.7.1. <a href="#autentiseringar-med-utlaendska-e-legitimationer">Autentiseringar med utländska e-legitimationer</a></p>
+<p> 1.7.2. <a href="#underskrifter-med-utlaendska-e-legitimationer">Underskrifter med utländska e-legitimationer</a></p>
+<p> 1.7.3. <a href="#hantering-av-identiteter">Hantering av identiteter</a></p>
+<p> 1.7.4. <a href="#svenska-e-legitimationer-i-utlaendska-e-tjaenster">Svenska e-legitimationer i utländska e-tjänster</a></p>
+</li>
+<li><p><a href="#tekniska-specifikationer"><strong>Tekniska specifikationer</strong></a></p>
+<p> 2.1. <a href="#profiler-och-specifikationer-for-saml">Profiler och specifikationer för SAML</a></p>
+<p> 2.1.1. <a href="#deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</a></p>
+<p> 2.1.2. <a href="#swedish-eid-framework-registry-for-identifiers">Swedish eID Framework - Registry for identifiers</a></p>
+<p> 2.1.3. <a href="#attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</a></p>
+<p> 2.1.4. <a href="#entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</a></p>
+<p> 2.1.5. <a href="#eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a></p>
+<p> 2.1.6. <a href="#bankid-profile">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a></p>
+<p> 2.1.7. <a href="#principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</a></p>
+<p> 2.1.8. <a href="#user-message-extension-in-saml-authentication-requests">User Message Extension in SAML Authentication Requests</a></p>
+<p> 2.2. <a href="#profiler-och-specifikationer-for-openid-connect">Profiler och specifikationer för OpenID Connect</a></p>
+<p> 2.2.1. <a href="#openid-connect-profile-for-sweden-connect">OpenID Connect Profile for Sweden Connect</a></p>
+<p> 2.2.2. <a href="#openid-connect-claims-and-scopes-specification-for-sweden-connect">OpenID Connect Claims and Scopes Specification for Sweden Connect</a></p>
+<p> 2.3. <a href="#specifikationer-foer-underskrift">Specifikationer för Underskrift</a></p>
+<p> 2.3.1. <a href="#implementation-profile-oasis-dss">Implementation Profile for using OASIS DSS in Central Signing Services</a></p>
+<p> 2.3.2. <a href="#dss-extensions">DSS Extension for Federated Central Signing Services</a></p>
+<p> 2.3.3. <a href="#certificate-profile-css">Certificate Profile for Certificates Issued by Central Signing Services
+</a></p>
+<p> 2.3.4. <a href="#signature-activation">Signature Activation Protocol for Federated Signing</a></p>
+</li>
+<li><p><a href="#referenslista"><strong>Referenslista</strong></a></p>
+<p> 3.1. <a href="#digg">DIGG</a></p>
+<p> 3.2. <a href="#oevriga-referenser">Övriga referenser</a></p>
+</li>
+</ol>
+<p><a name="introduktion"></a></p>
+<h2 id="1-introduktion">1. Introduktion</h2>
+<p><a name="oeversikt"></a></p>
+<h3 id="11-översikt">1.1. Översikt</h3>
+<p>Sweden Connect Tekniskt Ramverk är anpassat för
+identitetsfederationer som baseras på SAML 2.0.</p>
+<blockquote>
+<p>I den senaste versionen av Tekniskt ramverk har även specifikationer för OpenID Connect introducerats. För närvarande finns inget federationsstöd för OpenID Connect. Detta kommer att introduceras under 2025. </p>
+</blockquote>
+<blockquote>
+<p>Resterande delar av detta dokument beskriver endast SAML-federationen. Då OpenID Connect introduceras fullt ut kommer även detta dokument att beskriva denna teknik. </p>
+</blockquote>
+<p>Förlitande parter erhåller identitetsintyg i ett standardiserat format
+från en legitimeringstjänst<sup>1</sup>.</p>
+<p>E-tjänster som kräver underskrift behöver inte anpassas efter olika 
+användares e-legitimationer för att skapa elektroniska underskrifter. 
+Istället överlåter e-tjänsten detta till en underskriftstjänst där användare 
+med stöd av legitimering via en legitimeringstjänst ges möjlighet att underteckna
+elektroniska handlingar.</p>
+<p>Inom federationen intar e-tjänster och motsvarande förlitande parter
+rollen som Service Provider (SP) medan legitimeringstjänster som
+utfärdar identitetsintyg intar rollen som Identity Provider (IdP) och
+därmed den som autentiserar användaren, oavsett mot vilken e-tjänst som
+användaren legitimerar sig.</p>
+<p>För de fall där e-tjänsten behöver mer information om användaren t ex.
+uppgift om juridisk behörighet, kan en fråga ställas till en
+attributtjänst, Attribute Authority (AA), inom federationen, om sådan
+relevant attributtjänst finns. Genom en attributsförfrågan kan
+e-tjänsten erhålla nödvändig kompletterande information för att kunna
+auktorisera användaren och ge tillgång till e-tjänsten eller
+motsvarande.</p>
+<p>Då såväl personidentitetsuppgifter som andra attribut kopplat till
+användare tillhandahålls genom identitetsintyg och attributsintyg, kan
+alla typer av e-legitimationer som förlitande part har avtal om och som
+ingår i federationen användas för legitimering mot en e-tjänst som
+kräver såväl personnummer som ytterligare information, även om 
+e-legitimationen inte innehåller några specifika personuppgifter 
+(t.ex. koddosor för generering av engångslösenord).</p>
+<p class="img-container"><img src="img/sweeid-overview1.png" alt=""></p>
+<p>Figur 1: <em>Illustration av kommunikationen mellan de olika tjänsterna inom
+en identitetsfederation.</em></p>
+<blockquote>
+<p>[1]: Legitimeringstjänst benämns i annan dokumentation från Digg också som identitetstjänst och intygstjänst. I detta dokument används dock uteslutande benämningen legitimeringstjänst.</p>
+</blockquote>
+<p><a name="tillitsramverk-och-saekerhetsnivaaer"></a></p>
+<h3 id="12-tillitsramverk-och-säkerhetsnivåer">1.2. Tillitsramverk och säkerhetsnivåer</h3>
+<p>Grunden för vilken säkerhetsnivå som tillämpas när en användare
+legitimerar sig är den tillitsnivå avseende e-legitimationen som
+e-tjänsten kräver. För att dessa säkerhetsnivåer ska kunna vara
+jämförbara inom ramen för federationen definieras fyra tillitsnivåer (1
+– 4) i Tillitsramverket för Svensk e-legitimation [<a href="#digg-tillit">Digg.Tillit</a>] och tre
+tillitsnivåer (låg, väsentlig, hög) i EU-förordningen eIDAS. Alla som
+utfärdar identitetsintyg måste visa att hela den process som ligger till
+grund för utfärdandet av identitetsintyg uppfyller kraven i den
+efterfrågade tillitsnivån, detta innefattar bl.a.</p>
+<ul class="list">
+<li><p>  Krav på skapandet av identitetsintyget.</p>
+</li>
+<li><p>  Krav på den elektroniska legitimeringen (autentiseringen).</p>
+</li>
+<li><p>  Krav på utfärdandeprocessen.</p>
+</li>
+<li><p>  Krav på själva e-legitimationen och dess användning.</p>
+</li>
+<li><p>  Krav på utfärdaren av e-legitimationen.</p>
+</li>
+<li><p>  Krav på fastställande av den e-legitimationssökandens identitet.</p>
+</li>
+</ul>
+<p><a name="tjaenst-foer-insamling-administration-och-publicering-av-metadata"></a></p>
+<h3 id="13-tjänst-för-insamling-administration-och-publicering-av-metadata">1.3. Tjänst för insamling, administration och publicering av metadata</h3>
+<p>En SAML-federation tillhandahåller information om federationens
+deltagare genom SAML metadata. Som deltagare i en federation räknas
+såväl aktörer som levererar legitimerings- och attributtjänster i
+federationen som förlitande parter, d.v.s. aktörer som konsumerar dessa
+tjänster, t ex. e-tjänster.</p>
+<p>Genom federationens metadata kan deltagare inhämta information om andra
+deltagares tjänster, inklusive de uppgifter som krävs för ett säkert
+informationsutbyte mellan deltagarna. Metadata måste hållas uppdaterat
+av respektive part och överensstämma med avtalade förhållanden.</p>
+<p>Det viktigaste syftet med metadata är att tillhandahålla de nycklar/certifikat 
+som krävs för säker kommunikation och informationsutväxling mellan tjänster.
+Utöver nycklar innehåller metadata även annan information som är viktig
+för samverkan mellan tjänster t ex. adresser till funktioner som krävs,
+information om tillitsnivåer, tjänstekategorier,
+användargränssnittsinformation mm.</p>
+<p>En identitetsfederation definieras av ett register i XML-format som är
+signerat med federationsoperatörens certifikat. Filen innehåller
+information om identitetsfederationens medlemmar inklusive deras
+certifikat. Eftersom filen med metadata är signerad räcker det med att
+jämföra ett certifikat med dess motsvarighet i metadata. En
+infrastruktur baserad på ett centralt federationsregister förutsätter
+att registret uppdateras kontinuerligt samt att federationsmedlemmarna
+alltid använder den senaste versionen av filen.</p>
+<p><a name="anvisningstjaenst"></a></p>
+<h3 id="14-anvisningstjänst">1.4. Anvisningstjänst</h3>
+<p>I en identitetsfederation är det möjligt att erbjuda och konsumera en
+gemensam anvisningstjänst (Discovery Service), som listar vilka
+legitimeringstjänster som är möjliga för användaren att välja mellan.
+Syftet med en sådan anvisningstjänst är att avlasta de enskilda
+e-tjänsterna som ingår i identitetsfederationen från att själva
+implementera stöd för hur användare väljer legitimeringstjänst (eller
+inloggningsmetod).</p>
+<p>Genom att anvisningstjänsten finns tillgänglig inom
+identitetsfederationen kan e-tjänster styra sina användare dit för val
+av legitimeringstjänst. Anvisningstjänsten interagerar med användaren
+som gör sitt val och användaren, tillsammans med dennes val, styrs
+tillbaka till e-tjänsten som nu vet till vilken legitimeringstjänst
+användaren ska skickas för legitimering.</p>
+<blockquote>
+<p>För närvarande finns ingen gemensam anvisningstjänst för Sweden Connect-federationen.</p>
+</blockquote>
+<p><a name="integration-hos-foerlitande-part"></a></p>
+<h3 id="15-integration-hos-förlitande-part">1.5. Integration hos förlitande part</h3>
+<p>Förlitandeparter, t.ex. e-tjänster, integrerar mot legitimeringstjänster
+genom standardiserade meddelanden och konsumerar identitetsintyg vilka
+också har standardiserade format.</p>
+<p>Sweden Connect tekniskt ramverk är influerad av interoperabilitetsprofilen 
+”SAML V2.0 Deployment Profile for Federation Interoperability”
+[<a href="#saml2int">SAML2Int</a>]. Profilen stöds av ett flertal kommersiella 
+produkter och Open Source-lösningar, vilket underlättar integrationsarbetet
+hos e-tjänster.</p>
+<p>Många e-tjänster använder fristående autentiseringslösningar vilket
+innebär att en anpassning av integrationen för att följa
+tekniskt ramverk får en begränsad påverkan på e-tjänsten som sådan.</p>
+<p><a name="underskrift"></a></p>
+<h3 id="16-underskrift">1.6. Underskrift</h3>
+<p>Vid underskrift blir det med Sweden Connect tekniskt ramverk
+möjligt att använda olika typer av e-legitimationer, även sådana som
+inte är certifikatbaserade, utan att speciella anpassningar i e-tjänsten
+behövs. Anledningen är att det är det elektroniskt utställda
+identitetsintyget (som används för identifiering av användare vid
+underskrift) har samma format oavsett vilken typ av e-legitimation som
+användaren använder.</p>
+<p>En underskriftstjänst har som syfte att möjliggöra underskrift inom
+identitetsfederationer som följer tekniskt ramverk med stöd av alla 
+typer av e-legitimationer som erbjuder tillräcklig grad av säkerhet.</p>
+<p>Genom att upphandla<sup>1</sup> och införa en underskriftstjänst kan en förlitande
+part som ingår i federationen låta en användare skriva under en
+elektronisk handling med stöd av underskriftstjänsten.
+Användarens elektroniska signatur och tillhörande signeringscertifikat
+skapas av underskriftstjänsten efter det att användaren accepterat att
+skriva under genom att legitimera sig mot underskriftstjänsten<sup>2</sup>.</p>
+<blockquote>
+<p>[1]: Det är också möjligt att själv implementera en underskriftstjänst baserat på specifikationerna i tekniskt ramverk, eller på annat sätt införskaffa en underskriftstjänst.</p>
+</blockquote>
+<blockquote>
+<p>[2]: Viktigt att påpeka är att det är av största vikt att användaren upplever det som att denne skriver under en handling. Därför ska ett underskriftsflöde användas för de e-legitimationer som stödjer detta i samband med &quot;legitimering för underskrift&quot;.</p>
+</blockquote>
+<p><a name="tekniskt-ramverk-och-eidas"></a></p>
+<h3 id="17-tekniskt-ramverk-och-eidas">1.7. Tekniskt ramverk och eIDAS</h3>
+<p>EU-förordningen (<a href="http://eur-lex.europa.eu/legal-content/SV/TXT/PDF/?uri=CELEX:32014R0910&from=EN">910/2014</a>) om elektronisk identifiering och betrodda
+tjänster, eIDAS, ställer krav på svenska offentliga organ att erkänna de
+e-legitimationer som andra eIDAS-länder har anmält. Detta innebär att en
+offentlig svensk e-tjänst baserat på vissa regler skall kunna acceptera
+en inloggning som utförs med en e-legitimation utställd i ett annat
+land.</p>
+<p><a name="autentiseringar-med-utlaendska-e-legitimationer"></a></p>
+<h4 id="171-autentiseringar-med-utländska-e-legitimationer">1.7.1. Autentiseringar med utländska e-legitimationer</h4>
+<p>De tekniska specifikationerna för eIDAS bygger, såsom
+tekniskt ramverk, på SAML-standarder, och även
+om likheterna är många finns även skillnader i dessa specifikationer. En
+svensk e-tjänst ska dock inte förhålla sig direkt till eIDAS tekniska
+specifikationer. Nedanstående bild illustrerar hur
+den svenska eIDAS-noden (<em>eIDAS-connector</em>) agerar som en brygga
+mellan andra länder och den svenska federationen då en person autentiseras
+med en utländsk e-legitimation mot en svensk e-tjänst.
+Den svenska eIDAS-noden följer tekniskt ramverk.</p>
+<p class="img-container"><img src="img/eidas-flow.png" alt=""></p>
+<p>Flödet är enligt följande:</p>
+<ol class="list">
+<li><p>En användare med en utländsk e-legitimation begär åtkomst till en
+ svensk e-tjänst (d.v.s., loggar in).</p>
+</li>
+<li><p>E-tjänsten låter användaren välja inloggningssätt med hjälp av en
+ anvisningstjänst. Ett val ”Foreign eID” visas upp, vilket användaren
+ i eIDAS-fallet väljer.</p>
+</li>
+<li><p>E-tjänsten skapar en legitimeringsbegäran enligt detta tekniska
+ ramverk och styr användaren till den svenska eIDAS-noden (<em>connector</em>)
+ som DIGG ansvarar för. eIDAS-noden uppträder som
+ en legitimeringstjänst (<em>Identity Provider</em>) i federationen in
+ mot svenska förlitande parter vilket innebär att kommunikation med
+ denna tjänst utförs på samma sätt som mot övriga
+ legitimeringstjänster inom federationer som följer tekniskt ramverk.</p>
+</li>
+<li><p>Den mottagna begäran behandlas och eIDAS-noden visar upp en valsida
+ där användaren väljer ”sitt land”<sup>1</sup>. Den svenska eIDAS-noden
+ omvandlar nu den mottagna legitimeringsbegäran till en
+ legitimeringsbegäran enligt eIDAS och användaren styrs till det
+ valda landets ”eIDAS Proxy-tjänst”.</p>
+</li>
+<li><p>Då legitimeringsbegäran mottas av den eIDAS-Proxy-tjänst för valt
+ land tar detta lands teknik för autentisering över. Inte alla länder
+ inom eIDAS använder SAML för autentisering, men om så var fallet i
+ vårt exempel skulle användaren styras vidare till en
+ legitimeringstjänst (<em>Identity Provider</em>), och innan dess kanske även
+ en anvisningstjänst för val av legitimeringstjänst.</p>
+</li>
+<li><p>Då en autentisering utförts skapas ett intyg (<em>Assertion</em>) enligt
+ eIDAS specifikationer. Detta intyg innehåller bl.a. eIDAS-specifika
+ attribut som identifierar användaren. Detta intyg styrs nu vidare till
+ den svenska eIDAS-noden.</p>
+</li>
+<li><p>Noden tar emot intyget och validerar dess korrekthet. Detta intyg
+ transformeras från eIDAS-format till ett intyg utformat
+ enligt tekniskt ramverk och postas till e-tjänsten.</p>
+</li>
+<li><p>Förlitande part kompletterar eventuellt med ytterligare information
+ och avgör om användaren ska ges till åtkomst till tjänsten.</p>
+</li>
+</ol>
+<p>Svenska e-tjänster behöver således endast stödja 
+tekniskt ramverk för att kunna hantera en autentisering utförd med en
+europeisk e-legitimation. Dock måste e-tjänsten kunna hantera den
+identitet som presenteras, vilket inte nödvändigtvis är ett personnummer. 
+Det kan alltså hända att en e-tjänst autentiserar en användare via 
+eIDAS-ramverket, men att användarens
+presenterade identitet inte går att använda hos e-tjänsten. Mer om detta
+i kapitlet 1.7.3 nedan.</p>
+<blockquote>
+<p>[1]: Egentligen väljer användaren till vilken ”eIDAS Proxy-tjänst” som begäran ska skickas vidare till. Detta är beroende landstillhörigheten för användarens e-legitimationsutfärdare.</p>
+</blockquote>
+<p><a name="underskrifter-med-utlaendska-e-legitimationer"></a></p>
+<h4 id="172-underskrifter-med-utländska-e-legitimationer">1.7.2. Underskrifter med utländska e-legitimationer</h4>
+<p>Som redan beskrivits tillämpas en modell för
+elektronisk underskrift inom ramen för detta tekniska ramverk
+som kallas federerad underskrift. En
+serverbaserad underskriftstjänst knyts till e-tjänsten som i sin tur
+begär underskrift. När en användare skriver under ett dokument skickar
+e-tjänsten en underskriftsbegäran till underskriftstjänsten.
+Underskriftstjänsten begär därefter att användaren legitimerar sig. I
+samband med legitimeringen godkänner användaren underskriften.
+Underskriftstjänsten skickar tillbaka uppgifter till e-tjänsten och
+därefter lagras underskriftsuppgifterna kopplade till den handling som
+har skrivits under.</p>
+<p>Detta förfarande möjliggör att skriva under även med utländsk
+e-legitimation då underskriftstjänsten kan välja att legitimera
+användaren med utländsk e-legitimation i enlighet med förfarandet som
+beskrivs ovan i avsnitt 1.7.1.</p>
+<p>Vid en underskrift ansvarar i det fallet den svenska eIDAS-noden för att
+användaren upplyses om att syftet med legitimeringen är att skriva under
+ett dokument, vem som begärt underskrift samt med eventuell information
+om vad som undertecknas. Först när användaren genom att legitimera sig
+(för underskrift) utfärdas ett identitetsintyg, som skickas till
+underskriftstjänsten och som i sin tur genererar underskriften.</p>
+<p><a name="hantering-av-identiteter"></a></p>
+<h4 id="173-hantering-av-identiteter">1.7.3. Hantering av identiteter</h4>
+<p>Identitetsintyg från andra länder följer EU-gemensamma tekniska
+specifikationer framtagna inom ramen för eIDAS-regelverket. Här
+specificeras de attribut som varje land alltid måste skicka med för
+fysiska personer såväl som för organisationer (”Minimum Dataset”, MDS).
+Varje land måste skicka med en unik identifierare per e-legitimation som
+representerar endast en fysisk person. Från vissa länder kommer dessa
+identifierare vara unika och beständiga per person på motsvarande sätt
+som t.ex. svenska personnummer, men dessa identifierare kan ha vitt
+skilda sammansättningar och ha väldigt olika egenskaper. En egenskap som
+kan variera är hur persistent en sådan identifierare är, d.v.s., om en
+sådan identifierare är oförändrad under en persons livstid eller om den
+ändras om personen exempelvis flyttar till en annan region, byter namn
+eller bara byter e-legitimation. Från några länder (t.ex.
+Storbritannien) kommer identifieraren att vara olika beroende på vilken
+av landets e-legitimationer en användare för tillfället väljer att
+använda.</p>
+<p>För att förenkla hanteringen av användare i svenska e-tjänster
+genererar den svenska eIDAS-noden ett standardiserat ID-attribut för
+användare som legitimerats med utländsk e-legitimation, ett s.k.
+<em>provisional ID</em> (förkortat PRID). Dessutom skapas ett tillhörande
+attribut som deklarerar vilken förväntad persistens, eller livslängd,
+detta ID-attribut har. PRID-attributet genereras utifrån de
+attributvärden som erhålls från den utländska legitimeringen enligt
+specificerade metoder för respektive land. Varje kombination av land och
+metod klassas med avseende på förväntad persistens, d.v.s., hur
+sannolikt det är att en identitet ändras över tiden för samma person.
+Detta gör det möjligt för svenska e-tjänster att anpassa kommunikationen
+med användaren och proaktivt tillhandahålla funktioner som underlättar
+för en användare vars identitet har ändrats, att återfå kontrollen över
+sin information i e-tjänsten.</p>
+<p>I vissa fall kan en person som legitimeras med en utländsk
+e-legitimation även inneha ett svenskt personnummer. Det kan till exempel 
+röra sig om en svensk medborgare som flyttat utomlands och skaffat utländsk e-legitimation
+eller en utländsk medborgare som är folkbokförd i Sverige och har tilldelats ett
+personnummer.</p>
+<p>Det faktum att en person med utländsk e-legitimation innehar ett svenskt
+personnummer är normalt sett inte känt för den
+utländska legitimeringstjänsten och denna information ingår därför inte
+i identitetsintyg från landet där personen legitimeras. Den svenska
+noden har däremot möjlighet att fråga en attributtjänst i Sverige<sup>1</sup> om
+det finns ett registrerat personnummer för den
+legitimerade personen och kan, om så är fallet, påföra sådan information
+i det identitetsintyg som skickas till e-tjänsten.</p>
+<blockquote>
+<p>[1]: I skrivande stund finns ingen attributtjänst som utför koppling mellan eIDAS-identiteter och svenska personnummer.</p>
+</blockquote>
+<p><a name="svenska-e-legitimationer-i-utlaendska-e-tjaenster"></a></p>
+<h4 id="174-svenska-e-legitimationer-i-utländska-e-tjänster">1.7.4. Svenska e-legitimationer i utländska e-tjänster</h4>
+<p>Sverige har anmält svenska e-legitimationer på tillitsnivå väsentlig (substantial) och hög (high) enligt eIDAS. </p>
+<p>En begäran om legitimering från en utländsk e-tjänst ställs till den svenska eIDAS-noden (proxy-tjänst) via en s.k. eIDAS-connector i e-tjänstens land. 
+I den svenska eIDAS-noden väljer användaren med vilken svensk e-legitimation denne önskar autentisera sig, varpå en legitimeringsbegäran till den legitimeringstjänst (<em>Identity Provider</em>) som hanterar vald e-legitimation skickas. Denna begäran är utformad enligt tekniskt ramverk vilket innebär att en svensk legitimeringstjänst inte behöver förhålla sig till eIDAS tekniska specifikationer.</p>
+<p>Användaren autentiseras hos den svenska legitimeringstjänsten och ett identitetsintyg ställs ut (enligt tekniskt ramverk). Detta intyg mottas av den svenska eIDAS Proxy-tjänsten och omvandlas till ett intyg enligt eIDAS specifikationer innan det skickas vidare till den utländska eIDAS-connectorn och därpå till den anropande e-tjänsten (<em>Service Provider</em>).</p>
+<p><a name="tekniska-specifikationer"></a></p>
+<h2 id="2-tekniska-specifikationer">2. Tekniska specifikationer</h2>
+<p>Detta kapitel innehåller specifikationer och profiler för
+identitetsfederationer som följer Sweden Connect tekniskt
+ramverk, och vissa kringliggande tjänster. Där inget annat nämns är
+dessa dokument normativa för leverans av tjänster inom
+identitetsfederationer som implementerar 
+tekniskt ramverk.</p>
+<p><a name="profiler-och-specifikationer-for-saml"></a></p>
+<h3 id="21-profiler-och-specifikationer-för-saml">2.1. Profiler och specifikationer för SAML</h3>
+<p>Identitetsfederationer som följer Sweden Connect tekniska ramverk är uppbyggda
+kring ”Deployment Profile for the Swedish eID Framework”, [<a href="#saml-profile">SAML.Profile</a>]. Denna profil är influerad av, men inte normativt beroende på, ”SAML V2.0 Deployment Profile for Federation Interoperability” [<a href="#saml2int">SAML2Int</a>]. [<a href="#saml-profile">SAML.Profile</a>] innehåller också regler och riktlinjer specifika för Sweden Connect tekniskt ramverk. </p>
+<p><a name="deployment-profile-for-the-swedish-eid-framework"></a></p>
+<h4 id="211-deployment-profile-for-the-swedish-eid-framework">2.1.1. Deployment Profile for the Swedish eID Framework</h4>
+<p>”Deployment Profile for the Swedish eID Framework”, [<a href="#saml-profile">SAML.Profile</a>], är huvuddokumentet för tekniskt ramverk och specificerar bland annat:</p>
+<ul class="list">
+<li><p>Hur SAML metadata ska byggas upp och tolkas.</p>
+</li>
+<li><p>Hur formatet av en legitimeringsbegäran ska se ut.</p>
+</li>
+<li><p>Hur en legitimeringsbegäran ska behandlas, och hur ett identitetsintyg ska konstrueras, verifieras och behandlas.</p>
+</li>
+<li><p>Krav på säkerhet.</p>
+</li>
+<li><p>Specifika SAML-krav för underskriftstjänster och &quot;legitimering för underskrift&quot;.</p>
+</li>
+</ul>
+<p><a name="swedish-eid-framework-registry-for-identifiers"></a></p>
+<h4 id="212-swedish-eid-framework---registry-for-identifiers">2.1.2. Swedish eID Framework - Registry for identifiers</h4>
+<p>Implementering av en infrastruktur för Svensk e-legitimation kräver
+olika former av identifierare för att representera objekt i
+datastrukturer. Dokumentet ”Sweden Connect - Registry for identifiers”, [<a href="#sc-registry">SC.Registry</a>], definierar strukturen
+för identifierare som tilldelats inom ramen för tekniskt ramverk, samt ett
+register över definierade identifierare.</p>
+<p><a name="attribute-specification-for-the-swedish-eid-framework"></a></p>
+<h4 id="213-attribute-specification-for-the-swedish-eid-framework">2.1.3. Attribute Specification for the Swedish eID Framework</h4>
+<p>Specifikationen ”Attribute Specification for the Swedish eID Framework”,
+[<a href="#saml-attributes">SAML.Attributes</a>], deklarerar de SAML attributprofiler som används inom
+identitetsfederationer som följer tekniskt ramverk inklusive de som
+ansluter till eIDAS via den svenska eIDAS-noden.</p>
+<p><a name="entity-categories-for-the-swedish-eid-framework"></a></p>
+<h4 id="214-entity-categories-for-the-swedish-eid-framework">2.1.4. Entity Categories for the Swedish eID Framework</h4>
+<p>Entitetskategorier (Entity Categories) används inom federationen för ett antal olika
+syften:</p>
+<ul class="list">
+<li><p>Service Entity Categories – Används i metadata för att
+  representera e-tjänsters krav på tillitsnivåer och begärda attribut,
+  samt legitimeringstjänsters uppfyllande av tillitsnivåer och
+  leverans av attribut.</p>
+</li>
+<li><p>Service Property Categories – Används för att representera en viss
+  egenskap hos en tjänst.</p>
+</li>
+<li><p>Service Type Entity Categories – Används för att representera olika
+  tjänstetyper inom federationen.</p>
+</li>
+<li><p>Service Contract Entity Categories - Används av tjänster för att annonsera 
+  avtalsformer och liknande.</p>
+</li>
+<li><p>General Entity Categories - Entitetskategorier som inte faller inom ramen
+  för någon av de ovanstående typerna.</p>
+</li>
+</ul>
+<p>Specifikationen ”Entity Categories for the Swedish eID Framework”
+[<a href="#saml-entcat">SAML.EntCat</a>] specificerar de entitetskategorier som definieras av tekniskt ramverk och beskriver dess betydelse.</p>
+<p><a name="eidas-constructed-attributes-specification-for-the-swedish-eid-framework"></a></p>
+<h4 id="215-eidas-constructed-attributes-specification-for-the-swedish-eid-framework">2.1.5. eIDAS Constructed Attributes Specification for the Swedish eID Framework</h4>
+<p>Specifikationen ”eIDAS Constructed Attributes Specification for the Swedish
+eID Framework”, [<a href="#sc-eidas-attrs">SC.eIDAS.Attrs</a>], specificerar processer och regler
+för hur ID-attribut konstrueras baserat på attribut som tas emot vid
+legitimering mot eIDAS.</p>
+<p><a name="bankid-profile"></a></p>
+<h4 id="216-implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">2.1.6. Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h4>
+<p>Specifikationen &quot;Implementation Profile for BankID Identity Providers within the Swedish eID Framework&quot;, [<a href="#saml-bankid">SAML.BankID</a>], definierar regler för hur en legitimeringstjänst som implementerar stöd för BankID skall utformas.</p>
+<blockquote>
+<p><strong>Notera:</strong> Denna specifikation är inte normativ för uppfyllande av tekniskt ramverk. Den är endast relevant för legitimeringstjänster som implementerar stöd för BankID samt e-tjänster som använder dessa. Dock så skall legitimeringstjänster som implementerar stöd för BankID och vill ansluta till Sweden Connect-federationen uppfylla denna specifikation.</p>
+</blockquote>
+<p><a name="principal-selection-in-saml-authentication-requests"></a></p>
+<h4 id="217-principal-selection-in-saml-authentication-requests">2.1.7. Principal Selection in SAML Authentication Requests</h4>
+<p>Specifikationen &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#saml-principal">SAML.Principal</a>], definierar en utökning till SAML som möjliggör för en förlitande part att informera en legitimeringstjänst vilken identitet den önskar ska legitimeras.</p>
+<p><a name="user-message-extension-in-saml-authentication-requests"></a></p>
+<h4 id="218-user-message-extension-in-saml-authentication-requests">2.1.8. User Message Extension in SAML Authentication Requests</h4>
+<p>Specifikationen &quot;User Message Extension in SAML Authentication Requests&quot;, [<a href="#saml-umessage">SAML.UMessage</a>], definierar en utökning till SAML som möjliggör för en förlitande part att inkludera ett visningsmeddelande i den legitimeringsbegäran som skickas till legitimeringstjänsten. Legitimeringstjänsten kan då visa upp detta meddelande för använderen under legitimeringssteget.</p>
+<p><a name="profiler-och-specifikationer-for-openid-connect"></a></p>
+<h3 id="22-profiler-och-specifikationer-för-openid-connect">2.2. Profiler och specifikationer för OpenID Connect</h3>
+<p><a name="openid-connect-profile-for-sweden-connect"></a></p>
+<h4 id="221-openid-connect-profile-for-sweden-connect">2.2.1. OpenID Connect Profile for Sweden Connect</h4>
+<p>Profilen &quot;OpenID Connect Profile for Sweden Connect&quot;, [<a href="#oidc-profile">OIDC.Profile</a>], bygger vidare på <a href="https://www.oidc.se/specifications/swedish-oidc-profile-1_0.html">The Swedish OpenID Connect Profile</a> som är en OpenID Connect-profil framtagen av <a href="https://www.oidc.se">OIDC Sweden</a> för att främja interoperabilitet och säkerhet inom svenska OIDC-lösningar.</p>
+<p>[<a href="#oidc-profile">OIDC.Profile</a>] tillför ytterligare krav gällande Sweden Connect-federationen.</p>
+<p><a name="openid-connect-claims-and-scopes-specification-for-sweden-connect"></a></p>
+<h4 id="222-openid-connect-claims-and-scopes-specification-for-sweden-connect">2.2.2. OpenID Connect Claims and Scopes Specification for Sweden Connect</h4>
+<p>Specifikationen &quot;OpenID Connect Claims and Scopes Specification for Sweden Connect&quot;, [<a href="#oidc-claims">OIDC.Claims</a>], bygger vidare på specifikationen <a href="https://www.oidc.se/specifications/swedish-oidc-claims-specification-1_0.html">Claims and Scopes Specification for the Swedish OpenID Connect Profile</a> från <a href="https://www.oidc.se">OIDC Sweden</a>.</p>
+<p><a name="specifikationer-foer-underskrift"></a></p>
+<h3 id="23-specifikationer-för-underskrift">2.3. Specifikationer för Underskrift</h3>
+<p>Detta stycke innehåller referenser till de dokument vilka definierar
+underskriftstjänster inom federationer som följer Sweden Connect tekniskt
+ramverk.</p>
+<p><a name="implementation-profile-oasis-dss"></a></p>
+<h4 id="231-implementation-profile-for-using-oasis-dss-in-central-signing-services">2.3.1. Implementation Profile for using OASIS DSS in Central Signing Services</h4>
+<p>Implementationsprofilen ”Implementation Profile for Using OASIS DSS in
+Central Signing Services”, [<a href="#sign-dss-profile">Sign.DSS.Profile</a>], specificerar en profil för
+underskriftsbegäran och respons enligt OASIS standarden &quot;Digital
+Signature Service Core Protocols, Elements, and Bindings&quot;,
+[<a href="#dss">DSS</a>].</p>
+<p><a name="dss-extensions"></a></p>
+<h4 id="232-dss-extension-for-federated-central-signing-services">2.3.2. DSS Extension for Federated Central Signing Services</h4>
+<p>”DSS Extension for Federated Central Signing Services”, [<a href="#sign-dss-ext">Sign.DSS.Ext</a>], är en påbyggnad av 
+OASIS standarden ”Digital Signature Service Core Protocols, Elements, and Bindings”, [<a href="#dss">DSS</a>], där definitioner som behövs för underskrift enligt tekniskt ramverk specificeras.</p>
+<p><a name="certificate-profile-css"></a></p>
+<h4 id="233-certificate-profile-for-certificates-issued-by-central-signing-services">2.3.3. Certificate Profile for Certificates Issued by Central Signing Services</h4>
+<p>Certifikatprofilen ”Certificate profile for certificates issued by Central Signing services”, [<a href="#sign-cert-profile">Sign.Cert.Profile</a>], specificerar innehåll i signeringscertifikat. Denna profil tillämpar en
+ny certifikatextension till stöd för underskriftstjänster.</p>
+<p>Denna profil refererar till &quot;Authentication Context Certificate Extension&quot;, [<a href="#authcontext">AuthContext</a>], vilken beskriver hur ”Authentication Context” representeras i X.509 certifikat.</p>
+<p><a name="signature-activation"></a></p>
+<h4 id="234-signature-activation-protocol-for-federated-signing">2.3.4. Signature Activation Protocol for Federated Signing</h4>
+<p>Specifikationen &quot;Signature Activation Protocol for Federated Signing&quot;, [<a href="#sign-activation">Sign.Activation</a>], definierar ett &quot;Signature Activation Protocol&quot; (SAP) för implementation av &quot;Sole Control Assurance Level 2&quot; (SCAL2) enligt standarden &quot;prEN 419241 - Trustworthy Systems Supporting Server Signing&quot;.</p>
+<p><a name="referenslista"></a></p>
+<h2 id="3-referenslista">3. Referenslista</h2>
+<p><a name="digg"></a></p>
+<h3 id="31-digg">3.1. DIGG</h3>
+<p><a name="digg-tillit"></a>
+<strong>[Digg.Tillit]</strong></p>
+<blockquote>
+<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverk för Svensk e-legitimation</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
+</blockquote>
+<p><a name="saml-profile"></a>
+<strong>[SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-attributes"></a>
+<strong>[SAML.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-entcat"></a>
+<strong>[SAML.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-eidas-attrs"></a>
+<strong>[SC.eIDAS.Attrs]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID
+Framework</a>.</p>
+</blockquote>
+<p><a name="saml-bankid"></a>
+<strong>[SAML.BankID]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="saml-principal"></a>
+<strong>[SAML.Principal]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="saml-umessage"></a>
+<strong>[SAML.UMessage]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="oidc-profile"></a>
+<strong>[OIDC.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/OIDC_-_Sweden_Connect_-_OpenID_Connect_Profile.html">OpenID Connect Profile for Sweden Connect</a>.</p>
+</blockquote>
+<p><a name="oidc-claims"></a>
+<strong>[OIDC.Claims]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/OIDC_-_Sweden_Connect_-_Claims_and_Scopes_Specification.html">OpenID Connect Claims and Scopes Specification for Sweden Connect</a>.</p>
+</blockquote>
+<p><a name="sign-dss-profile"></a>
+<strong>[Sign.DSS.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sign-dss-ext"></a>
+<strong>[Sign.DSS.Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sign-cert-profile"></a>
+<strong>[Sign.Cert.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing
+services</a>.</p>
+</blockquote>
+<p><a name="sign-activation"></a>
+<strong>[Sign.Activation]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="oevriga-referenser"></a></p>
+<h3 id="32-övriga-referenser">3.2. Övriga referenser</h3>
+<p><a name="saml2int"></a>
+<strong>[SAML2Int]</strong></p>
+<blockquote>
+<p><a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML V2.0 Deployment Profile for Federation Interoperability</a>.</p>
+</blockquote>
+<p><a name="dss"></a>
+<strong>[DSS]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc">OASIS Standard – Digital Signature Service Core Protocols, Elements,
+and Bindings Version 1.0, April 11,
+2007</a>.</p>
+</blockquote>
+<p><a name="authcontext"></a>
+<strong>[AuthContext]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7773">RFC-7773: Authentication Context Certificate Extension</a>.</p>
+</blockquote>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html b/docs/december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
new file mode 100644
index 0000000..7252968
--- /dev/null
+++ b/docs/december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
@@ -0,0 +1,1594 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Deployment Profile for the Swedish eID Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</h1>
+<h3 id="version-18---2024-12-04">Version 1.8 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-308</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.2. <a href="#references-to-saml-2.0-standards-and-profiles">References to SAML 2.0 Standards and Profiles</a></p>
+</li>
+<li><p><a href="#metadata-and-trust-management"><strong>Metadata and Trust Management</strong></a></p>
+<p> 2.1. <a href="#requirements-for-metadata-content">Requirements for Metadata Content</a></p>
+<p> 2.1.1. <a href="#generic">Generic</a></p>
+<p> 2.1.2. <a href="#service-providers">Service Providers</a></p>
+<p> 2.1.3. <a href="#identity-providers">Identity Providers</a></p>
+<p> 2.1.4. <a href="#signature-service">Signature Service</a></p>
+</li>
+<li><p><a href="#name-identifiers"><strong>Name Identifiers</strong></a></p>
+</li>
+<li><p><a href="#attributes"><strong>Attributes</strong></a></p>
+</li>
+<li><p><a href="#authentication-requests"><strong>Authentication Requests</strong></a></p>
+<p> 5.1. <a href="#discovery">Discovery</a></p>
+<p> 5.2. <a href="#binding-and-security-requirements">Binding and Security Requirements</a></p>
+<p> 5.3. <a href="#message-content">Message Content</a></p>
+<p> 5.3.1. <a href="#requested-authentication-context">Requested Authentication Context</a></p>
+<p> 5.3.2. <a href="#scoping">Scoping</a></p>
+<p> 5.3.3. <a href="#principal-selection">Principal Selection</a></p>
+<p> 5.4. <a href="#processing-requirements">Processing Requirements</a></p>
+<p> 5.4.1. <a href="#validation-of-destination">Validation of Destination</a></p>
+<p> 5.4.2. <a href="#validation-of-assertion-consumer-addresses">Validation of Assertion Consumer Addresses</a></p>
+<p> 5.4.3. <a href="#identity-provider-user-interface">Identity Provider User Interface</a></p>
+<p> 5.4.4. <a href="#authentication-context-and-level-of-assurance-handling">Authentication Context and Level of Assurance Handling</a></p>
+<p> 5.4.5. <a href="#single-sign-on-processing">Single Sign On Processing</a></p>
+</li>
+<li><p><a href="#authentication-responses"><strong>Authentication Responses</strong></a></p>
+<p> 6.1. <a href="#security-requirements">Security Requirements</a></p>
+<p> 6.2. <a href="#message-content2">Message Content</a></p>
+<p> 6.2.1. <a href="#attribute-release-and-consuming-rules">Attribute Release and Consuming Rules</a></p>
+<p> 6.2.2. <a href="#message-content-requirements-for-holder-of-key">Message Content Requirements for Holder-of-key</a></p>
+<p> 6.3. <a href="#processing-requirements2">Processing Requirements</a></p>
+<p> 6.3.1. <a href="#signature-validation">Signature Validation</a></p>
+<p> 6.3.2. <a href="#subject-confirmation">Subject Confirmation</a></p>
+<p> 6.3.3. <a href="#conditions">Conditions</a></p>
+<p> 6.3.4. <a href="#the-authentication-statement">The Authentication Statement</a></p>
+<p> 6.3.5. <a href="#general-security-validation">General Security Validation</a></p>
+<p> 6.4. <a href="#error-responses">Error Responses</a></p>
+</li>
+<li><p><a href="#authentication-for-signature"><strong>Authentication for Signature</strong></a></p>
+<p> 7.1. <a href="#authentication-requests2">Authentication Requests</a></p>
+<p> 7.1.1. <a href="#requesting-display-of-signature-message">Requesting Display of Signature Message</a></p>
+<p> 7.1.2. <a href="#requesting-scal2-signature-activation-data">Requesting SCAL2 Signature Activation Data</a></p>
+<p> 7.2. <a href="#authentication-responses2">Authentication Responses</a></p>
+</li>
+<li><p><a href="#cryptographic-algorithms"><strong>Cryptographic Algorithms</strong></a></p>
+<p> 8.1. <a href="#digest-algorithms">Digest Algorithms</a></p>
+<p> 8.2. <a href="#signature-algorithms">Signature Algorithms</a></p>
+<p> 8.3. <a href="#block-encryption-algorithms">Block Encryption Algorithms</a></p>
+<p> 8.4. <a href="#key-transport-algorithms">Key Transport Algorithms</a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This profile specifies behaviour and options that deployments of the SAML
+V2.0 Web Browser SSO Profile, [<a href="#saml2prof">SAML2Prof</a>], and the SAML V2.0 Holder-of-key
+Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>],
+are required or permitted to rely on. The requirements specified in this profile
+are in addition to the underlying normative requirements of [<a href="#saml2prof">SAML2Prof</a>]
+and [<a href="#saml2hokprof">SAML2HokProf</a>] (including updates to these specifications provided by [<a href="#saml2errata05">SAML v2.0 Errata 05</a>]).</p>
+<blockquote>
+<p>Note: The profile is influenced by, but not normatively dependent on, <a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML2Int</a>.</p>
+</blockquote>
+<p>Readers should be familiar with all relevant reference documents, and
+any requirements stated are not repeated unless where deemed necessary
+to clarify or highlight a certain issue.</p>
+<p>Any SAML features specified in referenced SAML documents that are
+optional are out of scope of this profile, unless explicitly specified
+by this profile.</p>
+<p><a name="requirements-notation"></a></p>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The keywords &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
+&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
+document are to be interpreted as described in
+[<a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>].</p>
+<p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
+on deployment practices intended to foster both interoperability and
+guarantees of security and confidentiality needed to satisfy the
+requirements of many organizations that engage in the use of federated
+identity. Deviating may limit a deployment&#39;s ability to technically
+interoperate without additional negotiation, and should be undertaken
+with caution.</p>
+<p><a name="references-to-saml-2.0-standards-and-profiles"></a></p>
+<h3 id="12-references-to-saml-20-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
+<p>When referring to elements from the SAML 2.0 core specification
+[<a href="#saml2core">SAML2Core</a>], the following syntax is used:</p>
+<ul class="list">
+<li><p><code>&lt;saml2p:Protocolelement&gt;</code> – for elements from the SAML 2.0
+  Protocol namespace.</p>
+</li>
+<li><p><code>&lt;saml2:Assertionelement&gt;</code> – for elements from the SAML 2.0
+  Assertion namespace.</p>
+</li>
+</ul>
+<p>When referring to elements from the SAML 2.0 metadata specifications,
+the following syntax is used:</p>
+<ul class="list">
+<li><p>  <code>&lt;md:Metadataelement&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
+</li>
+<li><p>  <code>&lt;mdui:Element&gt;</code> – for elements defined in [<a href="#saml2metaui">SAML2MetaUI</a>].</p>
+</li>
+<li><p>  <code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
+</li>
+<li><p> <code>&lt;alg:Element&gt;</code> – for elements defined in [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>].</p>
+</li>
+</ul>
+<p>When referring to elements from the SAML V2.0 Holder-of-key Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>], the following syntax is used:</p>
+<ul class="list">
+<li><code>&lt;hoksso:ProtocolBinding&gt;</code> - for elements from the SAML V2.0 Web Browser Holder-of-key namespace.</li>
+</ul>
+<p>When referring to elements from the &quot;Identity Provider Discovery Service Protocol and Profile&quot; specification [<a href="#idpdisco">IdpDisco</a>], the following syntax is used:</p>
+<ul class="list">
+<li><code>&lt;idpdisc:DiscoveryResponse&gt;</code></li>
+</ul>
+<p>When referring to the <code>Scope</code> element defined in the &quot;Subject Identifier Attributes Profile&quot; specification, [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>], the following syntax is used:</p>
+<ul class="list">
+<li><code>&lt;shibmd:Scope&gt;</code></li>
+</ul>
+<p>When referring to elements from the W3C XML Signature namespace
+(<code>http://www.w3.org/2000/09/xmldsig\#</code>) the following syntax is used:</p>
+<ul class="list">
+<li>  <code>&lt;ds:Signature&gt;</code></li>
+</ul>
+<p><strong>Note</strong>: For all references to core SAML specifications, direct or indirect, the [<a href="#saml2errata05">SAML v2.0 Errata 05</a>] MUST always be considered.</p>
+<p><a name="metadata-and-trust-management"></a></p>
+<h2 id="2-metadata-and-trust-management">2. Metadata and Trust Management</h2>
+<p>Identity Providers and Service Providers conformant with this profile MUST provide a SAML 2.0 Metadata document representing its entity. The provided metadata MUST conform to &quot;Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0&quot;, [<a href="#saml2meta">SAML2Meta</a>], and SHOULD follow &quot;SAML v2.0 Metadata Profile for Algorithm Support Version 1.0&quot;, [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>].</p>
+<p>Services conforming to this profile MUST be able to consume SAML metadata on an automated and periodic basis using the processing rules defined by &quot;SAML V2.0 Metadata Interoperability Profile Version 1.0&quot; [<a href="#saml2metaiop">SAML2MetaIOP</a>]. Automatic consumption of metadata MUST be followed by a successful signature verification of the downloaded metadata before it is trusted and used. </p>
+<p><a name="requirements-for-metadata-content"></a></p>
+<h3 id="21-requirements-for-metadata-content">2.1. Requirements for Metadata Content</h3>
+<p><a name="generic"></a></p>
+<h4 id="211-generic">2.1.1. Generic</h4>
+<p><a name="display-information"></a></p>
+<h5 id="2111-display-information">2.1.1.1. Display Information</h5>
+<p>All services that are represented in the Metadata SHALL include a
+<code>&lt;md:Organization&gt;</code> element with mandatory child elements, which
+includes at least one of each of the elements
+<code>&lt;md:OrganizationName&gt;</code>, <code>&lt;md:OrganizationDisplayName&gt;</code> and
+<code>&lt;md:OrganizationURL&gt;</code>.</p>
+<p>The <code>&lt;md:OrganizationName&gt;</code> element SHALL hold a registered name of
+the organization, which matches the agreement with the federation
+operator.</p>
+<p>The <code>&lt;md:OrganizationDisplayName&gt;</code> element SHALL contain a display
+name of the organization and SHALL NOT contain a service name that is
+unrelated to the name of the organization.</p>
+<p>Metadata for an entity SHALL contain an <code>&lt;mdui:UIInfo&gt;</code>
+extension, extending the <code>&lt;md:SPSSODescriptor&gt;</code> or <code>&lt;md:IDPSSODescriptor&gt;</code> element 
+(depending on the type of the entity). This <code>&lt;mdui:UIInfo&gt;</code> element SHALL at least contain a
+<code>&lt;mdui:DisplayName&gt;</code> element with the language attribute <code>sv</code>
+(Swedish), representing the entity name that has been approved
+by the federation operator. The <code>&lt;mdui:UIInfo&gt;</code> element SHALL also
+contain a reference to one, or more, logotype images (<code>&lt;mdui:Logo&gt;</code>) as described in section 2.1.5
+of [<a href="#saml2metaui">SAML2MetaUI</a>] and SHOULD
+contain a <code>&lt;mdui:Description&gt;</code> element with the language attribute
+<code>sv</code> (Swedish).</p>
+<p>It is RECOMMENDED that the above elements represented in Swedish also be
+represented with the language attribute <code>en</code> (English).</p>
+<p>A federation operator may impose further requirements regarding the <code>&lt;mdui:UIInfo&gt;</code> extension.</p>
+<p><a name="certificates-in-metadata"></a></p>
+<h5 id="2112-certificates-in-metadata">2.1.1.2. Certificates in Metadata</h5>
+<p>Public keys used for signature validation and encryption MUST be expressed via X.509
+certificates included in metadata as <code>&lt;ds:X509Certificate&gt;</code> child elements to
+<code>&lt;md:KeyDescriptor&gt;</code> elements. These certificates merely acts as containers for the public keys 
+needed for signature validation and encryption and the consumer of a metadata entry cannot
+expect to be able to execute a successful certificate path validation of such certificates.
+A metadata consumer MUST NOT reject a metadata entry due to that certificate trust is missing,
+the certificate is expired, or certificate revocation information is missing.</p>
+<p>However, for interoperability reasons it is RECOMMENDED that:</p>
+<ul class="list">
+<li>self-signed certificates are used,</li>
+<li>non-expired certificates (with a long validity time) are used,</li>
+<li>certificates are not signed with MD5- och SHA1-based signature algorithms. </li>
+</ul>
+<p>All services represented in metadata SHOULD include at least one <code>&lt;md:KeyDescriptor&gt;</code> 
+element holding a certificate to be used for signature validation (with the <code>use</code>-attribute
+set to <code>signing</code>), and one <code>&lt;md:KeyDescriptor&gt;</code> element containing a certificate 
+to be used for message encryption (with the <code>use</code>-attribute set to <code>encryption</code>).
+It is allowed to use the same key and certificate for both usages, but in order to enable
+a future key rollover it is RECOMMENDED to avoid using only one <code>&lt;md:KeyDescriptor&gt;</code> element
+for both usages (i.e., with an absent <code>use</code>-attribute).</p>
+<p>In order to facilitate key rollover of a signing key, a service MUST support multiple signing 
+certificates found in peer metadata and MUST support signature validation using a key from 
+any of the available peer signature certificates.</p>
+<p>For key rollover of encryption keys, the service that is performing the key rollover MUST only
+publish the latest key (in a certificate) to its metadata entry. Until all peers have consumed
+the service&#39;s metadata entry containing the new certificate, the service MUST support decrypting 
+messages using both the old and new key.</p>
+<p><a name="declaring-algorithm-support"></a></p>
+<h5 id="2113-declaring-algorithm-support">2.1.1.3. Declaring Algorithm Support</h5>
+<p>Services MAY declare encryption and signature capabilities as defined in [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>]. The declared algorithms MUST meet the algorithm requirements defined by the Sweden Connect Framework or by the federation operator . Thus, it is not allowed to declare an algorithm, or key size, that is prohibited from use. </p>
+<p>All services conformant with this specification MUST support the mandatory algorithms defined by the Sweden Connect Framework, meaning that a service has no possibility to opt-out from a certain mandatory algorithm by excluding it from the declared capabilities. The main purpose of declaring an algorithm using any of the elements <code>&lt;md:EncryptionMethod&gt;</code>, <code>&lt;alg:SigningMethod&gt;</code> or <code>&lt;alg:DigestMethod&gt;</code> is to declare which algorithm the service prefers.</p>
+<p><a name="service-providers"></a></p>
+<h4 id="212-service-providers">2.1.2. Service Providers</h4>
+<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of a Service Provider’s
+entity descriptor SHOULD contain one entity category attribute
+[<a href="#entcat">EntCat</a>] that holds at least
+one attribute value representing a service entity category as defined in
+[<a href="#sc-entcat">SC.EntCat</a>], identifying the Service Provider requirements in relation to
+identity services concerning attribute release and level of assurance.</p>
+<p>The example below illustrates how an entity declares the service entity
+category identifier <strong><code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></strong> in its
+metadata.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
+                     <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>
+                     <span class="hljs-attr">xmlns:saml2</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+        http://id.elegnamnden.se/ec/1.0/loa3-pnr
+      <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p>If a Service Provider does not have any attribute requirements other than those
+implicitly requested by inclusion of one or more service entity categories, the
+metadata entry of the Service Provider SHOULD NOT include a
+<code>&lt;md:AttributeConsumingService&gt;</code> element (with <code>&lt;md:RequestedAttribute&gt;</code> 
+elements). </p>
+<p>Any needs for particular attributes from Identify Providers, when
+present, MUST be expressed through present service entity categories in
+combination with <code>&lt;md:RequestedAttribute&gt;</code> elements under the
+<code>&lt;md:AttributeConsumingService&gt;</code> element in the Service
+Provider metadata. The <code>&lt;md:RequestedAttribute&gt;</code> elements in the
+Service Provider metadata, when present, hold a list of requested and/or
+required attributes. This list of attributes MUST be interpreted in the
+context of present service entity categories defined in [<a href="#sc-entcat">SC.EntCat</a>].</p>
+<blockquote>
+<p>Note: Only the requirements for attributes that are not implicitly requested through a declared
+service entity category need to be expressed as <code>&lt;md:RequestedAttribute&gt;</code> elements.</p>
+</blockquote>
+<p>A Service Provider MAY sign authentication request messages sent to
+Identity Providers. A Service Provider that signs authentication
+requests messages MAY also ensure that a receiving Identity Provider
+will only accept valid signed requests from this Service Provider by
+assigning the <code>AuthnRequestsSigned</code> attribute of the
+<code>&lt;md:SPSSODescriptor&gt;</code> to a value of <code>true</code>.</p>
+<p>Section E7, “Metadata for Agreeing to Sign Authentication Requests”, of
+[<a href="#saml2errata05">SAML v2.0 Errata 05</a>]
+specifies the following concerning the <code>AuthnRequestsSigned</code> attribute:</p>
+<blockquote>
+<p>Optional attribute that indicates whether the
+<code>&lt;saml2p:AuthnRequest&gt;</code> messages sent by this Service Provider
+will be signed. If omitted, the value is assumed to be false. A value
+of false (or omission of this attribute) does not imply that the
+Service Provider will never sign its requests or that a signed request
+should be considered an error. However, an Identity Provider that
+receives an unsigned <code>&lt;saml2p:AuthnRequest&gt;</code> message from a
+Service Provider whose metadata contains this attribute with a value
+of true MUST return a SAML error response and MUST NOT fulfill the
+request.</p>
+</blockquote>
+<p>Furthermore, a Service Provider MAY require assertions that are issued
+to it, to be signed. This is done by assigning the <code>WantAssertionsSigned</code>
+attribute of the <code>&lt;md:SPSSODescriptor&gt;</code> to a value of <code>true</code>.</p>
+<p>Note that the response message that carries the assertion will always be
+signed, so the Service Provider should only require signed assertions in
+case that it wants to preserve the proof of authenticity of an assertion
+separate from the response.</p>
+<p>A Service Provider wishing to make use of a central discovery service as specified in the &quot;Identity Provider Discovery Service Protocol Profile&quot; [<a href="#idpdisco">IdPDisco</a>] MUST include at least one <code>&lt;idpdisc:DiscoveryResponse&gt;</code> element as an extension under the <code>&lt;md:SPSSODescriptor&gt;</code> element. </p>
+<p><a name="sp-holder-of-key-support"></a></p>
+<h5 id="2121-holder-of-key-support">2.1.2.1. Holder of Key Support</h5>
+<p>A Service Provider that sends authentication requests using the Holder-of-key Web Browser SSO Profile MUST include a <code>&lt;md:AssertionConsumerService&gt;</code> element in its metadata according to section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+<p>If the Service Provider also makes use of the ordinary Web Browser SSO Profile at least one <code>&lt;md:AssertionConsumerService&gt;</code> element according to section 2.4.4 of [<a href="#saml2meta">SAML2Meta</a>] MUST also be included in the Service Provider metadata. </p>
+<p>In those cases, where a Service Provider supports both profiles, it is RECOMMENDED that the a <code>&lt;md:AssertionConsumerService&gt;</code> element for ordinary Web Browser SSO Profile is marked as default.</p>
+<pre class="hljs"><code>&lt;md:AssertionConsumerService <span class="hljs-attribute">index</span>=<span class="hljs-string">&quot;0&quot;</span> <span class="hljs-attribute">isDefault</span>=<span class="hljs-string">&quot;true&quot;</span>
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot;</span>
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://sp.example.org/path1&quot;</span> /&gt;
+
+&lt;md:AssertionConsumerService <span class="hljs-attribute">index</span>=<span class="hljs-string">&quot;1&quot;</span> <span class="hljs-attribute">isDefault</span>=<span class="hljs-string">&quot;false&quot;</span>   
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>   
+  xmlns:<span class="hljs-attribute">hoksso</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span> 
+  hoksso:<span class="hljs-attribute">ProtocolBinding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot;</span> 
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span> 
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://sp.example.org/path2&quot;</span> /&gt;</code></pre><p><em>Example of a Service Provider&#39;s declared AssertionConsumerService elements; one for receiving assertions according the Web Browser SSO Profile and one for receiving assertions according to the Holder-of-key Web Browser SSO Profile.</em></p>
+<p><a name="identity-providers"></a></p>
+<h4 id="213-identity-providers">2.1.3. Identity Providers</h4>
+<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of an Identity Provider’s
+entity descriptor SHOULD contain one entity category attribute
+[<a href="#entcat">EntCat</a>] that holds at least
+one attribute value representing a service entity category as defined in
+[<a href="#sc-entcat">SC.EntCat</a>], defining the Identity Provider ability to deliver
+assertions (defining the level of assurance and attribute release).</p>
+<p>If an Identity Provider has the ability to release attributes, other than those
+implicitly given by the declared service entity categories, it is RECOMMENDED that 
+those attributes are declared as <code>&lt;saml:Attribute&gt;</code> elements under the 
+<code>&lt;md:IDPSSODescriptor&gt;</code> element. </p>
+<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of an Identity Provider’s
+metadata SHALL contain an attribute according to
+[<a href="#saml2iap">SAML2IAP</a>] with its <code>Name</code> attribute set to 
+<code>urn:oasis:names:tc:SAML:attribute:assurance-certification</code>
+and holding at least one attribute value identifying a Level of Assurance
+(LoA) for which the Identity Provider has been approved. 
+The Sweden Connect Framework defines such identifier values in section 3.1.1 of
+[<a href="#sc-registry">SC.Registry</a>] and their meanings are defined in [<a href="#se-trust">SE.Trust</a>].</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:attribute:assurance-certification&quot;</span>
+                    <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>
+                    <span class="hljs-attr">xmlns:saml</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xsd:string&quot;</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>
+    ...
+  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p><em>Example of how an Identity Provider advertises that the service delivers authentication according to
+the <code>http://id.elegnamnden.se/loa/1.0/loa3</code> level of assurance.</em></p>
+<p>An Identity Provider MAY require authentication request messages to be
+signed. This is indicated by assigning the
+<code>WantAuthnRequestsSigned</code> attribute of the <code>&lt;md:IDPSSPDescriptor&gt;</code>
+element to a value of <code>true</code>. See further section E7, “Metadata for
+Agreeing to Sign Authentication Requests”, of [<a href="#saml2errata05">SAML v2.0 Errata
+05</a>].</p>
+<p>Identity Providers SHALL advertise support for the SAP protocol according to [<a href="#sc-sap">SC.SAP</a>], by including the service property entity category URI
+<code>http://id.elegnamnden.se/sprop/1.0/scal2</code> in its metadata. An Identity Provider that does not advertise support for SAP MAY ignore requests for SAD.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span> 
+                    <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>
+                    <span class="hljs-attr">xmlns:saml</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>http://id.elegnamnden.se/sprop/1.0/scal2<span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>
+    ...
+  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p><em>Example of how an Identity Provider advertises its support for SCAL2 authentication.</em></p>
+<p>An Identity Provider that wishes to receive the <code>&lt;psc:PrincipalSelection&gt;</code> extension in authentication requests SHOULD include the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> extension extending the <code>&lt;md:IDPSSODescriptor&gt;</code> element. In this extension the Identity Provider declares which attribute value(s) it wants to receive in authentication requests from requestors using the <code>&lt;psc:PrincipalSelection&gt;</code> authentication request extension. See <a href="#principal-selection">section 5.3.3</a> and [<a href="#sc-principal">SC.Principal</a>].</p>
+<p><a name="declaring-authorized-scopes"></a></p>
+<h5 id="2131-declaring-authorized-scopes">2.1.3.1. Declaring Authorized Scopes</h5>
+<p>An Identity Provider that releases &quot;scoped attributes&quot;, see section 3.1.3 of [<a href="#sc-attributes">SC.Attributes</a>],
+MUST be authorized to do so by the federation operator. Each authorized scope MUST be declared in the Identity Provider metadata entry using a <code>&lt;shibmd:Scope&gt;</code> element, see section 3.5.2, &quot;Scope Filtering&quot;, in [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>]. The <code>&lt;shibmd:Scope&gt;</code> elements MUST appear within the <code>&lt;md:Extensions&gt;</code> element of the <code>&lt;md:IDPSSODescriptor&gt;</code>.</p>
+<pre class="hljs"><code>&lt;md:IDPSSODescriptor ...&gt;
+  &lt;md:<span class="hljs-keyword">Extensions&gt;
+</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">&quot;false&quot;</span> xmlns:<span class="hljs-keyword">shibmd=&quot;urn:mace:shibboleth:metadata:1.0&gt;2021006883&lt;/shibmd:Scope&gt;
+</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">&quot;false&quot;</span> xmlns:<span class="hljs-keyword">shibmd=&quot;urn:mace:shibboleth:metadata:1.0&gt;2021006255&lt;/shibmd:Scope&gt;
+</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">&quot;false&quot;</span> xmlns:<span class="hljs-keyword">shibmd=&quot;urn:mace:shibboleth:metadata:1.0&gt;example.com&lt;/shibmd:Scope&gt;
+</span>    ...</code></pre><p><em>Example of how an Identity Provider declares that it is authorized to deliver scoped attributes for three different scopes; two organizational numbers and one domain.</em></p>
+<p><a name="idp-holder-of-key-support"></a></p>
+<h5 id="2132-holder-of-key-support">2.1.3.2. Holder of Key Support</h5>
+<p>An Identity Provider that supports the Holder-of-key Web Browser SSO Profile MUST declare <code>&lt;md:SingleSignOnService&gt;</code> elements<sup>*</sup> in its metadata according to section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+<p>If the Identity Provider also supports authentication according the ordinary Web Browser SSO Profile <code>&lt;md:SingleSignOnService&gt;</code> elements<sup>*</sup> according to section 2.4.3 of [<a href="#saml2meta">SAML2Meta</a>] MUST also be included in the Identity Provider metadata.</p>
+<pre class="hljs"><code>&lt;md:SingleSignOnService
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect&quot;</span>
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://idp.example.org/path1&quot;</span> /&gt;
+  
+&lt;md:SingleSignOnService
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot;</span>
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://idp.example.org/path2&quot;</span> /&gt;
+  
+&lt;md:SingleSignOnService
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>
+  xmlns:<span class="hljs-attribute">hoksso</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span>
+  hoksso:<span class="hljs-attribute">ProtocolBinding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect&quot;</span> 
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span>
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://idp.example.org/path2&quot;</span> /&gt;
+  
+&lt;md:SingleSignOnService
+  xmlns:<span class="hljs-attribute">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>
+  xmlns:<span class="hljs-attribute">hoksso</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span>
+  hoksso:<span class="hljs-attribute">ProtocolBinding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot;</span> 
+  <span class="hljs-attribute">Binding</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser&quot;</span>
+  <span class="hljs-attribute">Location</span>=<span class="hljs-string">&quot;https://idp.example.org/path2&quot;</span> /&gt;</code></pre><p><em>Example of an Identity Provider&#39;s declared SingleSignOnService elements; two for receiving requests according to the Web Browser SSO Profile and two for receiving requests according to the Holder-of-key Web Browser SSO Profile.</em></p>
+<blockquote>
+<p>[*]: This profile requires an Identity Provider to support both the POST and Redirect bindings, see section <a href="#binding-and-security-requirements">5.2</a> below.</p>
+</blockquote>
+<p><a name="signature-service"></a></p>
+<h4 id="214-signature-service">2.1.4. Signature Service</h4>
+<p>A Signature Service within the Sweden Connect Framework is a Service
+Provider with specific requirements concerning its representation in
+metadata. </p>
+<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of a Signature Service SP
+entity descriptor SHALL include the service type entity category
+identifier <strong><code>http://id.elegnamnden.se/st/1.0/sigservice</code></strong> ([<a href="#sc-entcat">SC.EntCat</a>])
+as a value to the entity category attribute [<a href="#entcat">EntCat</a>].</p>
+<pre class="hljs"><code>&lt;mdattr:EntityAttributes xmlns:mdattr=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;`
+  &lt;saml2:Attribute Name=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
+                   NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>
+                   xmlns:saml2=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>&gt;
+    &lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;http:<span class="hljs-regexp">//i</span>d.elegnamnden.se<span class="hljs-regexp">/ec/</span><span class="hljs-number">1.0</span><span class="hljs-regexp">/loa3-pnr&lt;/</span>saml2:AttributeValue&gt;
+    &lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;http:<span class="hljs-regexp">//i</span>d.elegnamnden.se<span class="hljs-regexp">/st/</span><span class="hljs-number">1.0</span><span class="hljs-regexp">/sigservice&lt;/</span>saml2:AttributeValue&gt;
+  &lt;/saml2:Attribute&gt;
+&lt;/mdattr:EntityAttributes&gt;</code></pre><p><em>Entity attributes for a Signature Service SP.</em></p>
+<p>A Signature Service MUST assign the <code>AuthnRequestsSigned</code> attribute of the
+<code>&lt;md:SPSSODescriptor&gt;</code> element to <code>true</code>. This requirement ensures
+that the Signature Service always signs its authentication requests in
+order for the request to be accepted by the Identity Provider. The
+federation operator will enforce that all Service Providers that operate
+as Signature Services have this attribute set.</p>
+<p><a name="name-identifiers"></a></p>
+<h2 id="3-name-identifiers">3. Name Identifiers</h2>
+<p>Identity Providers and Service Providers MUST support both the
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</code> and the
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</code> name identifier
+formats as specified in [<a href="#saml2core">SAML2Core</a>].</p>
+<p>Identity Providers SHALL default to use the
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</code> name identifier
+format in cases where a Service Provider has not specified the name
+identifier to use (via the <code>&lt;md:NameIDFormat&gt;</code> element of the
+Service Provider metadata entry, or via the <code>Format</code> attribute of the
+<code>&lt;saml2p:NameIDPolicy&gt;</code> element of the authentication request
+message).</p>
+<p><a name="attributes"></a></p>
+<h2 id="4-attributes">4. Attributes</h2>
+<p>Attribute specifications for the Sweden Connect Framework are defined in
+[<a href="#sc-attributes">SC.Attributes</a>].</p>
+<p>The content of <code>&lt;saml2:AttributeValue&gt;</code> elements exchanged via any
+SAML 2.0 messages or assertions SHOULD be limited to a single child text
+node.</p>
+<p>For requirements regarding attribute inclusion in SAML assertions, see
+section <a href="#attribute-release-and-consuming-rules">6.2.1</a>, “<a href="#attribute-release-and-consuming-rules">Attribute Release and Consuming Rules</a>”, below.</p>
+<p><a name="authentication-requests"></a></p>
+<h2 id="5-authentication-requests">5. Authentication Requests</h2>
+<p>This profile supports two different SSO profiles; the Web Browser SSO Profile, [<a href="#saml2prof">SAML2Prof</a>], and the Holder-of-key Web Browser Profile, [<a href="#saml2hokprof">SAML2HokProf</a>]. </p>
+<p>The profile in use is determined by how an authentication process is initiated, meaning to which Identity Provider endpoint an <code>&lt;saml2p:AuthnRequest&gt;</code> message is sent, see <a href="#idp-holder-of-key-support">2.1.3.2</a>.</p>
+<p><a name="discovery"></a></p>
+<h3 id="51-discovery">5.1. Discovery</h3>
+<p>This profile does not impose any requirements of
+how the process of discovery is implemented by Service Providers wishing
+to display user interfaces for selection of Identity Providers for end
+users. However, Service Providers making use of a centralized
+discovery service as defined in [<a href="#idpdisco">IdpDisco</a>] MUST follow the requirements
+stated for discovery responses in 
+section <a href="##service-providers">2.1.2</a>, &quot;<a href="#service-providers">Service Providers</a>&quot;.</p>
+<p><a name="binding-and-security-requirements"></a></p>
+<h3 id="52-binding-and-security-requirements">5.2. Binding and Security Requirements</h3>
+<p>The endpoints, at which an Identity Provider receives a
+<code>&lt;saml2p:AuthnRequest&gt;</code> message, and all subsequent exchanges with
+the user agent, MUST be protected by TLS. </p>
+<p>If the Identity Provider supports the Holder-of-key Web Browser SSO Profile, the
+dedicated endpoints for this profile (see section <a href="#idp-holder-of-key-support">2.1.3.2</a>)
+MUST be configured to require a 
+client X.509 certificate being presented as part of the TLS handshake (mTLS, mutual TLS), 
+see section 2.4 of [<a href="#saml2hokprof">SAML2HokProf</a>]. If the Identity Provider receives
+a request on a Holder-of-key endpoint and is unable to retrieve the client X.509
+certificate it MUST respond with an error, see section 2.6.4 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+<p>A Service Provider sending an <code>&lt;saml2p:AuthnRequest&gt;</code> message to an Identity Provider
+may do so using either the HTTP-Redirect or HTTP-POST binding [<a href="#saml2bind">SAML2Bind</a>]<sup>*</sup>,
+meaning that Identity Providers conformant with this profile MUST support the
+HTTP-Redirect and the HTTP-POST binding.</p>
+<p>An Identity Provider that requires <code>&lt;saml2p:AuthnRequest&gt;</code> messages
+to be signed MUST not accept messages that are not signed, or where the
+verification of the signature fails. In these cases the Identity
+Provider MUST respond with an error.</p>
+<p>An Identity Provider that itself does not require authentication
+messages to be signed MUST still accept and verify signed request
+messages from Service Providers that indicate, in their metadata, that
+they sign request messages (see <a href="#service-providers">2.1.2</a> above). If this signature
+verification fails, the Identity Provider MUST return a SAML error
+response and MUST NOT fulfil the request.</p>
+<p>An Identity Provider that receives a request message that is not signed
+from a Service Provider that has indicated, in its metadata, that it
+will only send signed request messages (see <a href="#service-providers">2.1.2</a> above) MUST respond
+with an error.</p>
+<p>The signature for authentication request messages is applied differently
+depending on the binding. The HTTP-Redirect binding requires the
+signature to be applied to the URL-encoded value rather than being
+placed within the XML-message (see section 3.4.4.1 of
+[<a href="#saml2bind">SAML2Bind</a>]).
+For the HTTP-POST binding the <code>&lt;saml2p:AuthnRequest&gt;</code> element MUST
+be signed using a <code>&lt;ds:Signature&gt;</code> element within the
+<code>&lt;saml2:AuthnRequest&gt;</code>.</p>
+<p>Before signing the authentication request, the Service Provider SHOULD consult the Identity Provider&#39;s metadata (<code>&lt;alg:SigningMethod&gt;</code> and <code>&lt;alg:DigestMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory signing and digest algorithms defined in the Sweden Connect Framework during the signature operation.</p>
+<blockquote>
+<p>[*]: A Service Provider should be aware of web browser, or web server, size limitations
+of URL:s, and it is RECOMMENDED that a Service Provider use the HTTP-POST binding in cases where 
+the <code>&lt;saml2p:AuthnRequest&gt;</code> message becomes very large. This may be the case when a <code>SignMessage</code>
+extension containing much data is used, or when a complete certificate chain is attached to the signature 
+of the message.</p>
+</blockquote>
+<p><a name="message-content"></a></p>
+<h3 id="53-message-content">5.3. Message Content</h3>
+<p>An <code>&lt;saml2p:AuthnRequest&gt;</code> message MUST NOT contain a Document Type Definition (DTD).</p>
+<p>The <code>&lt;saml2p:AuthnRequest&gt;</code> message SHOULD contain an
+<code>AssertionConsumerServiceURL</code><sup>*</sup> attribute identifying the desired response
+location. The Service Provider MUST NOT use any other values for this
+attribute than those listed in its metadata record as
+<code>&lt;md:AssertionConsumerService&gt;</code> elements for the HTTP-POST binding
+(see section 4.1.6 of [<a href="#saml2prof">SAML2Prof</a>]), and URL
+canonicalization or normalization MUST NOT be required.</p>
+<p>The <code>Destination</code> attribute of the <code>&lt;saml2p:AuthnRequest&gt;</code> message
+MUST contain the URL to which the Service Provider has instructed the
+user agent to deliver the request. This is useful to prevent malicious
+forwarding of signed requests from being accepted by unintended Identity
+Providers.</p>
+<p>Identity Providers conformant with this profile MUST support the
+<code>ForceAuthn</code> and <code>IsPassive</code> attributes received in
+<code>&lt;saml2p:AuthnRequest&gt;</code> messages.</p>
+<p>Service Providers SHOULD include the <code>ForceAuthn</code> attribute in all
+<code>&lt;saml2p:AuthnRequest&gt;</code> messages and explicitly set its value to
+<code>true</code> or <code>false</code>, and not rely on its default value. The reason for this is
+to avoid accidental SSO.</p>
+<p>If the Service Provider has included more than one <code>&lt;md:AttributeConsumingService&gt;</code> element in its metadata it is RECOMMENDED that the <code>&lt;saml2p:AuthnRequest&gt;</code> message contains the <code>AttributeConsumingServiceIndex</code> attribute holding the index of the <code>&lt;md:AttributeConsumingService&gt;</code> element that the Identity Provider should consider during attribute release.</p>
+<blockquote>
+<p>[*]: The <code>AssertionConsumerServiceURL</code> attribute is mutually exclusive with the <code>AssertionConsumerServiceIndex</code> attribute, meaning that a <code>&lt;saml2p:AuthnRequest&gt;</code> message MUST NOT contain both attributes. </p>
+</blockquote>
+<p><a name="requested-authentication-context"></a></p>
+<h4 id="531-requested-authentication-context">5.3.1. Requested Authentication Context</h4>
+<p>A Service Provider SHOULD explicitly specify a requested
+authentication context element (<code>&lt;saml2p:RequestedAuthnContext&gt;</code>),
+containing <code>&lt;saml2:AuthnContextClassRef&gt;</code> elements each holding
+a Level of Assurance authentication context URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]) 
+that the Service Provider considers acceptable for the authentication process.</p>
+<p>A present <code>&lt;saml2p:RequestedAuthnContext&gt;</code> element MUST specify
+exact matching by means of either an absent <code>Comparison</code> attribute or a
+<code>Comparison</code> attribute with the value set to <code>exact</code>. This means that the
+Identity Provider is forced to return an assertion with exactly one of
+the requested <code>&lt;saml2:AuthnContextClassRef&gt;</code> in the request as the
+declared <code>&lt;saml2:AuthnContext&gt;</code>, or return an error response. If the
+Service Provider requires the Identity Provider to return specifically
+one out of a selection of acceptable authentication context URIs, then
+all of these URIs MUST be included in the request.</p>
+<p>The requested authentication context SHOULD be consistent with at least
+one of the service entity categories [<a href="#sc-entcat">SC.EntCat</a>] declared in the
+Service Provider’s metadata entry. See further <a href="#authentication-context-and-level-of-assurance-handling">section 5.4.4</a> below.</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2p:RequestedAuthnContext Comparison=<span class="hljs-string">&quot;exact&quot;</span>&gt;</span>
+  <span class="hljs-section">&lt;saml2:AuthnContextClassRef&gt;</span><span class="hljs-attribute">http</span>://id.elegnamnden.se/loa/<span class="hljs-number">1</span>.<span class="hljs-number">0</span>/loa<span class="hljs-number">3</span>&lt;/saml<span class="hljs-number">2</span>:AuthnContextClassRef&gt;
+<span class="hljs-section">&lt;/saml2p:RequestedAuthnContext&gt;</span></code></pre><p><em>Example of how an Authentication Context URI identifier representing a
+requested Level of Assurance is included in an authentication request
+message.</em></p>
+<pre class="hljs"><code>&lt;saml2p:RequestedAuthnContext Comparison=<span class="hljs-string">&quot;exact&quot;</span>&gt;
+  &lt;saml2:AuthnContextClassRef&gt;http:<span class="hljs-regexp">//i</span>d.elegnamnden.se<span class="hljs-regexp">/loa/</span><span class="hljs-number">1.0</span><span class="hljs-regexp">/loa3&lt;/</span>saml2:AuthnContextClassRef&gt;
+  &lt;saml2:AuthnContextClassRef&gt;http:<span class="hljs-regexp">//i</span>d.elegnamnden.se<span class="hljs-regexp">/loa/</span><span class="hljs-number">1.0</span><span class="hljs-regexp">/eidas-nf-sub&lt;/</span>saml2:AuthnContextClassRef&gt;
+&lt;/saml2p:RequestedAuthnContext&gt;</code></pre><p><em>Example of how several Authentication Context URIs are included in an
+authentication request message. In this case, the Service Provider
+states that it requests the authentication to be performed according to
+either the LoA3 URI defined within the Sweden Connect Framework or the
+substantial level for notified eIDs defined within the eIDAS Framework.</em></p>
+<p><a name="scoping"></a></p>
+<h4 id="532-scoping">5.3.2. Scoping</h4>
+<p>An Identity Provider that acts as a proxy for other Identity Providers SHOULD support the <code>&lt;saml2p:Scoping&gt;</code> element holding one, or more, entries signalling to the Proxy Identity Provider which Identity Provider(s) that may be used to authenticate the user. A Service Provider that sends authentication requests to a Proxy
+IdP MAY include the <code>&lt;saml2p:Scoping&gt;</code> element. See section 3.4.1.5 of [<a href="#saml2core">SAML2Core</a>].</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Scoping</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPEntry</span> <span class="hljs-attr">ProviderID</span>=<span class="hljs-string">&quot;http://idp.example.com&quot;</span> /&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Scoping</span>&gt;</span></code></pre><p><em>Example of how an <code>AuthnRequest</code> contains a <code>Scoping</code>-element where the requester (Service Provider) signals to the Proxy IdP which Identity Provider that should perform the authentication of the user.</em></p>
+<p>The Swedish eIDAS Connector is a Proxy IdP that proxies requests to foreign eIDAS Proxy Services. Normally, the eIDAS connector presents a country selection dialogue to the user, prompting for the country where the user should be directed to for authentication. However, a Service Provider MAY include an eIDAS Proxy Service alias URI for a specific country&#39;s Proxy Service under the <code>&lt;saml2p:Scoping&gt;</code> element of the <code>&lt;saml2p:AuthnRequest&gt;</code> in order to bypass the country selection dialogue. See section 3.1.9.1 of [<a href="#sc-registry">SC.Registry</a>].</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Scoping</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPEntry</span> <span class="hljs-attr">ProviderID</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/eidas/1.0/proxy-service/no&quot;</span> /&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Scoping</span>&gt;</span></code></pre><p><em>Example of how an <code>AuthnRequest</code> sent to the eIDAS Connector requests that the eIDAS Connector should
+proxy the request to the Norwegian eIDAS Proxy Service for authentication.</em></p>
+<blockquote>
+<p><strong>Note</strong>: A Service Provider may list more than one country in the <code>&lt;saml2p:IDPList&gt;</code> of a <code>&lt;saml2p:Scoping&gt;</code> element. The eIDAS Connector will then present a country selection dialogue containing only the listed countries.</p>
+</blockquote>
+<p><strong>Note:</strong> Another method of bypassing the country selection dialogue is to include the <code>c</code> (<code>urn:oid:2.5.4.6</code>) 
+attribute with the country code for the requested country as its value in a <code>&lt;psc:PrincipalSelection&gt;</code>
+extension of the <code>AuthnRequest</code> message, see section <a href="#principal-selection">5.3.3</a> below.</p>
+<p><a name="principal-selection"></a></p>
+<h4 id="533-principal-selection">5.3.3. Principal Selection</h4>
+<p>The specification &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#sc-principal">SC.Principal</a>], defines the <code>&lt;psc:PrincipalSelection&gt;</code> extension that enables a requestor to inform the Identity Provider about known attributes for the principal that is about to be authenticated. </p>
+<p>This may be relevant for Identity Provider services who prompt users for an identifier in order initiate an authentication process with the user&#39;s eID. In such cases, this extension can be used to avoid unnecessary prompting when the user&#39;s identity is known in advance to the service requesting authentication, such as when a previously authenticated user is requested to sign a document.</p>
+<p>An Identity Provider that wishes to receive the <code>&lt;psc:PrincipalSelection&gt;</code> extension SHOULD advertise this in its metadata according to <a href="#identity-providers">section 2.1.3</a>.</p>
+<p>A Service Provider that sends an authentication request  to an Identity Provider that has declared that it wishes to receive certain attribute values MAY include the <code>&lt;psc:PrincipalSelection&gt;</code> extension in the <code>&lt;saml2p:AuthnRequest&gt;</code> message, provided that the Service Provider has knowledge about this information.</p>
+<p>A Service Provider that is a Signature Service SHOULD include the extension for the case described above.</p>
+<p><a name="processing-requirements"></a></p>
+<h3 id="54-processing-requirements">5.4. Processing Requirements</h3>
+<p><a name="validation-of-destination"></a></p>
+<h4 id="541-validation-of-destination">5.4.1. Validation of Destination</h4>
+<p>An Identity Provider receiving a <code>&lt;saml2p:AuthnRequest&gt;</code> message
+MUST verify that the <code>Destination</code> attribute is present, and that it is
+consistent with URLs configured in the Identity Provider’s metadata.</p>
+<p><a name="validation-of-assertion-consumer-addresses"></a></p>
+<h4 id="542-validation-of-assertion-consumer-addresses">5.4.2. Validation of Assertion Consumer Addresses</h4>
+<p>If the <code>AssertionConsumerServiceURL</code> attribute is present in the
+<code>&lt;saml2p:AuthnRequest&gt;</code> message, its value MUST be verified to be
+consistent with one of the <code>&lt;md:AssertionConsumerService&gt;</code> elements
+having the HTTP-POST binding<sup>*</sup> found in the Service Provider’s metadata
+entry and matching the SSO profile<sup>**</sup> in use 
+(see <a href="#sp-holder-of-key-support">section 2.1.2.1</a>). If this is not the case, 
+the request must be rejected.</p>
+<p>If the <code>AssertionConsumerServiceIndex</code> attribute is present in the
+<code>&lt;saml2p:AuthnRequest&gt;</code> message, a <code>&lt;md:AssertionConsumerService&gt;</code> matching this
+index MUST be present in the Service Provider’s metadata. This
+<code>&lt;md:AssertionConsumerService&gt;</code> element MUST also match the binding and SSO
+profile in use as defined above. If this is not the case, 
+the request must be rejected.</p>
+<blockquote>
+<p>This means that an Identity Provider that services an authentication request
+received on an <code>SingleSignOnService</code> endpoint dedicated for the Holder-of-key
+Web Browser Profile MUST NOT allow an <code>&lt;md:AssertionConsumerService&gt;</code> element
+that is not intended for the Holder-of-key profile, see section 2.8 of 
+[<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+</blockquote>
+<p>If the attribute is not present in the <code>&lt;saml2p:AuthnRequest&gt;</code>
+message, the Identity Provider MUST obtain the desired response location
+from the Service Provider’s metadata entry.  This location is determined by first 
+finding all the <code>&lt;md:AssertionConsumerService&gt;</code> 
+elements that matches the SSO profile<sup>**</sup> in use (see 
+<a href="#sp-holder-of-key-support">section 2.1.2.1</a>) and the binding<sup>*</sup> (HTTP-POST), 
+and then selecting the element that is marked as default (has the <code>isDefault</code> attribute set), 
+or if no matching element is marked as default, the one with the lowest index value (see 
+section 2.4.4.1 of [<a href="#saml2meta">SAML2Meta</a>] and section 2.8 of 
+[<a href="#saml2hokprof">SAML2HokProf</a>]). If no matching <code>&lt;md:AssertionConsumerService&gt;</code>
+element is found the request must be rejected.</p>
+<blockquote>
+<p>[*]: For Holder-of-key <code>&lt;md:AssertionConsumerService&gt;</code> elements the actual binding
+is given by the <code>hoksso:ProtocolBinding</code> attribute, see section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+</blockquote>
+<blockquote>
+<p>[**]: The Web Browser SSO Profile or the Holder-of-key Web Browser SSO Profile are possible profiles.</p>
+</blockquote>
+<p><a name="identity-provider-user-interface"></a></p>
+<h4 id="543-identity-provider-user-interface">5.4.3. Identity Provider User Interface</h4>
+<p>An Identity Provider presenting information related to a Service Provider
+in its user interface during processing of an <code>&lt;saml2p:AuthnRequest&gt;</code> message
+MUST obtain this information from the
+<code>&lt;mdui:UIInfo&gt;</code> element of the Service Provider’s metadata entry.
+Implementers of this profile MUST be capable of handling display
+information stored in the <code>&lt;mdui:DisplayName&gt;</code>, <code>&lt;mdui:Logo&gt;</code>
+and the <code>&lt;mdui:Description&gt;</code> elements.</p>
+<p>An Identity Provider displaying logotypes found in a Service Provider&#39;s
+metadata MUST be able to handle embedded in-line images, as well as
+vector-based images where the height and width given in metadata should
+be interpreted as image dimensions and not the actual size.</p>
+<p><a name="authentication-context-and-level-of-assurance-handling"></a></p>
+<h4 id="544-authentication-context-and-level-of-assurance-handling">5.4.4. Authentication Context and Level of Assurance Handling</h4>
+<p>This framework defines a number of authentication context identifiers
+(URI), where each such identifier specifies a defined Level of Assertion
+and may define specific requirements on the authentication process.
+There can be multiple authentication context URIs representing the same
+Level of Assertion, but one authentication context URI always identifies
+one defined Level of Assurance. </p>
+<p>Identity Providers SHALL exclusively use one of the requested
+authentication contexts in <code>&lt;saml2p:AuthnRequest&gt;</code> in the
+<code>&lt;saml2:AuthnContextClassRef&gt;</code> element under the
+<code>&lt;saml2p:RequestedAuthnContext&gt;</code> element, when present, to determine
+the requested authentication process and Level of Assurance. The
+Identity Provider SHALL respond with an error <code>&lt;saml2p:StatusCode&gt;</code>
+with the value <code>urn:oasis:names:tc:SAML:2.0:status:Requester</code>
+[<a href="#saml2core">SAML2Core</a>]
+if no requested authentication context is supported. If no requested
+authentication context is present in the <code>&lt;saml2p:AuthnRequest&gt;</code>,
+the Identity Provider MAY return the result of a default authentication
+process that is consistent with the Identity Providers metadata.</p>
+<p><strong>Note</strong>: The Identity Provider does not have to consider the service
+entity categories ([<a href="#sc-entcat">SC.EntCat</a>]) declared in the Service Provider’s
+metadata entry when determining the requested authentication context
+under which the authentication should be performed. The purpose of the
+service entity categories is primarily to support service matching in
+discovery services and attribute release policies in Identity Providers.
+Significant Identity Provider products and software are not equipped to
+use service entity category information to determine the requested
+authentication context.</p>
+<p><a name="single-sign-on-processing"></a></p>
+<h4 id="545-single-sign-on-processing">5.4.5. Single Sign On Processing</h4>
+<p>An Identity Provider conformant to this profile MAY issue an assertion
+relying on a previously established security context (active session)
+instead of authenticating the user. However, the Identity Provider MUST
+NOT re-use an already existing security context in the following cases:</p>
+<ul class="list">
+<li><p>When the security context has expired, i.e., the time elapsed since
+  the security context was established is too long given the
+  SSO-policy stipulated by the federation or Identity Provider itself.</p>
+</li>
+<li><p>When the <code>&lt;saml2p:AuthnRequest&gt;</code> contains a <code>ForceAuthn</code> attribute
+  with the value of <code>true</code>.</p>
+</li>
+<li><p>If the original authentication process, which led to the
+  establishment of the security context, was performed using another
+  Level of Assurance that what is requested in the current
+  <code>&lt;saml2p:AuthnRequest&gt;</code> message.</p>
+</li>
+<li><p>If the original authentication was performed according to the Holder-of-key
+  Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>], and
+  no certificate, or a certificate not matching the certificate included
+  in the <code>&lt;saml2:SubjectConfirmation&gt;</code> element of the original assertion, 
+  is presented in along with the current <code>&lt;saml2p:AuthnRequest&gt;</code> message. </p>
+</li>
+<li><p>If the original authentication was performed according to the Web Browser SSO
+  Profile, [<a href="#saml2prof">SAML2Prof</a>] and the current request is made 
+  according to the Holder-of-key Web Browser SSO Profile, 
+  [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+</li>
+</ul>
+<p>If the Identity Provider user interface contains some sort of user
+consent, or information, concerning which attributes, or any other
+information, that is included in an assertion being issued, the Identity
+Provider SHOULD preserve this functionality if a
+<code>&lt;saml2p:AuthnRequest&gt;</code> message requesting a different set of
+attributes (or any other information) compared to what was delivered in
+the assertion at the time of establishing the security context. The
+Identity Provider may require re-authentication or display a user
+interface for consent/information in these cases.</p>
+<p><a name="authentication-responses"></a></p>
+<h2 id="6-authentication-responses">6. Authentication Responses</h2>
+<p><a name="security-requirements"></a></p>
+<h3 id="61-security-requirements">6.1. Security Requirements</h3>
+<p>The endpoint(s) at which a Service Provider receives a
+<code>&lt;saml2p:Response&gt;</code> message MUST be protected by TLS.</p>
+<p>If a Service Provider wants to make use of the Holder-of-key Web Browser SSO Profile
+it needs to provide a dedicated endpoint for this purpose, see section <a href="#sp-holder-of-key-support">2.1.2.1</a>. This endpoint MUST be configured to require a client X.509 certificate
+being presented as part of the TLS handshake (mTLS, mutual TLS), see section 2.4 of 
+[<a href="#saml2hokprof">SAML2HokProf</a>]. If the Service Provider receives a <code>&lt;saml2p:Response&gt;</code>
+on a Holder-of-key endpoint and is unable to retrieve the client X.509 certificate it MUST 
+reject the message and not create a security context for the principal, see section 2.6.6 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
+<p>The <code>&lt;saml2p:Response&gt;</code> message issued by the Identity Provider MUST
+be signed using a <code>&lt;ds:Signature&gt;</code> element within the
+<code>&lt;saml2p:Response&gt;</code> element.</p>
+<p>The <code>&lt;saml2:Assertion&gt;</code> element issued by the Identity Provider MAY
+be signed using a <code>&lt;ds:Signature&gt;</code> element within the
+<code>&lt;saml2:Assertion&gt;</code>. If a Service Provider requires signed
+assertions, by assigning the <code>WantAssertionsSigned</code> attribute of its
+metadata record (see <a href="#service-providers">chapter 2.1.2</a>), the Identity Provider MUST sign
+assertions issued to this Service Provider (as well as the response
+message as stated above).</p>
+<p>Identity Providers SHALL utilize XML Encryption and return a
+<code>&lt;saml2:EncryptedAssertion&gt;</code> element in the <code>&lt;saml2p:Response&gt;</code>
+message. The elements <code>&lt;saml2:EncryptedID&gt;</code> and
+<code>&lt;saml2:EncryptedAttribute&gt;</code> MUST NOT be used; instead the entire
+assertion MUST be encrypted.</p>
+<p>Before performing encryption and signing, the Identity Provider SHOULD consult the Service Provider&#39;s metadata (<code>&lt;md:EncryptionMethod&gt;</code>, <code>&lt;alg:SigningMethod&gt;</code> and <code>&lt;alg:DigestMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Service Provider prefers. If the intersection is empty, or if the Service Provider has not declared any algorithms, the Identity Provider MUST use algorithms listed as mandatory by the Sweden Connect Framework. For encryption, the chosen algorithm MUST also be compatible with the Service Provider&#39;s encryption key 
+declared in metadata.</p>
+<p>Service Providers SHOULD NOT accept unsolicited <code>&lt;saml2p:Response&gt;</code>
+messages (i.e., responses that are not the result of an earlier
+<code>&lt;saml2p:AuthnRequest&gt;</code> message). Service Providers that do accept
+unsolicited response messages MUST ensure, by other means, that the
+security and processing requirements of this profile (<a href="#processing-requirements">section 6.3</a>) can be fully satisfied.</p>
+<p><a name="message-content2"></a></p>
+<h3 id="62-message-content">6.2. Message Content</h3>
+<p>The <code>&lt;saml2:Response&gt;</code> message MUST NOT contain a Document Type Definition (DTD).</p>
+<p>Successful response messages MUST contain exactly one <code>&lt;saml2:AuthnStatement&gt;</code> element
+and exactly one <code>&lt;saml2:AttributeStatement&gt;</code> element.</p>
+<p>The <code>&lt;saml2:Response&gt;</code> message MUST contain an <code>&lt;saml2:Issuer&gt;</code>
+element containing the unique identifier (entityID) of the issuing
+Identity Provider.</p>
+<p>The <code>AuthnInstant</code> attribute of the <code>&lt;saml2:AuthnStatement&gt;</code> element
+MUST be assigned the time when the actual authentication took place.
+This time may differ from the <code>IssueInstant</code> attribute of the assertion
+itself, which holds the time when the assertion was issued. This is
+especially important in cases of re-use of already established security
+contexts at the Identity Provider side (Single Sign On).</p>
+<p>Each identity assertion MUST have a <code>&lt;saml:Subject&gt;</code> element that
+specifies the principal that is the subject of all the statements in
+the assertion.</p>
+<p>The value of the <code>&lt;saml:NameID&gt;</code> element under the
+<code>&lt;saml:Subject&gt;</code> element MUST hold a pseudonym identifier of the
+subject, which SHALL be:</p>
+<ul class="list">
+<li><p>Unique for the IdP – SP combination being the issuer and recipient
+  for the assertion.</p>
+</li>
+<li><p>Constructed in a manner that does not reveal the registered identity
+  of the subject.</p>
+</li>
+</ul>
+<p>The <code>&lt;saml2:Subject&gt;</code> element MUST contain one
+<code>&lt;saml2:SubjectConfirmation&gt;</code> element containing a <code>Method</code> attribute having the value
+of <code>urn:oasis:names:tc:SAML:2.0:cm:bearer</code> if the Web Browser SSO Profile was used,
+and <code>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</code> if the Holder-of-key Web Browser 
+SSO Profile was used. This element MUST contain a <code>&lt;saml2:SubjectConfirmationData&gt;</code> 
+element that contains at least the following:</p>
+<ul class="list">
+<li><p>  An <code>InResponseTo</code> attribute matching the request’s ID.</p>
+</li>
+<li><p>A <code>Recipient</code> attribute containing the Service Provider’s assertion
+  consumer service URL (see sections <a href="#message-content">5.3</a> and 
+  <a href="#validation-of-destination">5.4.1</a>).</p>
+</li>
+<li><p>A <code>NotOnOrAfter</code> attribute containing a time instant at which the
+  subject no longer can be confirmed.</p>
+</li>
+<li><p>An <code>Address</code> attribute containing the network address from which an attesting entity
+  (user) can present the assertion.</p>
+</li>
+<li><p>If the Holder-of-key Web Browser SSO Profile was used to authenticate the
+  principal a <code>&lt;ds:KeyInfo&gt;</code> element identifying the X.509 certificate presented
+  to the Identity Provider. See section <a href="#message-content-requirements-for-holder-of-key">6.2.2</a> below.</p>
+</li>
+</ul>
+<p>The assertion MUST contain a <code>&lt;saml2:Conditions&gt;</code> element containing
+the following attributes and elements:</p>
+<ul class="list">
+<li><p>A <code>&lt;saml2:AudienceRestriction&gt;</code> element including the requesting
+  Service Provider’s unique identifier (entityID) as an
+  <code>&lt;saml2:Audience&gt;</code> value.</p>
+</li>
+<li><p>A <code>NotBefore</code> attribute specifying the earliest time instant at which
+  the assertion is valid.</p>
+</li>
+<li><p>A <code>NotOnOrAfter</code> attribute specifying the time instant when the
+  assertion expires.</p>
+</li>
+</ul>
+<p>An Identity Provider conformant to this profile MUST, in its issued
+assertions, include an authentication context URI indicating under which
+Level of Assurance the assertion was issued. This identifier MUST be
+placed under the <code>&lt;saml2:AuthnStatement&gt;</code> element as the value of an
+<code>&lt;saml2:AuthnContextClassRef&gt;</code> element that is part of the
+<code>&lt;saml2:AuthnContext&gt;</code> element.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnStatement</span> <span class="hljs-attr">AuthnInstant</span>=<span class="hljs-string">&quot;2013-03-15T09:22:00&quot;</span> <span class="hljs-attr">SessionIndex</span>=<span class="hljs-string">&quot;b07b804c-7c29-ea16-7300-4f3d6f7928ac&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>
+    ...
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnStatement</span>&gt;</span></code></pre><p><em>Example of how an Authentication Context URI identifier representing a
+Level of Assurance is included in an authentication statement.</em></p>
+<p>An Identity Provider that acts as a proxy for other Identity Providers SHOULD include the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element under the <code>&lt;saml2:AuthnContext&gt;</code> element. This element will contain the entityID of the Identity Provider that authenticated the principal.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnStatement</span> <span class="hljs-attr">AuthnInstant</span>=<span class="hljs-string">&quot;2013-03-15T09:22:00&quot;</span> <span class="hljs-attr">SessionIndex</span>=<span class="hljs-string">&quot;b07b804c-7c29-ea16-7300-4f3d6f7928ac&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
+    ...
+    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthenticatingAuthority</span>&gt;</span>http://idp.example.com/auth<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthenticatingAuthority</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnStatement</span>&gt;</span></code></pre><p><em>Example of how the entityID of an Identity Provider that provided the authentication for the principal is included in an authentication statement.</em></p>
+<p><a name="attribute-release-and-consuming-rules"></a></p>
+<h4 id="621-attribute-release-and-consuming-rules">6.2.1. Attribute Release and Consuming Rules</h4>
+<p>An Identity Provider determines which attributes to include in the
+<code>&lt;saml2:AttributeStatement&gt;</code> element of an assertion based on the
+Service Provider requirements and its agreements with the user being
+authenticated. Service Provider attribute preferences and requirements
+are specified by the service entity categories [<a href="#sc-entcat">SC.EntCat</a>] and
+requested attributes in the <code>&lt;md:AttributeConsumingService&gt;</code> element
+declared in the Service Provider metadata. A service entity category
+specifies the attribute set (as defined in [<a href="#sc-attributes">SC.Attributes</a>]) that is
+requested for the attribute release process.</p>
+<p>An Identity Provider declares service entity categories in order to
+publish its ability to deliver attributes according to certain attribute
+sets. For all declared service entity categories, the Identity Provider
+MUST possess the ability to deliver the mandatory attributes of the
+underlying attribute set. See [<a href="#sc-entcat">SC.EntCat</a>] and [<a href="#sc-attributes">SC.Attributes</a>] for details.</p>
+<p>An Identity Provider releasing scoped attributes, see section 3.1.3 of [<a href="#sc-attributes">SC.Attributes</a>], MUST be authorized to release attributes with given scopes by the federation operator. An Identity Provider&#39;s authorized scopes are published in its metadata according to section <a href="#declaring-authorized-scopes">2.1.3.1</a>, &quot;<a href="#declaring-authorized-scopes">Declaring Authorized Scopes</a>&quot;. </p>
+<p>Consequently, a Service Provider consuming a scoped attribute SHOULD verify that the issuing Identity Provider has been authorized to release attributes for the given scope by asserting its presence in the Identity Provider&#39;s metadata, see section <a href="#declaring-authorized-scopes">2.1.3.1</a> and section 3.5.2 of [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>]. A scoped attribute that fails this check MUST NOT be accepted by the Service Provider.</p>
+<p>The Service Provider is responsible for checking that an Identity
+Provider is capable of providing necessary attributes before sending a
+request and to verify that it received all attributes necessary for
+providing a requested service. Checks whether an Identity Provider is
+capable of fulfilling the needs of a Service Provider can be done either
+by relying on a discovery process to filter out non-conformant Identity
+Providers, and/or by examining the metadata of Identity providers. </p>
+<p>An Identity Provider receiving a request for more attributes than it can
+provide SHOULD return an assertion with the attributes it can provide
+according to its defined attribute release policy if the user has been successfully 
+authenticated, leaving it up to the Service Provider to decide how to proceed, 
+e.g., by denying service to the authenticated user, provide limited services or to use other
+resources to collect necessary attributes. However, if a Service Provider
+has expressed a specific attribute requirement using the <code>&lt;md:RequestedAttribute&gt;</code>
+element of a matching <code>&lt;md:AttributeConsumingService&gt;</code> element in its metadata
+and assigned the <code>isRequired</code>-attribute to <code>true</code>, and the Identity Provider knows that it will not be able to provide this attribute, then the Identity Provider SHOULD reject any request for authentication from that Service Provider and respond with an error.</p>
+<p>For privacy reasons, an Identity Provider SHOULD NOT release identity attributes<sup>*</sup> that are not requested by the Service Provider via its metadata declarations
+ (service entity categories or <code>&lt;md:RequestedAttribute&gt;</code> elements).</p>
+<blockquote>
+<p>[*]: This requirement does not apply to attributes that are not &quot;identity&quot; attributes, for example transaction identifiers or any other attribute that does not directly belong to a user&#39;s identity.</p>
+</blockquote>
+<p><a name="message-content-requirements-for-holder-of-key"></a></p>
+<h4 id="622-message-content-requirements-for-holder-of-key">6.2.2. Message Content Requirements for Holder-of-key</h4>
+<p>When the Holder-of-key Web Browser SSO Profile has been used during the authentication
+of the user, information about the X.509 certificate presented by the user MUST be 
+included in a <code>&lt;ds:KeyInfo&gt;</code> element placed in the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element. Section 2.4 of [<a href="#saml2hokap">SAML2HokAP</a>] defines the requirements for this.</p>
+<p>This profile adds the following requirements to what is specified in [<a href="#saml2hokap">SAML2HokAP</a>]:</p>
+<p>The user X.509 certificate SHOULD be represented using a <code>&lt;ds:X509Certificate&gt;</code> element
+in all cases, except for the cases when this certificate contains identity information 
+about the subject that is not represented as SAML attributes in the 
+<code>&lt;saml2:AttributeStatement&gt;</code> element.
+The reason for this is to ensure the privacy of the user and not release identity information that is not requested by the Service Provider (see section <a href="#attribute-release-and-consuming-rules">6.2.1</a> above).</p>
+<p>In these cases the <code>&lt;ds:X509Certificate&gt;</code> MUST NOT be used, and the Identity Provider 
+SHOULD include a <code>&lt;ds:KeyValue&gt;</code> representing the public key of the user certificate.</p>
+<p><a name="processing-requirements2"></a></p>
+<h3 id="63-processing-requirements">6.3. Processing Requirements</h3>
+<p>This profile mandates a correct processing of a <code>&lt;saml2p:Response&gt;</code>
+message in order to ensure proper protection from the security threats
+described in [<a href="#saml2sec">SAML2Sec</a>].
+Processing requirements are listed in [<a href="#saml2core">SAML2Core</a>],
+[<a href="#saml2prof">SAML2Prof</a>] and [<a href="#saml2sec">SAML2Sec</a>].
+This document will list the necessary requirements that apply to this
+profile.</p>
+<p>After the Service Provider has encrypted the assertion from the received
+response message the following requirements apply. Any verification that
+fails MUST lead to that the Service Provider rejects the response
+message and does not use the assertion.</p>
+<p>Some of the processing requirements below are defined in order to
+protect from MITM- or MITB-attacks<sup>*</sup> were unsigned authentication
+requests may be changed before being sent to the Identity Provider.
+However, a Service Provider MUST implement all of the specified
+processing requirements even if it sends signed authentication request
+messages.</p>
+<blockquote>
+<p>[*]: MITM stands for ”man in the middle” and MITB stands for ”man in the browser”.</p>
+</blockquote>
+<p><a name="signature-validation"></a></p>
+<h4 id="631-signature-validation">6.3.1. Signature Validation</h4>
+<p>The signature present on the <code>&lt;saml2p:Response&gt;</code> message, and
+optionally on the <code>&lt;saml2:Assertion&gt;</code>, MUST be successfully
+verified.</p>
+<p>The public key being used to verify the signature MUST appear in the
+issuing Identity Provider’s metadata record (as a
+<code>&lt;ds:X509Certificate&gt;</code> under the <code>&lt;ds:KeyInfo&gt;</code> element).</p>
+<p><a name="subject-confirmation"></a></p>
+<h4 id="632-subject-confirmation">6.3.2. Subject Confirmation</h4>
+<p>Based on the <code>InResponseTo</code> attribute of the
+<code>&lt;saml2:SubjectConfirmationData&gt;</code> the Service Provider MUST be able
+to obtain the corresponding <code>&lt;saml2p:AuthnRequest&gt;</code> message, or a
+secure context containing corresponding information from the request
+(for future processing of the assertion).</p>
+<p>The <code>Recipient</code> attribute from the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element 
+MUST match the location to which the <code>&lt;saml2p:Response&gt;</code> message was delivered 
+<strong>and</strong> match the value the <code>AssertionConsumerServiceURL</code> attribute included in the
+request message, or if this attribute was not provided in the request
+message, the default response location specified in the Service
+Provider’s metadata entry, as described in <a href="#validation-of-assertion-consumer-addresses">section 5.4.2</a>.</p>
+<p>The time from the <code>NotOnOrAfter</code> attribute from the
+<code>&lt;saml2:SubjectConfirmationData&gt;</code> MUST NOT have passed compared with
+the time instant at which the subject is confirmed (i.e., when the
+assertion is validated). A reasonable allowable clock skew between the
+providers should be taken in account.</p>
+<p>If the <code>Address</code> attribute is assigned to the
+<code>&lt;saml2:SubjectConfirmationData&gt;</code> element, the Service Provider MAY
+choose to check the user agent’s client address against it. Practical
+issues regarding the Service Provider’s network setup and the risk of
+introducing false negatives makes this an optional step in the
+validation phase.</p>
+<p>If the <code>&lt;saml2:SubjectConfirmation&gt;</code> element has a <code>Method</code> set to
+<code>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</code> its containing 
+<code>&lt;saml2:SubjectConfirmationData&gt;</code> element MUST be processed according to
+section 2.5 of [<a href="#saml2hokap">SAML2HokAP</a>]. The Service Provider MUST also
+be able to verify the holder-of-key assertion if the <code>&lt;saml2:SubjectConfirmationData&gt;</code>
+element contains a <code>&lt;ds:KeyValue&gt;</code> element, see <a href="#message-content-requirements-for-holder-of-key">6.2.2</a>.</p>
+<p><a name="conditions"></a></p>
+<h4 id="633-conditions">6.3.3. Conditions</h4>
+<p>The Service Provider MUST assert that the value of the
+<code>&lt;saml2:Audience&gt;</code> element under the
+<code>&lt;saml2:AudienceRestriction&gt;</code> element matches the unique entityID of
+the Service Provider.</p>
+<p>The Service Provider MUST verify that the time instant at which the
+assertion is validated is within the range given by the <code>NotBefore</code> and
+<code>NotOnOrAfter</code> attributes of the <code>&lt;saml2:Conditions&gt;</code> element
+(allowing for a reasonable clock skew). See also the processing of the
+<code>NotOnOrAfter</code> attribute in <a href="#subject-confirmation">section 6.3.2</a>.</p>
+<p><a name="the-authentication-statement"></a></p>
+<h4 id="634-the-authentication-statement">6.3.4. The Authentication Statement</h4>
+<p>The Service Provider MUST assert that the <code>&lt;saml2:AuthnStatement&gt;</code>
+contains a <code>&lt;saml2:AuthnContext&gt;</code> element that holds a
+<code>&lt;saml2:AuthnContextClassRef&gt;</code> element having as its value the
+authentication context URI indicating under which Level of Assurance the
+authentication was performed. If the Service Provider declared one, or more, 
+<code>&lt;saml2:AuthnContextClassRef&gt;</code> elements under the <code>&lt;saml2p:RequestedAuthnContext&gt;</code>
+element of the authentication request (see <a href="#message-content">section 5.4</a>), 
+the received authentication context URI MUST match one of the declared 
+authentication context URI:s from the request. If not, the Service Provider 
+MUST reject the assertion<sup>*</sup>.</p>
+<blockquote>
+<p>[*]: If the Service Provider does not declare an authentication context URI
+in the authentication request it should be prepared to receive any of the
+authentication context URI:s declared by the Identity Provider in its metadata
+record (see <a href="#identity-providers">section 2.1.3</a>).</p>
+</blockquote>
+<p><a name="general-security-validation"></a></p>
+<h4 id="635-general-security-validation">6.3.5. General Security Validation</h4>
+<p>In order to protect itself from replay attacks, the Service Provider
+MUST ensure that the same assertion is not processed more than once
+within the time it is valid (with respect to the <code>NotOnOrAfter</code> attribute
+of the <code>&lt;saml2:Conditions&gt;</code> element).</p>
+<p>In order to prevent stolen assertions and user impersonation, the
+Service Provider SHOULD implement a validation that rejects an assertion
+if the time given it its <code>IssueInstant</code> attribute compared to the time
+when the response message is received is too great. This time is
+typically on the order of seconds, and limits the time window when a
+stolen assertion could be used.</p>
+<p>If the Service Provider included the attribute <code>ForceAuthn</code> with a value
+of <code>true</code> in the authentication request, the Service Provider SHOULD
+ensure that the <code>AuthnInstant</code> attribute of the
+<code>&lt;saml2:AuthnStatement&gt;</code> element is greater than the time when the
+request was sent (allowing for a reasonable clock skew).</p>
+<p>A reasonable clock skew according to this profile is between 3 and 5 minutes in either direction.</p>
+<p><a name="error-responses"></a></p>
+<h3 id="64-error-responses">6.4. Error Responses</h3>
+<p>If the Identity Provider returns an error, it MUST NOT include any
+assertions in the <code>&lt;saml2p:Response&gt;</code> message.</p>
+<p>An Identity Provider conformant with this profile SHOULD NOT make use of
+any other <code>&lt;saml2p:StatusCode&gt;</code> values than those specified in
+section 3.2.2.2 of
+[<a href="#saml2core">SAML2Core</a>] or in section 3.1.4 of [<a href="#sc-registry">SC.Registry</a>]. 
+The top-level <code>&lt;saml2p:StatusCode&gt;</code> value may only be one of the following error
+identifiers:</p>
+<ul class="list">
+<li><p><code>urn:oasis:names:tc:SAML:2.0:status:Requester</code> – The request could not
+  be performed due to an error on the part of the Service Provider.</p>
+</li>
+<li><p><code>urn:oasis:names:tc:SAML:2.0:status:Responder</code> – The request could not
+  be performed due to an error on the part of the Identity Provider.</p>
+</li>
+<li><p><code>urn:oasis:names:tc:SAML:2.0:status:VersionMismatch</code> – The Identity
+  Provider could not process the request because the version of the
+  request message was incorrect.</p>
+</li>
+</ul>
+<p>If the user cancels an authentication process the Identity Provider
+SHOULD indicate this by assigning the second-level status code to
+<code>http://id.elegnamnden.se/status/1.0/cancel</code>.</p>
+<p>If an Identity Provider displays information describing an error in its
+user interface it MUST also offer ways for the end user to confirm this
+information (for example, by including an OK-button). When the end user
+acknowledges taking part of the information (i.e., clicks on the OK-button),
+the <code>&lt;saml2p:Response&gt;</code> message is posted back to the Service
+Provider according to the HTTP POST binding [<a href="#saml2bind">SAML2Bind</a>].</p>
+<p>If an Identity Provider detects suspicious fraudulent behaviour or if any of its security checks alerts a (possible) fraud, the Identity Provider MUST NOT issue an assertion but instead display an error message. After the end user confirms this error message, the error message posted back to the Service Provider SHOULD contain a second-level status code set to <code>http://id.elegnamnden.se/status/1.0/fraud</code> or <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> (depending on whether the Identity Provider aborted the authentication due to a determined or suspected fraud).</p>
+<p><a name="authentication-for-signature"></a></p>
+<h2 id="7-authentication-for-signature">7. Authentication for Signature</h2>
+<p>“DSS Extension for Federated Central Signing Services”, [<a href="#sc-dss-ext">SC.DSS.Ext</a>],
+defines an extension to the OASIS DSS protocol for providing centralized
+Signature Services within the Sweden Connect Framework. This specification
+defines the communication between a <em>Signature Requestor</em><sup>*</sup> and a
+Signature Service, but does not cover SAML specific requirements
+regarding the user authentication phase that is part of the signature
+process.</p>
+<p>This section defines requirements on the SAML authentication process
+when authentication is requested by a Signature Service, acting as a
+SAML Service Provider. All requirements regarding user authentication
+specified earlier in this profile are still valid. This section extends
+these requirements for the “authentication for signature” process.</p>
+<blockquote>
+<p>[*]: A Signature Requestor is a Service Provider within the federation to which the user previously has logged in to and from where the user initiates a signature operation.</p>
+</blockquote>
+<p><a name="authentication-requests2"></a></p>
+<h3 id="71-authentication-requests">7.1. Authentication Requests</h3>
+<p>Authentication requests from a Signature Service SHALL meet the
+following requirements:</p>
+<ul class="list">
+<li><p>The <code>ForceAuthn</code> attribute of the <code>&lt;saml2p:AuthnRequest&gt;</code> element
+  MUST be set to <code>true</code>.</p>
+</li>
+<li><p>The <code>&lt;saml2p:AuthnRequest&gt;</code> element MUST be signed. This MUST
+  also be indicated in the Signature Service metadata record using the
+  <code>AuthnRequestsSigned</code> attribute (see <a href="#signature-service">section 2.1.4</a>).</p>
+</li>
+</ul>
+<p>If the receiving Identity Provider has declared that it wishes to receive principal selection information about the signer (see <a href="#principal-selection">section 5.3.3</a>), and the Signature Service has received any of the requested attribute values in the <code>Signer</code> element of the <code>SignRequest</code> ([<a href="#sc-dss-ext">SC.DSS.Ext</a>]), the Signature Service SHOULD include those attribute values in a <code>&lt;psc:PrincipalSelection&gt;</code> extension of the authentication request. </p>
+<p>It is RECOMMENDED that the <code>&lt;saml2p:Scoping&gt;</code> element containing a <code>&lt;saml2p:RequesterID&gt;</code> element holding the entityID of the Service Requestor is included in <code>&lt;saml2p:AuthnRequest&gt;</code> messages generated by a Signature Service.</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2p:Scoping&gt;</span>
+  <span class="hljs-section">&lt;saml2p:RequesterID&gt;</span><span class="hljs-attribute">http</span>://www.origsp.com/sp&lt;/saml<span class="hljs-number">2</span>:RequesterID&gt;
+<span class="hljs-section">&lt;/saml2p:Scoping&gt;</span></code></pre><p><em>Example when the <code>&lt;saml2p:RequesterID&gt;</code> element is used to inform the Identity Provider about which Service Provider that requested the signature associated with this request for authentication.</em></p>
+<blockquote>
+<p>The reason for this recommendation is that an Identity Provider may adapt user interfaces or authentication procedures to different Service Providers based on either static configuration or on information found in the Service Provider&#39;s metadata. It can therefore be useful for an Identity Provider to know which Service Provider that requested the signature (<em>Signature Requestor</em>) that caused a Signature Service to request authentication. The Identity Provider may use this information to maintain the same user experience and procedures regardless of whether authentication is requested directly by the Service Provider, or by a Signature Service as a result of a signature request from the same Service Provider.</p>
+</blockquote>
+<p>An Identity Provider that accepts an <code>&lt;saml2p:AuthnRequest&gt;</code> message
+from a Service Provider that has indicated that it is a Signature
+Service<sup>*</sup> MUST provide a user interface that is indicating that the
+end user is performing a signature.</p>
+<blockquote>
+<p>[*]: An Identity Provider identifies a Service Provider as a Signature Service if it declares the <code>http://id.elegnamnden.se/st/1.0/sigservice</code> URI as a service type entity category in its metadata (see <a href="#signature-service">2.1.4</a>).</p>
+</blockquote>
+<p><a name="requesting-display-of-signature-message"></a></p>
+<h4 id="711-requesting-display-of-signature-message">7.1.1. Requesting Display of Signature Message</h4>
+<p>[<a href="#sc-dss-profile">SC.DSS.Profile</a>] specifies that a Signature Requestor may include a
+<code>SignMessage</code> element (as defined by [<a href="#sc-dss-ext">SC.DSS.Ext</a>]) in a signature request.
+This element holds a message that the Identity Provider, which is
+responsible for “authentication for signature”, should present to the
+user that is performing the signature.</p>
+<p>A Signature Service MAY request the Identity Provider to show a sign
+message to the user by including the <code>SignMessage</code> element from the
+signature request as a child element to an <code>&lt;saml2p:Extensions&gt;</code>
+element in the <code>&lt;saml2p:AuthnRequest&gt;</code> message (see section 3.2.1 of
+[<a href="#saml2core">SAML2Core</a>]).</p>
+<p>All Identity Providers compliant with this profile MUST be able to parse and understand
+the <code>SignMessage</code> extension.</p>
+<p>If the <code>Message</code>-element of the <code>SignMessage</code> is to be encrypted, the Service Provider SHOULD consult the Identity Provider&#39;s metadata (<code>&lt;md:EncryptionMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory algorithms defined in the Sweden Connect Framework during the encryption operation, which is compatible with the Identity Provider&#39;s encryption key declared in metadata.</p>
+<p>If an Identity Provider that has ways of determining the principal&#39;s identity before displaying
+a sign message receives a <code>&lt;psc:PrincipalSelection&gt;</code> extension in  the authentication request 
+it SHOULD ensure that the contents of the <code>&lt;psc:PrincipalSelection&gt;</code> extension matches the 
+principal identity. If there is a mismatch, the Identity Provider MUST NOT display the
+sign message, and if the request states that the sign message must be displayed, fail with
+an error response where the second-level status code is set to
+<code>urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal</code> ([<a href="#saml2core">SAML2Core</a>]).</p>
+<blockquote>
+<p>Typical scenarios where the above requirement apply is for the Swedish eIDAS connector that first authenticates a principal and then displays the sign message, and for Identity Providers that prompt the user for its user identity as part of its authentication scheme. In those scenarios the Identity Providers must compare the principal identity with the contents of <code>&lt;psc:PrincipalSelection&gt;</code>, if received in the authentication request. </p>
+</blockquote>
+<p>Identity Providers processing a request containing a <code>SignMessage</code> extension SHALL meet
+the following requirements (in addition to other general requirements associated with requests 
+from signature services):</p>
+<ul class="list">
+<li><p>If the <code>MustShow</code> attribute of the <code>SignMessage</code> extension is set, the Identity Provider
+MUST fail with an error response if the message, for some reason, can not be displayed 
+to the user.</p>
+</li>
+<li><p>The Identity Provider MUST display the sign message to the user in a manner that is consistent 
+with the data format of the sign message. If necessary, the Identity Provider MUST process 
+defined filtering rules on the message. If the present message format is not supported or the 
+sign message for any reason cannot be displayed in a proper manner, the Identity Provider must
+return an error response.</p>
+</li>
+<li><p>If authentication and sign message confirmation by the user was successful, the Identity Provider 
+MUST include the <code>signMessageDigest</code> attribute (see section 3.2.4 of [<a href="#sc-attributes">SC.Attributes</a>]) 
+in the assertion that is issued.</p>
+</li>
+<li><p>The Identity Provider MUST NOT return an assertion without performing an authentication process 
+consistent with the requested authentication context which includes display of a sign message,
+even if the request has no present <code>ForceAuthn</code> attribute or includes a <code>ForceAuthn</code> attribute set 
+to the value <code>false</code>.  </p>
+</li>
+</ul>
+<p><a name="requesting-scal2-signature-activation-data"></a></p>
+<h4 id="712-requesting-scal2-signature-activation-data">7.1.2. Requesting SCAL2 Signature Activation Data</h4>
+<p>The type of signature requested in a signature request is, according to [<a href="#sc-dss-profile">SC.DSS.Profile</a>], specified by the <code>CertType</code> attribute of the <code>&lt;CertRequestProperties&gt;</code> element. When the value of this attribute is set to <code>QC/SSCD</code>, the requested signature is a Qualified Signature created in a Qualified Signature Creation Device (QSCD). To achieve this level of signature the Authentication Request MUST include a request for Signature Activation Data (SAD) for Sole Control Assurance Level 2 (SCAL2) in accordance with the &quot;Signature Activation Protocol for Federated Signing&quot; [<a href="#sc-sap">SC.SAP</a>], and MUST include the <code>SignMessage</code> extension (as described above).</p>
+<p>As pointed out in <a href="#identity-providers">section 2.1.3</a> an Identity Provider that supports processing of SAD requests and issuance of SAD-attributes SHALL advertise this by declaring the service property entity category <code>http://id.elegnamnden.se/sprop/1.0/scal2</code> in its metadata. An Identity Provider that has declared this entity category MUST return a SAD attribute in an issued assertion if the corresponding <code>&lt;saml2p:AuthnRequest&gt;</code> message contains the <code>&lt;sap:SADRequest&gt;</code> extension.</p>
+<p>A SAD returned from the Identity Provider MUST have a signature which can be verified using a certificate from the Identity Provider&#39;s metadata entry. The signature algorithm used to sign the SAD MUST be equivalent to the algorithm used to sign the responses and assertions from the Identity Provider.</p>
+<p>Verification of a received SAD-attribute MUST follow the verification rules specified in section 3.2.3 of [<a href="#sc-sap">SC.SAP</a>].</p>
+<p><a name="authentication-responses2"></a></p>
+<h3 id="72-authentication-responses">7.2. Authentication Responses</h3>
+<p>By including the <code>signMessageDigest</code> attribute (see section 3.2.4 of [<a href="#sc-attributes">SC.Attributes</a>]) 
+in the SAML assertion, the Identity Provider asserts that it has successfully displayed the sign message
+received in the request for the user and that the user has accepted to sign under the context of this sign message. This attribute MUST be included in the issued assertion if a sign message was displayed for, and accepted by, the user.</p>
+<p><a name="cryptographic-algorithms"></a></p>
+<h2 id="8-cryptographic-algorithms">8. Cryptographic Algorithms</h2>
+<p>This section lists the requirements for crypto algorithm support for being compliant with this profile.</p>
+<p>For signature and encryption keys the following requirements apply:</p>
+<ul class="list">
+<li>RSA public keys MUST be at least 2048 bits in length. 3072 bits or more is RECOMMENDED.</li>
+<li>EC public keys MUST be at least 256 bits in length (signature only).<ul class="list">
+<li>The curves NIST Curve P-256, NIST Curve P-384 and NIST Curve P-521 MUST be supported ([<a href="#rfc5480">RFC5480</a>]).</li>
+</ul>
+</li>
+</ul>
+<p>Services conforming to this profile MUST support the mandatory algorithms below, and SHOULD support the algorithms listed as optional.</p>
+<p>The sender of a secure message MUST NOT use an algorithm that is not listed as mandatory in the sections below, unless it is explicitly declared by the peer in its metadata (see [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>]). </p>
+<p>A service processing a message in which an algorithm not listed below has been used MUST refuse to accept the message and respond with an error, unless this algorithm has been declared as preferred or supported by the service in its metadata entry.</p>
+<blockquote>
+<p>This profile does not specify a complete list of blacklisted algorithms. However, there is a need to explicitly point out that the commonly used algorithms SHA-1 for digests and RSA PKCS#1 v1.5 for key transport are considered broken and SHOULD not be used or accepted.</p>
+</blockquote>
+<p>The algorithms below are defined in [<a href="#xmlenc">XMLEnc</a>], [<a href="#xmldsig">XMLDSig</a>] and [<a href="#rfc4051">RFC4051</a>].</p>
+<p><a name="digest-algorithms"></a></p>
+<h3 id="81-digest-algorithms">8.1. Digest Algorithms</h3>
+<p><strong>Mandatory:</strong></p>
+<ul class="list">
+<li>SHA-256, <code>http://www.w3.org/2001/04/xmlenc#sha256</code></li>
+</ul>
+<p><strong>Optional:</strong></p>
+<ul class="list">
+<li>SHA-384, <code>http://www.w3.org/2001/04/xmldsig-more#sha384</code></li>
+<li>SHA-512, <code>http://www.w3.org/2001/04/xmlenc#sha512</code></li>
+</ul>
+<p><a name="signature-algorithms"></a></p>
+<h3 id="82-signature-algorithms">8.2. Signature Algorithms</h3>
+<p><strong>Mandatory:</strong></p>
+<ul class="list">
+<li>RSA-SHA256, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</code></li>
+<li>ECDSA-SHA256, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256</code></li>
+</ul>
+<p><strong>Optional:</strong></p>
+<ul class="list">
+<li>RSA-SHA384, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha384</code></li>
+<li>RSA-SHA512, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha512</code></li>
+<li>ECDSA-SHA384, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384</code></li>
+<li>ECDSA-SHA512, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512</code></li>
+</ul>
+<p><a name="block-encryption-algorithms"></a></p>
+<h3 id="83-block-encryption-algorithms">8.3. Block Encryption Algorithms</h3>
+<p><strong>Mandatory:</strong></p>
+<ul class="list">
+<li>AES128-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes128-cbc</code></li>
+<li>AES192-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes192-cbc</code></li>
+<li>AES256-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes256-cbc</code></li>
+</ul>
+<p><strong>Optional:</strong></p>
+<ul class="list">
+<li>AES128-GCM, <code>http://www.w3.org/2009/xmlenc11#aes128-gcm</code></li>
+<li>AES192-GCM, <code>http://www.w3.org/2009/xmlenc11#aes192-gcm</code></li>
+<li>AES256-GCM, <code>http://www.w3.org/2009/xmlenc11#aes256-gcm</code></li>
+</ul>
+<p><strong>Note:</strong> The AES-CBC algorithm has been reported to have vulnerabilities, but these weaknesses can not be exploited when using signed SAML messages. Also, the support for AES-GCM in SAML software is not sufficiently spread at the time of writing. Therefore, the current version of this profile specifies AES-CBC as the default block encryption algorithm.</p>
+<p>Services supporting the AES-GCM algorithm SHOULD indicate this in its metadata.</p>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;encryption&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">ds:KeyInfo</span> <span class="hljs-attr">xmlns:ds</span>=<span class="hljs-string">&quot;http://www.w3.org/2000/09/xmldsig#&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">ds:X509Data</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">ds:X509Certificate</span>&gt;</span>MIIE+DC...SpWg==<span class="hljs-tag">&lt;/<span class="hljs-name">ds:X509Certificate</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">ds:X509Data</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">ds:KeyInfo</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">&quot;http://www.w3.org/2009/xmlenc11#aes256-gcm&quot;</span>/&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">&quot;http://www.w3.org/2009/xmlenc11#aes128-gcm&quot;</span>/&gt;</span>
+  ...
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:KeyDescriptor</span>&gt;</span></code></pre><p><em>Example of how a service announces that it has support for AES-GCM and wishes peers to use these algorithms when encrypting for the service.</em></p>
+<p><a name="key-transport-algorithms"></a></p>
+<h3 id="84-key-transport-algorithms">8.4. Key Transport Algorithms</h3>
+<p><strong>Mandatory:</strong></p>
+<ul class="list">
+<li>RSA-OAEP-MGF1P, <code>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</code><ul class="list">
+<li>Key transport digest: SHA-1 (<code>http://www.w3.org/2000/09/xmldsig#sha1</code>)</li>
+</ul>
+</li>
+</ul>
+<p>For interoperability reasons the current version of this profile specifies the RSA-OAEP-MGF1P algorithm as the default key transport algorithms. This algorithm&#39;s padding method defaults to the use of SHA-1 as a digest algorithm and also uses the &quot;MGF1 with SHA-1&quot; mask generation function<sup>*</sup>.</p>
+<p><strong>Optional:</strong></p>
+<ul class="list">
+<li>RSA-OAEP-MGF1P, <code>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</code><ul class="list">
+<li>Key transport digest: Any of the digest methods listed as mandatory or optional in section <a href="#digest-algorithms">8.1</a>.</li>
+</ul>
+</li>
+</ul>
+<p>A service wishing to receive encrypted messages where SHA-1 is not used as the key transport digest SHOULD indicate this in its metadata using the <code>&lt;md:EncryptionMethod&gt;</code> element as the example below.</p>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">ds:DigestMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/04/xmlenc#sha256&quot;</span>/&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:EncryptionMethod</span>&gt;</span>
+...</code></pre><p><em>Example of how a service announces that it wishes that the peer uses SHA-256 as the key transport digest when encrypting using RSA-OAEP-MGF1P.</em></p>
+<blockquote>
+<p>[*]: Note that the use if SHA-1 in this context (both as digest algoritm and as mask generation function) is limited to providing randomness of padding data and as a hash over optional OAEP parameter data which typically is an empty string. It is not used as a hash function to assert the integrity of the encrypted data. No weaknesses of SHA-1 are known to be relevant to its use in this context.</p>
+</blockquote>
+<p><a name="normative-references"></a></p>
+<h2 id="9-normative-references">9. Normative References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997.</a></p>
+</blockquote>
+<p><a name="xmlenc"></a>
+<strong>[XMLEnc]</strong></p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/xmlenc-core1/">D. Eastlake et al. XML Encryption Syntax and Processing. W3C Recommendation, April 2013</a>.</p>
+</blockquote>
+<p><a name="xmldsig"></a>
+<strong>[XMLDSig]</strong></p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/xmldsig-core1/">D. Eastlake et al. XML-Signature Syntax and Processing, Version 1.1. W3C Recommendation, April 2013</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2errata05"></a>
+<strong>[SAML v2.0 Errata 05]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/errata05/os/saml-v2.0-errata05-os.html">SAML Version 2.0 Errata 05. 01 May 2012. OASIS Approved
+Errata</a>.</p>
+</blockquote>
+<p><a name="saml2bind"></a>
+<strong>[SAML2Bind]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf">OASIS Standard, Bindings for the OASIS Security Assertion Markup
+Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2prof"></a>
+<strong>[SAML2Prof]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf">OASIS Standard, Profiles for the OASIS Security Assertion Markup
+Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2meta"></a>
+<strong>[SAML2Meta]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">OASIS Standard, Metadata for the OASIS Security Assertion Markup
+Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2sec"></a>
+<strong>[SAML2Sec]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf">Security and Privacy Considerations for the OASIS Security Assertion
+Markup Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2iap"></a>
+<strong>[SAML2IAP]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html">SAML V2.0 Identity Assurance Profiles Version 1.0, 05 November
+2010</a>.</p>
+</blockquote>
+<p><a name="saml2metaiop"></a>
+<strong>[SAML2MetaIOP]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf">OASIS Standard, SAML V2.0 Metadata Interoperability Profile Version 1.0, October 2019</a>.</p>
+</blockquote>
+<p><a name="saml2metaui"></a>
+<strong>[SAML2MetaUI]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html">OASIS Draft, SAML V2.0 Metadata Extensions for Login and Discovery
+User Interface Version 1.0, April 2012</a></p>
+</blockquote>
+<p><a name="saml2metaattr"></a>
+<strong>[SAML2MetaAttr]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html">OASIS Committee Specification, SAML V2.0 Metadata Extension for
+Entity Attributes Version 1.0, August
+2009</a>.</p>
+</blockquote>
+<p><a name="saml2metaalg"></a>
+<strong>[SAML2MetaAlgSupport]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupport.html">SAML v2.0 Metadata Profile for Algorithm Support Version 1.0, 21 February 2011</a>.</p>
+</blockquote>
+<p><a name="entcat"></a>
+<strong>[EntCat]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc8409">RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types</a>.</p>
+</blockquote>
+<p><a name="idpdisco"></a>
+<strong>[IdpDisco]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf">OASIS Committee Specification, Identity Provider Discovery Service
+Protocol and Profile, March
+2008</a>.</p>
+</blockquote>
+<p><a name="saml2subjidattr"></a>
+<strong>[SAML2SubjIdAttr]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf">OASIS Committee Specification, SAML V2.0 Subject Identifier Attributes Profile Version 1.0, January 2019</a>.</p>
+</blockquote>
+<p><a name="saml2hokprof"></a>
+<strong>[SAML2HokProf]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.pdf">OASIS Committee Specification, SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0, August 2010</a>.</p>
+</blockquote>
+<p><a name="saml2hokap"></a>
+<strong>[SAML2HokAP]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key.pdf">OASIS Committee Specification, SAML V2.0 Holder-of-Key Assertion Profile Version 1.0, January 2010</a>.</p>
+</blockquote>
+<p><a name="se-trust"></a>
+<strong>[SE.Trust]</strong></p>
+<blockquote>
+<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverket för Svensk e-legitimation</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
+</blockquote>
+<p><a name="sc-attributes"></a>
+<strong>[SC.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-entcat"></a>
+<strong>[SC.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-principal"></a>
+<strong>[SC.Principal]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="sc-dss-ext"></a>
+<strong>[SC.DSS.Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sc-dss-profile"></a>
+<strong>[SC.DSS.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sc-sap"></a>
+<strong>[SC.SAP]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="rfc4051"></a>
+<strong>[RFC4051]</strong></p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc4051.txt">IETF RFC 4051, Additional XML Security Uniform Resource Identifiers, April 2005</a>.</p>
+</blockquote>
+<p><a name="rfc5480"></a>
+<strong>[RFC5480]</strong></p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc5480.txt">IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information, March 2009</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="10-changes-between-versions">10. Changes between versions</h2>
+<p><strong>Changes between version 1.7 and 1.8:</strong></p>
+<ul class="list">
+<li>Section 7.1.2 was updated to state that the requirement to include both a SAD and a SignMessage extension only applies when the requested CertType is &quot;QC/SSCD&quot;. Voluntary use of SAD for other types of signatures (e.g., nonqualified signatures) does not automatically trigger a requirement to include SignMessage.</li>
+</ul>
+<p><strong>Changes between version 1.6 and 1.7:</strong></p>
+<ul class="list">
+<li><p>Sections 2.1.2 and 2.1.3 were updated with clarifications for how a Service Provider declares requested attributes and how an Identity Provider declares its ability to deliver attributes.</p>
+</li>
+<li><p>Section 6.2.1, &quot;Attribute Release and Consuming Rules&quot;, was updated with a privacy requirement that tells that an Identity Provider must not release identity attributes not requested by the Service Provider.</p>
+</li>
+<li><p>Section 2.1.3.1, &quot;Declaring Authorized Scopes&quot;, was introduced in order to define how an Identity Provider declares authorized scopes. Section 6.2.1, &quot;Attribute Release and Consuming Rules&quot;, was updated with release and consumption rules for scoped attributes.</p>
+</li>
+<li><p>Support for the Holder-of-key Web Browser SSO Profile has been added.</p>
+</li>
+<li><p>Removed text in section 7, &quot;Authentication for Signature&quot;, regarding the use of the deprecated sigmessage URI:s.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.5 and 1.6:</strong></p>
+<ul class="list">
+<li><p>In order to facilitate algorithm interoperability between peers additions concerning &quot;Metadata Profile for Algorithm Support&quot; [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>] was added. Section 2.1.1 was updated with a section defining how preferred algorithms are declared in metadata, and sections 5.2, 6.1 and 7.2.1 was updated with requirements for algorithm selection during signing and encryption.</p>
+</li>
+<li><p>Section 5.3, &quot;Message Content&quot;, was re-structured with subchapters for requested authentication contexts, scoping and principal selection.</p>
+</li>
+<li><p>The <code>PrincipalSelection</code> and <code>RequestedPrincipalSelection</code> extensions were introduced to sections 2.1.3, 5.3.3 and 7.2.</p>
+</li>
+<li><p>The link for the &quot;Tillitsramverk för Svensk e-legitimation&quot; specification was updated.</p>
+</li>
+<li><p>This profile is no longer normatively dependent upon SAML2Int. Therefore, the profile has been updated with requirements that previously was implicit (due to the normative dependency to SAML2Int).</p>
+</li>
+<li><p>Section 8, &quot;Cryptographic Algorithms&quot;, was introduced in order to clearly define the algorithm requirements for services that are conformant to this profile.</p>
+</li>
+<li><p>Section 2.1.1 was updated with elaborations concerning certificates in metadata.</p>
+</li>
+<li><p>Section 7.2.1 was updated with a requirement that ensures that a sign message is only displayed to the intended user.</p>
+</li>
+<li><p>Section 7, &quot;Authentication for Signature&quot;, was updated where &quot;Sign Message Authentication Context URI&quot; were deprecated
+and the use of the <code>signMessageDigest</code> attribute was introduced.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.4 and 1.5:</strong></p>
+<ul class="list">
+<li>Section 2.1.3 &quot;Identity Providers&quot;, was extended to include requirements on metadata to signal support for the SAP (Signature Activation Protocol).</li>
+<li>Section 7.2, &quot;Authentication Requests&quot;, was extended to recommend the usage of the <code>&lt;saml2p:RequesterID&gt;</code> element within <code>&lt;saml2p:Scoping&gt;</code>. The reason for this recommendation is that Identity Providers may need information about the &quot;Signature Requestor&quot;, i.e., the Service Provider that requested the signature that caused a Signature Service to request authentication.</li>
+<li>Section 6.3.4, &quot;The Authentication Statement&quot;, contained a requirement about how to process a received authentication context URI that was incorrect. This has been corrected.</li>
+<li>A new section, 7.2.2, &quot;Requesting SCAL2 Signature Activation Data&quot;, was added. This amendment describes how and when to request Signature Activation Data from an Identity Provider in order to enable a signature service to operate as a Qualified Signature Creation Device (QSCD).</li>
+<li>Attribute release rules have been clarified in sections 2.1.2, &quot;Service Providers&quot; and 6.2.1, &quot;Attribute Release Rules&quot;.</li>
+<li>Section 2.1.2, &quot;Service Providers&quot;, was updated to include a requirement for Service Providers communicating with a centralized discovery service.</li>
+<li>Section 5.3, &quot;Message Content&quot;, was updated to describe the use of <code>&lt;saml2p:IDPEntry&gt;</code> elements under the <code>&lt;samp2p:Scoping&gt;</code> elements for requests sent to Identity Providers acting as proxies for other Identity Providers.</li>
+<li>The reference to [<a href="#saml2metaui">SAML2MetaUI</a>] was updated to the latest official version: <a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html">http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html</a>.</li>
+<li>The reference to [<a href="#entcat">EntCat</a>] was updated to the latest version. </li>
+</ul>
+<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
+<ul class="list">
+<li><p>Version 1.3 of this profile stated that a
+  <code>&lt;saml2p:AuthnRequest&gt;</code> message MUST contain an
+  <code>AssertionConsumerServiceURL</code> attribute identifying the desired
+  response location. It has shown that this requirement aggravates
+  interoperability since some of the major providers of Service
+  Provider software do not fully support this attribute. Furthermore,
+  the requirement does increase security since an Identity Provider
+  may only post response messages to locations registered in the
+  <code>&lt;md:AssertionConsumerService&gt;</code> elements of the Service Provider
+  metadata entry. Therefore, chapter 5.3, “Message Content”, has been
+  changed to state that the <code>&lt;saml2p:AuthnRequest&gt;</code> message SHOULD
+  contain an <code>AssertionConsumerServiceURL</code> attribute. Changes have also
+  been made to sections 5.4.2 and 6.3.2 where processing requirements
+  were updated.</p>
+</li>
+<li><p>In section 5.3, a clarification regarding specifying more than one
+  authentication context URI was made.</p>
+</li>
+<li><p>In section 7.1, a set of authentication context URIs for the eIDAS
+  Framework was added.</p>
+</li>
+<li><p>In section 6.4, the requirement to use the sublevel status code
+  <code>http://id.elegnamnden.se/status/1.0/cancel</code> was added. This status
+  should be used to indicate a cancelled operation.</p>
+</li>
+<li><p>In section 6.4, the status codes <code>http://id.elegnamnden.se/status/1.0/fraud</code> and <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> were introduced. Their purpose is to alert (suspected) fraudulent behaviour.</p>
+</li>
+<li><p>The specification for “Discovery within the Swedish eID Framework”
+  has been deprecated and requirements referring to this document have
+  been updated.</p>
+</li>
+<li><p>A clarification to section 5.2 was made stating that conformant
+Identity Providers MUST support the HTTP-POST binding.</p>
+</li>
+<li><p>Section 6.2 was updated with requirements for proxy-IdP:s that are expected to include the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element holding the entityID of the Identity Provider that provided the authentication of the principal.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
+<ul class="list">
+<li><p>This profile now extends a newer version of the SAML2Int Deployment
+  Profile (see <a href="http://saml2int.org/profile/current/">http://saml2int.org/profile/current/</a>).</p>
+</li>
+<li><p>Clarifications on how entity categories are represented in metadata
+  were made to chapters: 2.1.2, 2.1.3, and 2.1.4.</p>
+</li>
+<li><p>Changes were made to chapter 6.1, “Security Requirements”, where the
+  profile now requires the entire <code>&lt;saml2p:Response&gt;</code> message to
+  be signed, as compared to the previous version where the signature
+  requirement was put on <code>&lt;saml2:Assertion&gt;</code> elements.</p>
+</li>
+<li><p>In chapter 6.2, it is now specified that an Address attribute MUST
+  be part of the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element. The
+  previous version stated SHOULD.</p>
+</li>
+<li><p>Chapter 6.2.1, “Attribute Release Rules”, was introduced to clarify
+  how the attribute release process should be handled by an issuing
+  entity.</p>
+</li>
+<li><p>A Service Provider is now obliged to explicitly specify the required
+  Level of Assurance under which a specific authentication should be
+  performed. This is specified in chapter 5.3, “Message Content”, and
+  5.4.4, “Authentication Context and Level of Assurance Handling”.</p>
+</li>
+<li><p>The specification “Authentication Context Classes for Levels of
+  Assurance for the Swedish eID Framework” has been removed from the
+  Swedish eID Framework. The reason for this is that it was proven
+  difficult to make use of the <code>&lt;saml2:AuthnContextDecl&gt;</code> element
+  to store authentication context parameters, and that no commercial,
+  or open source, Identity Provider software had support for this
+  feature. [SC.Attributes] now describe how the <code>authContextParams</code>
+  attribute may be used for the same purpose, and the examples where
+  this information was stored under the <code>&lt;saml2:AuthnContextDecl&gt;</code>
+  element was removed from chapter 6.2, “Message Content”.</p>
+</li>
+<li><p>Chapter 7, “Authentication for Signature”, was introduced to specify
+  requirements regarding the process of “authentication for signature”
+  where a <em>Signature Service</em> requests that a user performing a
+  signature authenticates.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li><p>This profile now explicitly defines requirements for the use of
+  signed authentication request messages, see sections 2.1and 5.2.</p>
+</li>
+<li><p>This profile now allows the HTTP-POST binding to be used for sending
+  authentication request messages (see chapter 5.2, “Binding and
+  Security Requirements”). The main reason for this is to facilitate
+  the use of signed authentication request messages.</p>
+</li>
+<li><p>In chapter 5.4, additional processing requirements for received
+  authentication requests were added or changed. These include:</p>
+</li>
+<li><p>  Validation of assertion consumer addresses (5.4.1).</p>
+</li>
+<li><p>  Clarifications to chapter 5.4.4.</p>
+</li>
+<li><p>  Single Sign On processing (5.4.5).</p>
+</li>
+<li><p>This profile now states that “Unsolicited response” messages are not
+  accepted by Service Providers due to security reasons, see chapter
+  6.1, “Security Requirements”.</p>
+</li>
+<li><p>Changes and additions in chapter 6.2, “Message Content”, for
+  responses including:</p>
+</li>
+<li><p>Clarifications about the usage of the <code>AuthnInstant</code> attribute of the
+  <code>&lt;saml2:AuthnStatement&gt;</code> element.</p>
+</li>
+<li><p>Specifications of the use of <code>&lt;saml2:SubjectConfirmation&gt;</code> in
+  assertions.</p>
+</li>
+<li><p>Clarifications on the use of audience restrictions and assertion
+  validity.</p>
+</li>
+<li><p>Chapter 6.3, “Processing Requirements”, was added. This chapter
+  contains specifications and requirements of how a response message
+  should be processed in order to maintain security.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li><p>In chapter 5.1, “Discovery”, a reference to the specification
+  “Discovery within the Swedish eID Framework” [Eid2Disco] was
+  added.</p>
+</li>
+<li><p>In chapter 5.4.4, a note was added that informs about the need to
+  ensure IdP-capabilities regarding level of assurance before issuing
+  a request.</p>
+</li>
+<li><p>In chapter 6.2, “Message Content”, an example of how an Identity
+  Provider may include an authentication context class declaration was
+  provided.</p>
+</li>
+<li><p>  Some faulty references were corrected.</p>
+</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/03_-_Registry_for_Identifiers.html b/docs/december-2024/03_-_Registry_for_Identifiers.html
new file mode 100644
index 0000000..3140dbb
--- /dev/null
+++ b/docs/december-2024/03_-_Registry_for_Identifiers.html
@@ -0,0 +1,1204 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Sweden Connect - Registry for identifiers</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-landscape.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="sweden-connect---registry-for-identifiers">Sweden Connect - Registry for identifiers</h1>
+<h3 id="version-18---2024-12-04">Version 1.8 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-309</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#background"><strong>Background</strong></a></p>
+</li>
+<li><p><a href="#structure"><strong>Structure</strong></a></p>
+<p> 2.1. <a href="#uri-identifiers">URI Identifiers</a></p>
+<p> 2.2. <a href="#oid-identifiers">OID Identifiers</a></p>
+</li>
+<li><p><a href="#assigned-identifiers"><strong>Assigned Identifiers</strong></a></p>
+<p> 3.1. <a href="#url-identifiers">URL Identifiers</a></p>
+<p> 3.1.1. <a href="#authentication-context-uris">Authentication Context URIs</a></p>
+<p> 3.1.1.1. <a href="#authentication-context-uris-for-swedish-non-residents">Authentication Context URIs for Swedish Non-residents</a></p>
+<p> 3.1.1.2. <a href="#authentication-context-uris-for-uncertified-providers">Authentication Context URIs for Uncertified Providers</a></p>
+<p> 3.1.2. <a href="#attribute-sets">Attribute Sets</a></p>
+<p> 3.1.3. <a href="#entity-category-identifiers">Entity Category Identifiers</a></p>
+<p> 3.1.3.1. <a href="#service-entity-categories">Service Entity Categories</a></p>
+<p> 3.1.3.2. <a href="#entity-categories-for-service-properties">Entity Categories for Service Properties</a></p>
+<p> 3.1.3.3. <a href="#entity-categories-for-service-type">Entity Categories for Service Type</a></p>
+<p> 3.1.3.4. <a href="#entity-categories-for-service-contract">Entity Categories for Service Contract</a></p>
+<p> 3.1.3.5. <a href="#general-entity-categories">General Entity Categories</a></p>
+<p> 3.1.4. <a href="#saml-protocol-status-codes">SAML Protocol Status Codes</a></p>
+<p> 3.1.5. <a href="#central-signing">Central Signing</a></p>
+<p> 3.1.6. <a href="#authentication-context">Authentication Context</a></p>
+<p> 3.1.7. <a href="#sign-response-status-codes">Sign Response Status Codes</a></p>
+<p> 3.1.8. <a href="#name-registration-authorities">Name Registration Authorities</a></p>
+<p> 3.1.9. <a href="#eidas-identifiers">eIDAS Identifiers</a></p>
+<p> 3.1.9.1. <a href="#eidas-proxy-service-aliases">eIDAS Proxy Service Aliases</a></p>
+<p> 3.1.9.2. <a href="#eidas-connector-aliases">eIDAS Connector Aliases</a></p>
+<p> 3.1.9.3. <a href="#identity-binding-processes">Identity Binding Processes</a></p>
+<p> 3.2. <a href="#oid-identifiers3">OID Identifiers</a></p>
+<p> 3.2.1. <a href="#asn1-declarations">ASN.1 Declarations</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p><a name="background"></a></p>
+<h2 id="1-background">1. Background</h2>
+<p>The implementation of a Swedish infrastructure for electronic
+identification and electronic signature requires various types of
+identifiers to represent objects in protocols and data structures.</p>
+<p>This document defines the structure for identifiers assigned by the Sweden Connect Framework and provides a registry for assigned identifiers.</p>
+<p>The following types of identifiers are assigned in this document:</p>
+<ul class="list">
+<li><p>  URI (Uniform Resource Identifier)</p>
+</li>
+<li><p>  OID (Object Identifier)</p>
+</li>
+</ul>
+<p>This registry is limited to registering assigned identifiers.
+Identifiers in this registry are typically defined within the context of
+a separate specification, which defines the semantic meaning of the
+identifier within the context of a particular protocol and/or data
+structure. Where applicable, this registry provides references to the
+documents where the exact meaning of each identifier is defined.</p>
+<p><a name="structure"></a></p>
+<h2 id="2-structure">2. Structure</h2>
+<p>The basic structure of identifiers assigned by the Sweden Connect Framework is based on the following components:</p>
+<table>
+<thead>
+<tr>
+<th><strong>Parameter</strong></th>
+<th><strong>Description</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>Prefix</strong></td>
+<td>The leading portion of the identifier that associates the identifier with this registry and identifies the Swedish e-identification board or Sweden Connect as the assigner of the identifier.</td>
+</tr>
+<tr>
+<td><strong>Category</strong></td>
+<td>A code for the category of an identifier. Each category is a defined context for a collection of identifiers within the scope of a protocol, service or object type.</td>
+</tr>
+<tr>
+<td><strong>Version</strong> (optional)</td>
+<td>An indicator of the version of the object represented by this identifier. The exact semantic of the version indicator, if present, is defined within each category.</td>
+</tr>
+<tr>
+<td><strong>Identifier</strong></td>
+<td>A sequence of characters or numbers (according to the syntax of the identifier type), which distinguish this identifier among all other identifiers within a particular prefix, category and version.</td>
+</tr>
+</tbody></table>
+<p><a name="uri-identifiers"></a></p>
+<h3 id="21-uri-identifiers">2.1. URI Identifiers</h3>
+<p>All URI identifiers in this registry are of URL type (Uniform Resource
+Locator), assigned under the prefixes <code>http://id.elegnamnden.se</code> and <code>http://id.swedenconnect.se</code>.</p>
+<p>These URL identifiers are defined using the following structure:</p>
+<ul class="list">
+<li><strong><code>http://id.elegnamnden.se/{category}[/{version}]/{identifier}</code></strong>, or,</li>
+<li><strong><code>http://id.swedenconnect.se/{category}[/{version}]/{identifier}</code></strong>.</li>
+</ul>
+<p><a name="oid-identifiers"></a></p>
+<h3 id="22-oid-identifiers">2.2. OID Identifiers</h3>
+<p>An object identifier consists of a node in a hierarchically-assigned
+namespace, formally defined using the ITU-T&#39;s ASN.1 standard, X.690.
+Successive numbers of the nodes, starting at the root of the tree,
+identify each node in the tree. Designers set up new nodes by
+registering them under the node&#39;s registration authority. The root of
+the tree contains the following three arcs:</p>
+<ul class="list">
+<li>  0: ITU-T</li>
+<li>  1: ISO</li>
+<li>  2: joint-iso-itu-t</li>
+</ul>
+<p>Object identifiers are in this document represented as a string
+containing a sequence of integers separated by a dot (“.”), e.g.
+2.3.4.25, where each integer represents a node in the hierarchy.</p>
+<p>The node assigned to the Swedish E-identification Board/Sweden Connect is: <strong>1.2.752.201</strong>.</p>
+<p>This represents a hierarchical structure of nodes in the following
+sequence:</p>
+<ul class="list">
+<li>  1 = ISO</li>
+<li>  2 = ISO member body</li>
+<li>  752 = The Swedish Standardization Institute (SIS-ITS)</li>
+<li>  201 = Swedish E-identification Board (see note below)</li>
+</ul>
+<p>This node is used as the Prefix (root node) for all OID identifiers in
+this registry, using the following structure:</p>
+<p><strong>1.2.752.201.{category}.{identifier}</strong></p>
+<p>OID identifiers according to this structure assign a node for each
+category and an identifier node under this category node. No node in
+this structure is assigned as version node. Version is handled, when
+necessary, within the identifier portion of the OID, typically by
+assigning a new identifier.</p>
+<p><strong>Note</strong>: The OID 1.2.752.201 was assigned to the Swedish E-identification Board, but
+this organisation has been overtaken by the Swedish Agency for Digital Government (Digg) who 
+now uses this OID arc for the Sweden Connect Framework.</p>
+<p><a name="assigned-identifiers"></a></p>
+<h2 id="3-assigned-identifiers">3. Assigned Identifiers</h2>
+<p><a name="url-identifiers"></a></p>
+<h3 id="31-url-identifiers">3.1. URL Identifiers</h3>
+<p>The following category codes are defined:</p>
+<table>
+<thead>
+<tr>
+<th><strong>Code</strong></th>
+<th><strong>Category</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>loa</strong></td>
+<td>Level of Assurance. Identifiers representing level of assurance for federated identity (Tillitsnivå).</td>
+</tr>
+<tr>
+<td><strong>ac</strong></td>
+<td>Attribute profile.</td>
+</tr>
+<tr>
+<td><strong>ec</strong></td>
+<td>Entity Category. Generic service type declarations for service matching.</td>
+</tr>
+<tr>
+<td><strong>sprop</strong></td>
+<td>Service Property. Specific entity category identifiers for specific service property.</td>
+</tr>
+<tr>
+<td><strong>st</strong></td>
+<td>Service Type. Specific entity category identifiers for defined types of services in the federation.</td>
+</tr>
+<tr>
+<td><strong>contract</strong></td>
+<td>Service contract. Specific entity category identifiers for declaring contract, or business agreement, affiliation within a federation.</td>
+</tr>
+<tr>
+<td><strong>csig</strong></td>
+<td>Central Signing Service – Identifiers used by the central signing service infrastructure.</td>
+</tr>
+<tr>
+<td><strong>auth-cont</strong></td>
+<td>Authentication context information schema.</td>
+</tr>
+<tr>
+<td><strong>status</strong></td>
+<td>SAML Protocol status codes.</td>
+</tr>
+<tr>
+<td><strong>sig-status</strong></td>
+<td>Sign response status codes.</td>
+</tr>
+<tr>
+<td><strong>eidas</strong></td>
+<td>Identifiers used for integration with the eIDAS Framework.</td>
+</tr>
+<tr>
+<td><strong>ns</strong></td>
+<td>XML Schema namespaces.</td>
+</tr>
+</tbody></table>
+<p><a name="authentication-context-uris"></a></p>
+<h4 id="311-authentication-context-uris">3.1.1. Authentication Context URIs</h4>
+<p>Authentication Context URIs representing assurance levels (Tillitsnivåer) relevant to
+[<a href="#se-trust">SE.Trust</a>] and [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa1</code></td>
+<td align="left">Assurance level 1.</td>
+<td align="left">[<a href="#se-trust">SE.Trust</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa2</code></td>
+<td align="left">Assurance level 2.</td>
+<td align="left">[<a href="#se-trust">SE.Trust</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa3</code></td>
+<td align="left">Assurance level 3.</td>
+<td align="left">[<a href="#se-trust">SE.Trust</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa4</code></td>
+<td align="left">Assurance level 4.</td>
+<td align="left">[<a href="#se-trust">SE.Trust</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-low</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level low for non-notified and notified eID schemes.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-sub</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level substantial for non-notified and notified eID schemes.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-high</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level high for non-notified and notified eID schemes.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level low using an eID scheme that MUST be notified.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-sub</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level substantial using an eID scheme that MUST be notified.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-high</code><sup>*</sup></td>
+<td align="left">Authentication accordance to eIDAS assurance level high using an eID scheme that MUST be notified.</td>
+<td align="left">[<a href="#eidas">eIDAS</a>]</td>
+</tr>
+</tbody></table>
+<p><strong>NOTE:</strong> eIDAS assurance levels low, substantial and high have the
+following <code>AuthnContextClassRef</code> URI:s defined by the EU commission:</p>
+<ul class="list">
+<li><p>  <code>http://eidas.europa.eu/LoA/low</code></p>
+</li>
+<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/low</code> (for non-notified eID schemes)</p>
+</li>
+<li><p>  <code>http://eidas.europa.eu/LoA/substantial</code></p>
+</li>
+<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/substantial</code> (for non-notified eID schemes)</p>
+</li>
+<li><p>  <code>http://eidas.europa.eu/LoA/high</code></p>
+</li>
+<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/high</code> (for non-notified eID schemes)</p>
+</li>
+</ul>
+<blockquote>
+<p>[*]: The authentication context URI:s are intended to be used to represent authentication
+over the eIDAS authentication framework using an official eIDAS-connector. Authorization to 
+issue assertions using these authentication context URI:s is determined by declaration of the
+&quot;assurance certification&quot; for the connector (see section 2.1.3 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]).</p>
+</blockquote>
+<p><a name="authentication-context-uris-for-swedish-non-residents"></a></p>
+<h5 id="3111-authentication-context-uris-for-swedish-non-residents">3.1.1.1. Authentication Context URIs for Swedish Non-residents</h5>
+<p>The Swedish assurance framework, [<a href="#se-trust">SE.Trust</a>], states that a Swedish eID
+according to any of the defined assurance levels must only be issued to an individual holding
+a Swedish personal identity number (personnummer) or a Swedish coordination number 
+(samordningsnummer).</p>
+<p>In some cases, a certified eID-issuer may also issue eIDs to persons that do not hold
+a Swedish identity number (non-residents). If this is the case, and the original 
+identification of the person has a strength that corresponds to the requirements 
+put in [<a href="#se-trust">SE.Trust</a>], a certified Identity Provider or OpenID Provider MAY use the URIs
+defined below:</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa2-nonresident</code></td>
+<td align="left">A URI that is indented to be used by a level 2-certified providers that authenticate a non-resident eID holder according to assurance level 2 - <code>http://id.elegnamnden.se/loa/1.0/loa2</code>.</td>
+<td align="left">This document</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa3-nonresident</code></td>
+<td align="left">A URI that is indented to be used by a level 3-certified providers that authenticate a non-resident eID holder according to assurance level 3 - <code>http://id.elegnamnden.se/loa/1.0/loa3</code>.</td>
+<td align="left">This document</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa4-nonresident</code></td>
+<td align="left">A URI that is indented to be used by a level 4-certified providers that authenticate a non-resident eID holder according to assurance level 4 - <code>http://id.elegnamnden.se/loa/1.0/loa4</code>.</td>
+<td align="left">This document</td>
+</tr>
+</tbody></table>
+<p><strong>Note:</strong> An Identity Provider, or OpenID Provider, that includes any of the above URIs in an issued assertion/ID Token, MUST NOT provide the Swedish personal identity number as an identity attribute/claim. 
+This is per definition since these URIs are intended to be used for non-residents (i.e., they do not hold a Swedish identity number).</p>
+<p><a name="authentication-context-uris-for-uncertified-providers"></a></p>
+<h5 id="3112-authentication-context-uris-for-uncertified-providers">3.1.1.2. Authentication Context URIs for Uncertified Providers</h5>
+<p>The assurance levels defined in section <a href="#authentication-context-uris">3.1.1</a> may only be used by Identity Providers, or OpenID Providers, that have been reviewed and approved by the Swedish Agency for Digital Government (Digg) according to [<a href="#se-trust">SE.Trust</a>]. For providers that have not undergone a review process but make a self declaration to be compliant with [<a href="#se-trust">SE.Trust</a>] this specification defines the following authentication context URIs:</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>uncertified-loa2</code></td>
+<td align="left">URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 2 - <code>http://id.elegnamnden.se/loa/1.0/loa2</code>.</td>
+<td align="left">This document</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>uncertified-loa3</code></td>
+<td align="left">URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 3 - <code>http://id.elegnamnden.se/loa/1.0/loa3</code>.</td>
+<td align="left">This document</td>
+</tr>
+</tbody></table>
+<p>Proxy providers that have eIDAS authentication as an option MUST NOT use the eIDAS authentication context URIs defined in section <a href="#authentication-context-uris">3.1.1</a>, instead they should use:</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-low</code></td>
+<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-low</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code> in an assertion from the official Swedish eIDAS-connector.</td>
+<td align="left">This document</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-sub</code></td>
+<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-sub</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-sub</code> in an assertion from the official Swedish eIDAS-connector.</td>
+<td align="left">This document</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-high</code></td>
+<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-high</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-high</code> in an assertion from the official Swedish eIDAS-connector.</td>
+<td align="left">This document</td>
+</tr>
+</tbody></table>
+<p><a name="attribute-sets"></a></p>
+<h4 id="312-attribute-sets">3.1.2. Attribute Sets</h4>
+<p>Identifiers for attribute sets defined in the Sweden Connect SAML Attribute Specification.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>Identifier</strong></th>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">ELN-AP-Pseudonym-01</td>
+<td align="left"><code>http://id.elegnamnden.se/ap/1.0/pseudonym-01</code></td>
+<td align="left">Pseudonym identity attribute set.</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">ELN-AP-NaturalPerson-01</td>
+<td align="left"><code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></td>
+<td align="left">Personal identity without civic registration number attribute set.</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">ELN-AP-Pnr-01</td>
+<td align="left"><code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></td>
+<td align="left">Personal identity with civic registration number attribute set.</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">ELN-AP-OrgPerson-01</td>
+<td align="left"><code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></td>
+<td align="left">Organizational identity attribute set.</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">ELN-AP-eIDAS-NatPer-01</td>
+<td align="left"><code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></td>
+<td align="left">Natural person identity for the eIDAS Framework.</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">DIGG-AP-HSAid-01</td>
+<td align="left"><code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code></td>
+<td align="left">Natural Person Identity with HSA-ID</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="entity-category-identifiers"></a></p>
+<h4 id="313-entity-category-identifiers">3.1.3. Entity Category Identifiers</h4>
+<p>Identifiers for categories of service entities, specified as an “Entity Attribute” in the SAML federation metadata.</p>
+<p><a name="service-entity-categories"></a></p>
+<h5 id="3131-service-entity-categories">3.1.3.1. Service Entity Categories</h5>
+<p>Identifiers for entity categories representing alternative sets of requirements.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa2-pnr</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa3-pnr</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/sc/uncertified-loa3-pnr</code></td>
+<td align="left">Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa4-pnr</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/eidas-naturalperson</code></td>
+<td align="left">Service consuming/providing assertions based on any eIDAS assurance level, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/eidas-pnr-delivery</code></td>
+<td align="left">Service providing assertions to eIDAS services via Swedish eIDAS-node</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-hsaid</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code>.</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/sc/uncertified-loa3-hsaid</code></td>
+<td align="left">Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code>.</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa2-orgid</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-orgid</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa4-orgid</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa2-name</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-name</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa4-name</code></td>
+<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="entity-categories-for-service-properties"></a></p>
+<h5 id="3132-entity-categories-for-service-properties">3.1.3.2. Entity Categories for Service Properties</h5>
+<p>Identifiers for defined service properties.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/sprop/1.0/mobile-auth</code></td>
+<td align="left">Service adapted to require/provide user authentication based on mobile devices.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/sprop/1.0/scal2</code></td>
+<td align="left">Service adapted to support authentication requests from signature services supporting Sole Control Assurance Level 2 (SCAL2).</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="entity-categories-for-service-type"></a></p>
+<h5 id="3133-entity-categories-for-service-type">3.1.3.3. Entity Categories for Service Type</h5>
+<p>Identifiers for defined service types.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/st/1.0/sigservice</code></td>
+<td align="left">Electronic signature service</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code></td>
+<td align="left">Public sector Service Provider</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code></td>
+<td align="left">Private sector Service Provider</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="entity-categories-for-service-contract"></a></p>
+<h5 id="3134-entity-categories-for-service-contract">3.1.3.4. Entity Categories for Service Contract</h5>
+<p>Service Contract Entity Category identifiers are indented for performing service matching based on contracts, or business agreements, between providing and consuming services.</p>
+<p>All Service Contract identifiers are prefixed with <code>http://id.swedenconnect.se/contract/&lt;org&gt;</code>, where <code>org</code> is the identifier for the defining organization.</p>
+<p>The Sweden Connect Framework specifications do not define any Service Contract identifiers, instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.</p>
+<p><a name="general-entity-categories"></a></p>
+<h5 id="3135-general-entity-categories">3.1.3.5. General Entity Categories</h5>
+<p>An entity category of the General Entity Category type is a category that does not fit into any of the other category types regarding definitions and matching rules.</p>
+<p>General category identifiers are prefixed with <code>http://id.swedenconnect.se/general-ec</code>.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/secure-authenticator-binding</code></td>
+<td align="left">Indicator that a secure authenticator binding is required, or supported.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/accepts-coordination-number</code></td>
+<td align="left">Category for opt-in for the acceptance of Swedish coordination numbers in the personalIdentityNumber attribute.</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/supports-user-message</code></td>
+<td align="left">Indicator that an Identity Provider supports the <code>UserMessage</code> authentication request extension, see [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>].</td>
+<td align="left">[<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="saml-protocol-status-codes"></a></p>
+<h4 id="314-saml-protocol-status-codes">3.1.4. SAML Protocol Status Codes</h4>
+<p>Status code identifiers for use in SAML Response messages. The list
+below extends the list of second-level status codes defined in section
+3.2.2.2 of [<a href="#saml2core">SAML2Core</a>].</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/status/1.0/cancel</code></td>
+<td align="left">Status code representing a cancelled operation.</td>
+<td align="left">[<a href="#sc-saml-profile">SC.SAML.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/status/1.0/fraud</code></td>
+<td align="left">Status code indicating a fraudulent request.</td>
+<td align="left">[<a href="#sc-saml-profile">SC.SAML.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/status/1.0/possibleFraud</code></td>
+<td align="left">Status code indicating a possible fraudulent request.</td>
+<td align="left">[<a href="#sc-saml-profile">SC.SAML.Profile</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="central-signing"></a></p>
+<h4 id="315-central-signing">3.1.5. Central Signing</h4>
+<p>Identifiers used in the protocol for requesting services form a central signing service.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/csig/1.0/dss-ext/ns</code></td>
+<td align="left"><strong>Deprecated</strong>. XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.0).</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/csig/1.0/eid2-dss/profile</code></td>
+<td align="left"><strong>Deprecated</strong>. Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.0).</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/csig/1.1/dss-ext/ns</code></td>
+<td align="left">XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.1).</td>
+<td align="left">[<a href="#sc-dss-ext">SC.DSS.Ext</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code></td>
+<td align="left">Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.1).</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/csig/1.1/sap/ns</code></td>
+<td align="left">XML schema name space for the Signature Activation Protocol, extending version 1.1 of the DSS protocol extension</td>
+<td align="left">[<a href="#sc-sap">SC.SAP</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="authentication-context"></a></p>
+<h4 id="316-authentication-context">3.1.6. Authentication Context</h4>
+<p>Identifiers associated with the Authentication Context X.509 extension</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/auth-cont/1.0/saci</code></td>
+<td align="left">XML schema namespace for SAML Authentication Context Information in the Authentication Context X.509 certificate extension</td>
+<td align="left">[<a href="#rfc7773">RFC7773</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info</code></td>
+<td align="left">XML schema namespace for Extended Authentication Information in the Authentication Context X.509 certificate extension</td>
+<td align="left">[<a href="#sc-cert-profile">SC.Cert.Profile</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="sign-response-status-codes"></a></p>
+<h4 id="317-sign-response-status-codes">3.1.7. Sign Response Status Codes</h4>
+<p>Status code identifiers for the DSS Extension for Central Signing services. The following identifiers provide defined status codes for inclusion in a <code>&lt;ResultMinor&gt;</code> element of the <code>&lt;Result&gt;</code> element of a sign response message according to the OASIS standard “Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0” [<a href="#oasis-dss">OASIS-DSS</a>].</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/req-expired</code></td>
+<td align="left">The time window for the signature request has expired.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/user-mismatch</code></td>
+<td align="left">The authenticated user does not match the signer identity attributes in the request.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/unsupported-loa</code></td>
+<td align="left">The requested level of assurance for user authentication is not supported.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/sigmessage-error</code></td>
+<td align="left">A requirement to display sign message was included in the sign request, but the sign service could not establish that the sign message was displayed to the user.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/user-cancel</code></td>
+<td align="left">The end user cancelled the signature operation.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code></td>
+<td align="left">The authentication during the signature operation failed.</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code></td>
+<td align="left">The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud).</td>
+<td align="left">[<a href="#sc-dss-profile">SC.DSS.Profile</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="name-registration-authorities"></a></p>
+<h4 id="318-name-registration-authorities">3.1.8. Name Registration Authorities</h4>
+<p>Some protocols require a URI identifier to uniquely identify the entity responsible for a particular namespace.</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URL</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.elegnamnden.se/eln/name-registration-authority</code></td>
+<td align="left">Identifying the Swedish e-Identification Board<sup>*</sup> as name registration authority, responsible for a particular namespace.</td>
+<td align="left">[<a href="#sc-cert-profile">SC.Cert.Profile</a>]</td>
+</tr>
+</tbody></table>
+<blockquote>
+<p>[*]: This also covers the Swedish Agency for Digital Government (Digg) which has overtaken the Swedish E-identification Board&#39;s assignments.</p>
+</blockquote>
+<p><a name="eidas-identifiers"></a></p>
+<h4 id="319-eidas-identifiers">3.1.9. eIDAS Identifiers</h4>
+<p>This section defines identifiers used within the Sweden Connect Framework to integrate with the eIDAS Framework.</p>
+<p><a name="eidas-proxy-service-aliases"></a></p>
+<h5 id="3191-eidas-proxy-service-aliases">3.1.9.1. eIDAS Proxy Service Aliases</h5>
+<p>Each country within the eIDAS federation provides an eIDAS Proxy Service that is a Proxy Identity Provider for the authentication services within that specific country. The entityID identifier for an eIDAS Proxy Service in another country is not known to a Swedish Service Provider, but there are cases in which the Swedish Service Provider needs to refer to a specific eIDAS Proxy Service. Therefore, this specification defines a URI identifier format for eIDAS Proxy Service aliases. The format is as follows:</p>
+<p><strong><code>http://id.swedenconnect.se/eidas/1.0/proxy-service/{country-code}</code></strong></p>
+<p>where <code>{country-code}</code> is the country identifier in ISO 3166-1 alpha-2 format [<a href="#iso3166">ISO 3166</a>].</p>
+<blockquote>
+<p>A consumer of an eIDAS Proxy Service alias URI MUST accept the country code part of the URI in both lower and upper case letters.</p>
+</blockquote>
+<p><a name="eidas-connector-aliases"></a></p>
+<h5 id="3192-eidas-connector-aliases">3.1.9.2. eIDAS Connector Aliases</h5>
+<p>A Swedish Identity Provider that delivers authentication services to eIDAS, via the Swedish eIDAS Proxy Service, will receive the entityID of the Service Provider from another country that has requested user authentication in a <code>&lt;saml2p:RequesterID&gt;</code> element of the authentication request. Along with this information, the Swedish Proxy Service will also include another <code>RequesterID</code> element that holds the &quot;eIDAS Connector alias&quot; URI, telling from which country the requesting Service Provider resides.</p>
+<p>The format of this alias is as follows:</p>
+<p><strong><code>http://id.swedenconnect.se/eidas/1.0/connector/{country-code}</code></strong></p>
+<p>where <code>{country-code}</code> is the country identifier in ISO 3166-1 alpha-2 format [<a href="#iso3166">ISO 3166</a>].</p>
+<blockquote>
+<p>A consumer of an eIDAS Connector alias URI MUST accept the country code part of the URI in both lower and upper case letters.</p>
+</blockquote>
+<p><a name="identity-binding-processes"></a></p>
+<h5 id="3193-identity-binding-processes">3.1.9.3. Identity Binding Processes</h5>
+<p>Section 3.3.2 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>] describes how the <code>personalIdentityNumberBinding</code> attribute is assigned with one or more &quot;Identity Binding Process URI:s&quot; after an identity binding. The possible values are: </p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>URI</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/populationregister</code></td>
+<td align="left">Unique match of name and birth date between eIDAS identity and the Swedish Population register.</td>
+<td align="left">[<a href="#id-binding">ID-Binding</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/swedish-eid</code></td>
+<td align="left">Digitally signed attestation using a Swedish eID.</td>
+<td align="left">[<a href="#id-binding">ID-Binding</a>]</td>
+</tr>
+</tbody></table>
+<p>The <a href="#id-binding">Binding eIDAS Identities to Records in the Swedish Population Register</a> ([<a href="#id-binding">ID-Binding</a>]) document defines the above processes in detail. </p>
+<p><a name="oid-identifiers3"></a></p>
+<h3 id="32-oid-identifiers">3.2. OID Identifiers</h3>
+<p>Defined categories:</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>Code</strong></th>
+<th align="left"><strong>Category</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>0</strong></td>
+<td align="left">ASN.1 modules</td>
+</tr>
+<tr>
+<td align="left"><strong>1</strong></td>
+<td align="left">Test identifiers</td>
+</tr>
+<tr>
+<td align="left"><strong>2</strong></td>
+<td align="left">Policy identifiers</td>
+</tr>
+<tr>
+<td align="left"><strong>3</strong></td>
+<td align="left">Attribute identifiers</td>
+</tr>
+<tr>
+<td align="left"><strong>4</strong></td>
+<td align="left">”Qualified Certificate” Statement identifiers (RFC 3739)</td>
+</tr>
+<tr>
+<td align="left"><strong>5</strong></td>
+<td align="left">X.509 certificate extension identifiers</td>
+</tr>
+</tbody></table>
+<p>The following OIDs are defined in the ASN.1 declarations in <a href="#asn1-declarations">3.2.1</a>:</p>
+<table>
+<thead>
+<tr>
+<th align="left"><strong>OID</strong></th>
+<th align="left"><strong>Object</strong></th>
+<th align="left"><strong>Reference</strong></th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">1.2.752.201.5.1</td>
+<td align="left">Authentication Context Extension</td>
+<td align="left">[<a href="#rfc7773">RFC7773</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.5.2</td>
+<td align="left">Signature Validation Token Extension</td>
+<td align="left">[<a href="#svt-pdf">SVT-PDF</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.2.1</td>
+<td align="left">Object identifier for the Signature Validation Token RFC 3161 timestamp policy</td>
+<td align="left"></td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.1</td>
+<td align="left">Organization Affiliation Attribute</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.2</td>
+<td align="left">Transaction Identifier</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.3</td>
+<td align="left">Authentication Context Parameters</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.4</td>
+<td align="left">Provisional ID</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.5</td>
+<td align="left">Provisional ID Persistence Indicator</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.6</td>
+<td align="left">Personal Identity Number Binding URI</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.7</td>
+<td align="left">eIDAS Person Identifier</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.8</td>
+<td align="left">Birth name</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.9</td>
+<td align="left">eIDAS Natural Person Address</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.10</td>
+<td align="left">User Certificate</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.11</td>
+<td align="left">User Signature</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.12</td>
+<td align="left">Signature Activation Data</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.13</td>
+<td align="left">Authentication Server Signature</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.14</td>
+<td align="left">Sign Message Digest</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.15</td>
+<td align="left">Previous Personal Identity Number</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+<tr>
+<td align="left">1.2.752.201.3.16</td>
+<td align="left">Mapped Personal Identity Number</td>
+<td align="left">[<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="asn1-declarations"></a></p>
+<h4 id="321-asn1-declarations">3.2.1. ASN.1 Declarations</h4>
+<p>Object Identifier Registry for Sweden Connect<sup>*</sup></p>
+<pre class="hljs"><code><span class="hljs-built_in">id</span>-eleg OBJECT IDENTIFIER ::= {iso(<span class="hljs-number">1</span>) member-body(<span class="hljs-number">2</span>) se(<span class="hljs-number">752</span>) e-legitimationsnamnden(<span class="hljs-number">201</span>)}
+
+<span class="hljs-comment">-- Sweden Connect arcs</span>
+<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">0</span> }    <span class="hljs-comment">-- ASN.1 modules</span>
+<span class="hljs-built_in">id</span>-test   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">1</span> }    <span class="hljs-comment">-- OIDs for test</span>
+<span class="hljs-built_in">id</span>-pol    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Policy</span>
+<span class="hljs-built_in">id</span>-attr   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">3</span> }    <span class="hljs-comment">-- Attributes</span>
+<span class="hljs-built_in">id</span>-qcs    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">4</span> }    <span class="hljs-comment">-- QC Statement</span>
+<span class="hljs-built_in">id</span>-ce     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">5</span> }    <span class="hljs-comment">-- Cert Extensions</span>
+
+<span class="hljs-comment">-- Sweden Connect Modules</span>
+<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>-auth-context<span class="hljs-number">-88</span> OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span> <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Used in RFC 7773</span>
+<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>-auth-context<span class="hljs-number">-08</span> OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span> <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Used in RFC 7773</span>
+
+<span class="hljs-comment">-- Sweden Connect OIDs for test</span>
+
+<span class="hljs-comment">-- Sweden Connect Policies</span>
+<span class="hljs-built_in">id</span>-pol-svt-ts-policy         OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-pol <span class="hljs-number">1</span> }     <span class="hljs-comment">-- SVT RFC 3161 timestamp policy</span>
+
+<span class="hljs-comment">-- Sweden Connect Attributes</span>
+<span class="hljs-built_in">id</span>-attr-org-affiliation      OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Organizational affiliation</span>
+<span class="hljs-built_in">id</span>-attr-<span class="hljs-keyword">transaction</span>-<span class="hljs-built_in">id</span>       OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Transaction identifier</span>
+<span class="hljs-built_in">id</span>-attr-auth-context-params  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">3</span> }    <span class="hljs-comment">-- Authentication context parameters</span>
+<span class="hljs-built_in">id</span>-attr-prid                 OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">4</span> }    <span class="hljs-comment">-- Provisional ID</span>
+<span class="hljs-built_in">id</span>-attr-prid-persistence     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">5</span> }    <span class="hljs-comment">-- Provisional ID persistence indicator</span>
+<span class="hljs-built_in">id</span>-attr-pnr-binding          OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">6</span> }    <span class="hljs-comment">-- Personal Identity Number binding URI</span>
+<span class="hljs-built_in">id</span>-attr-eidas-pid            OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">7</span> }    <span class="hljs-comment">-- eIDAS Person Identifier</span>
+<span class="hljs-built_in">id</span>-attr-birth-<span class="hljs-built_in">name</span>           OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">8</span> }    <span class="hljs-comment">-- Birth name</span>
+<span class="hljs-built_in">id</span>-attr-eidas-np-address     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">9</span> }    <span class="hljs-comment">-- eIDAS Natural Person Address</span>
+<span class="hljs-built_in">id</span>-attr-user-certificate     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">10</span> }   <span class="hljs-comment">-- User certificate</span>
+<span class="hljs-built_in">id</span>-attr-user-signature       OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">11</span> }   <span class="hljs-comment">-- User signature</span>
+<span class="hljs-built_in">id</span>-attr-sad                  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">12</span> }   <span class="hljs-comment">-- Signature activation data</span>
+<span class="hljs-built_in">id</span>-attr-auth-srv-signature   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">13</span> }   <span class="hljs-comment">-- Authentication server signature</span>
+<span class="hljs-built_in">id</span>-attr-sign-message-digest  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">14</span> }   <span class="hljs-comment">-- Sign message digest</span>
+<span class="hljs-built_in">id</span>-attr-previous-pid-<span class="hljs-built_in">number</span>  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">15</span> }   <span class="hljs-comment">-- Previous personal identity number</span>
+<span class="hljs-built_in">id</span>-attr-mapped-pid-<span class="hljs-built_in">number</span>    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">16</span> }   <span class="hljs-comment">-- Mapped personal identity number</span>
+
+<span class="hljs-comment">-- Sweden Connect QC Statement extension</span>
+<span class="hljs-built_in">id</span>-qcs-sid         OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-qcs <span class="hljs-number">1</span> }   <span class="hljs-comment">-- Semantics Identifiers</span>
+<span class="hljs-built_in">id</span>-qcs-statement   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-qcs <span class="hljs-number">2</span> }   <span class="hljs-comment">-- QC statements</span>
+
+<span class="hljs-comment">-- Sweden Connect Certificate Extensions</span>
+<span class="hljs-built_in">id</span>-ce-authContext  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-ce <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Auth context extension used in RFC 7773</span>
+<span class="hljs-built_in">id</span>-ce-svt          OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-ce <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Signature Validation Token extension</span></code></pre><blockquote>
+<p>[*]: The OID 1.2.752.201 was assigned to the Swedish E-identification Board, but this organisation has been overtaken by the Swedish Agency for Digital Government (Digg) who now uses this OID arc for the Sweden Connect Framework.</p>
+</blockquote>
+<p><a name="references"></a></p>
+<h2 id="4-references">4. References</h2>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March 2005</a></p>
+</blockquote>
+<p><a name="oasis-dss"></a>
+<strong>[OASIS-DSS]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html">Digital Signature Service Core Protocols, Elements, and Bindings
+Version 1.0.</a></p>
+</blockquote>
+<p><a name="se-trust"></a>
+<strong>[SE.Trust]</strong></p>
+<blockquote>
+<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverket för Svensk e-legitimation</a>.</p>
+</blockquote>
+<p><a name="rfc7773"></a>
+<strong>[RFC7773]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7773">RFC7773: Authentication Context Certificate Extension</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-entcat"></a>
+<strong>[SC.SAML.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-attrs"></a>
+<strong>[SC.SAML.Attrs]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-umsg"></a>
+<strong>[SC.SAML.UMsg]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="sc-dss-ext"></a>
+<strong>[SC.DSS.Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sc-sap"></a>
+<strong>[SC.SAP]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="sc-dss-profile"></a>
+<strong>[SC.DSS.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sc-cert-profile"></a>
+<strong>[SC.Cert.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing services</a></p>
+</blockquote>
+<p><a name="id-binding"></a>
+<strong>[ID-Binding]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS Identities to Records in the Swedish Population Register</a></p>
+</blockquote>
+<p><a name="svt-pdf"></a>
+<strong>[SVT-PDF]</strong></p>
+<blockquote>
+<p><a href="https://datatracker.ietf.org/doc/draft-santesson-svt-pdf/">PDF Signature Validation Token</a>.</p>
+</blockquote>
+<p><a name="eidas"></a>
+<strong>[eIDAS]</strong></p>
+<blockquote>
+<p>REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE
+COUNCIL of 23 July 2014 on electronic identification and trust
+services for electronic transactions in the internal market and
+repealing Directive 1999/93/EC. Including implementation acts of the
+regulation and associated technical specifications.</p>
+</blockquote>
+<p><a name="iso3166"></a>
+<strong>[ISO 3166]</strong></p>
+<blockquote>
+<p>Country Codes - ISO 3166, <a href="https://www.iso.org/iso-3166-country-codes.html">https://www.iso.org/iso-3166-country-codes.html</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="5-changes-between-versions">5. Changes between versions</h2>
+<p><strong>Changes between version 1.7 and version 1.8:</strong></p>
+<ul class="list">
+<li><p>The document name was changed to &quot;Sweden Connect - Registry for identifiers&quot; from &quot;Swedish eID Framework - Registry for identifiers&quot;.</p>
+</li>
+<li><p>Section 3.1.7, &quot;Sign Response Status Codes&quot;, were extended with error codes for <code>authn-failed</code> and <code>security-violation</code>.</p>
+</li>
+<li><p>Section 3.1.9.3, &quot;Identity Binding Processes&quot;, was introduced where binding process URI:s for matching eIDAS identities to Swedish identity numbers are listed.</p>
+</li>
+<li><p>The <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category was added to section, 3.1.3.5, &quot;General Entity Categories&quot;.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
+<ul class="list">
+<li><p>Section, 3.1.3.5, &quot;General Entity Categories&quot;, was introduced and <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> and <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> was added.</p>
+</li>
+<li><p>In section 3.2, an object identifier (OID) for Signature Validation Token extension was added and one OID for an SVT timestamp policy.</p>
+</li>
+<li><p>Added service entity categories <code>http://id.swedenconnect.se/ec/1.0/loa3-orgid</code> and <code>http://id.swedenconnect.se/ec/1.0/loa3-name</code> to section 3.1.3.1.</p>
+</li>
+<li><p>In section 3.2, the attributes for &quot;previous personal identity number&quot; (<code>1.2.752.201.3.15</code>) and  &quot;mapped personal identity number&quot; (<code>1.2.752.201.3.16</code>) were added.</p>
+</li>
+<li><p>Section 3.1.3.1, &quot;Service Entity Categories&quot;, was updated with categories for loaX-name and loaX-orgid.</p>
+</li>
+<li><p>Authentication context URIs for non-residents and uncertified providers were added to sections 3.1.1.1 and 3.1.1.2.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
+<ul class="list">
+<li><p>The specification was renamed from &quot;Registry for identifiers assigned by the Swedish e-identification board&quot; to &quot;Swedish eID Framework - Registry for identifiers&quot;.</p>
+</li>
+<li><p>The authentication context URIs <code>http://id.swedenconnect.se/loa/1.0/uncertified-loa3</code> and <code>http://id.swedenconnect.se/loa/1.0/uncertified-loa3-sigmessage</code> were introduced in sections 3.1.1 and 3.1.1.1, and the service entity category <code>http://id.swedenconnect.se/ec/sc/uncertified-loa3-pnr</code> was added to section 3.1.3.1.</p>
+</li>
+<li><p>A description of Service Contract Entity Categories was added to section 3.1.3.4.</p>
+</li>
+<li><p>In section 3.1.1, the EU commission <code>AuthnContextClassRef</code> URI:s for non-notified schemes were changed.</p>
+</li>
+<li><p>Section 3.1.9.2, &quot;eIDAS Connector Aliases&quot;, defining the URI format for representing country affiliation of eIDAS connector services, was added.</p>
+</li>
+<li><p>The link for the &quot;Tillitsramverk för Svensk e-legitimation&quot; specification was updated.</p>
+</li>
+<li><p>Added the attribute SignMessageDigest (1.2.752.201.3.14) to section 3.2.</p>
+</li>
+<li><p>The Sign Message Authentication Context URIs defined in section 3.1.1.1 are deprecated.</p>
+</li>
+<li><p>The XML Schema namespace identifier <code>http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info</code> was added. This XML Schema defines an XML extension for the Authentication Context Extension to provide extended authentication information.</p>
+</li>
+<li><p>Associating the OID registry with Sweden Connect.</p>
+</li>
+<li><p>Aligned registered module OID:s with RFC 7773.</p>
+</li>
+<li><p>Adding a new extension OID for Signature Validation Tokens in timestamp extensions.</p>
+</li>
+<li><p>Added attribute set and service entity categories for HSA-ID.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
+<ul class="list">
+<li><p>Added identifier for the service property entity category <code>http://id.elegnamnden.se/sprop/1.0/scal2</code></p>
+</li>
+<li><p>Added XML Schema name space identifier <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code>. This XML Schema defines XML elements related to the Signature Activation Protocol.</p>
+</li>
+<li><p>Added Semantics Identifiers section 3.1.8 to define a name registration authority URI necessary to express a provisional ID attribute in an X.509 certificate according to ETSI EN 319 412-1.</p>
+</li>
+<li><p>Added Authentication Context URI:s <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code> and <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low-sigm</code> to section 3.1.1.</p>
+</li>
+<li><p>Added section 3.1.9, &quot;eIDAS Identifiers&quot;, that describes the format for eIDAS Proxy Service Alias URI identifiers.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
+<ul class="list">
+<li><p>  Attributes and URI:s for the eIDAS Framework was added.</p>
+</li>
+<li><p>The SAML status code identifier
+  <code>http://id.elegnamnden.se/status/1.0/cancel</code> was added to be used in SAML
+  Response messages to indicate a cancelled operation.</p>
+</li>
+<li><p>Added the SAML status code identifiers <code>http://id.elegnamnden.se/status/1.0/fraud</code> and <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> were added to be used in SAML Response messages to alert fraudulent requests.</p>
+</li>
+<li><p>Added attribute definitions for “Birth name”, “User certificate”,
+  “User signature”, &quot;Authentication Server Signature&quot; and “Signature activation data”. See chapter 3.2.</p>
+</li>
+<li><p> Added the Service Type Entity Categories <code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code> and <code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code> to section 3.1.3.3.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
+<ul class="list">
+<li><p>Object identifiers for the attributes “Transaction identifier”,
+  “Authentication Context Parameters”, “Provisional ID” and
+  “Provisional ID quality indicator” were defined and added to section
+  3.2.</p>
+</li>
+<li><p>Chapter 3.1.7, “XML Schema namespaces”, was removed since the “Level
+  of Assurance context class declarations” are deprecated and thus,
+  the namespace <code>http://id.elegnamnden.se/ns/1.0/loa-context-params</code>
+  is no longer part of the Swedish eID Framework.</p>
+</li>
+<li><p>Authentication Context URIs for use by signature services during
+  authentication was added to section 3.1.1.</p>
+</li>
+<li><p>Service entity categories for future use within the eIDAS Framework
+  were added to section 3.1.3.1.</p>
+</li>
+<li><p>The status code identifier
+  <code>http://id.elegnamnden.se/sig-status/1.0/sigmessage-error</code> was added
+  to section 3.1.6 and the signature response status code <code>http://id.elegnamnden.se/sig-status/1.0/user-cancel</code> was added to section 3.1.7.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li>URI identifiers for Attribute Profiles as specified in [AttrProf]
+  were introduced.</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li><p>In chapter 3.1.3.1, “Service Entity Categories”, service entity
+  categories for Level of Assurance 2 and 4 were introduced.</p>
+</li>
+<li><p>  Chapter 3.1.7, “XML Schema namespaces”, was added.</p>
+</li>
+<li><p>  Typos were fixed.</p>
+</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html b/docs/december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
new file mode 100644
index 0000000..f19b1fa
--- /dev/null
+++ b/docs/december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
@@ -0,0 +1,1222 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Attribute Specification for the Swedish eID Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-landscape.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</h1>
+<h3 id="version-18---2024-12-04">Version 1.8 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-310</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#terminology">Terminology</a></p>
+<p> 1.2. <a href="#requirement-keywords">Requirement keywords</a></p>
+<p> 1.3. <a href="#name-space-references">Name space references</a></p>
+<p> 1.4. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#attribute-sets"><strong>Attribute Sets</strong></a></p>
+<p> 2.1. <a href="#pseudonym-identity">Pseudonym Identity</a></p>
+<p> 2.2. <a href="#natural-personal-identity-without-civic-registration-number">Natural Personal Identity without Civic Registration Number</a></p>
+<p> 2.3. <a href="#natural-personal-identity-with-civic-registration-number">Natural Personal Identity with Civic Registration Number</a></p>
+<p> 2.4. <a href="#organizational-identity-for-natural-persons">Organizational Identity for Natural Persons</a></p>
+<p> 2.5. <a href="#eidas-natural-person-attribute-set">eIDAS Natural Person Attribute Set</a></p>
+<p> 2.6. <a href="#natural-person-identity-with-hsa-id">Natural Person Identity with HSA-ID</a></p>
+</li>
+<li><p><a href="#attribute-definitions"><strong>Attribute Definitions</strong></a></p>
+<p> 3.1. <a href="#attributes">Attributes</a></p>
+<p> 3.1.1. <a href="#attribute-string-values">Attribute String Values</a></p>
+<p> 3.1.2. <a href="#multi-valued-attributes">Multi-valued Attributes</a></p>
+<p> 3.1.3. <a href="#scoped-attributes">Scoped Attributes</a></p>
+<p> 3.2. <a href="#saml-attribute-format">SAML Attribute Format</a></p>
+<p> 3.2.1. <a href="#the-authcontextparams-attribute">The authContextParams Attribute</a></p>
+<p> 3.2.2. <a href="#the-usercertificate-and-usersignature-attributes">The userCertificate, userSignature and authServerSignature Attributes</a></p>
+<p> 3.2.3. <a href="#the-sad-attribute">The sad Attribute</a></p>
+<p> 3.2.4. <a href="#the-signmessagedigest-attribute">The signMessageDigest Attribute</a></p>
+<p> 3.2.5. <a href="#the-orgaffiliation-attribute">The orgAffiliation Attribute</a></p>
+<p> 3.2.6. <a href="#the-previouspersonalidentitynumber-attribute">The previousPersonalIdentityNumber Attribute</a></p>
+<p> 3.3. <a href="#attributes-for-the-eidas-framework">Attributes for the eIDAS Framework</a></p>
+<p> 3.3.1. <a href="#the-prid-and-pridpersistence-attributes">The prid and pridPersistence Attributes</a></p>
+<p> 3.3.2. <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes</a></p>
+<p> 3.3.3. <a href="#conversion-of-eidas-attributes">Conversion of eIDAS Attributes</a></p>
+<p> 3.3.3.1. <a href="#conversion-of-eidas-currentaddress">Conversion of eIDAS CurrentAddress</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This document specifies an attribute profile for the Swedish eID
+Framework. The attribute profile defines attributes for use within the
+Swedish eID Framework, and a number of defined attribute sets that may
+be referenced by other documents as means to specify specific attribute
+release requirements.</p>
+<p><a name="terminology"></a></p>
+<h3 id="11-terminology">1.1. Terminology</h3>
+<table>
+<thead>
+<tr>
+<th align="left">Term</th>
+<th align="left">Defined meaning</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>Attribute</strong></td>
+<td align="left">A property, quality or characteristic of a person, thing or object. This term is used in general in this specification to denote an attribute of a person/entity that is represented by a set of attributes in a SAML attribute statement (see SAML Attribute). This term is also used in this specification when describing XML syntax to denote an attribute (property) of an XML element.</td>
+</tr>
+<tr>
+<td align="left"><strong>SAML attribute</strong></td>
+<td align="left">An attribute of an entity represented by a set of attributes in a SAML attribute statement (<code>&lt;saml:AttributeStatement&gt;</code> element).</td>
+</tr>
+<tr>
+<td align="left"><strong>IDP</strong></td>
+<td align="left">Identity Provider</td>
+</tr>
+<tr>
+<td align="left"><strong>SP</strong></td>
+<td align="left">Service Provider</td>
+</tr>
+<tr>
+<td align="left"><strong>Natural person</strong></td>
+<td align="left">Natural person is legal term for a real human being, as opposed to a legal person, which may be a private (i.e., business entity) or public (i.e., government) organization.</td>
+</tr>
+<tr>
+<td align="left"><strong>Civic registration number</strong></td>
+<td align="left">A unique identifier assigned to each natural person in a national population register. Within the context of this specification this is a Swedish ”personnummer” or ”samordningsnummer” according to [SKV704] and [SKV707].</td>
+</tr>
+</tbody></table>
+<p><a name="requirement-keywords"></a></p>
+<h3 id="12-requirement-keywords">1.2. Requirement keywords</h3>
+<p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
+interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations. When these words are
+not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="name-space-references"></a></p>
+<h3 id="13-name-space-references">1.3. Name space references</h3>
+<p>Conventional XML namespace prefixes are used throughout the listings in
+this specification to stand for their respective namespaces as follows,
+whether a namespace declaration is present in the example:</p>
+<table>
+<thead>
+<tr>
+<th align="left">Prefix</th>
+<th align="left">XML Namespace</th>
+<th align="left">Comments</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>saml</code></td>
+<td align="left"><code>urn:oasis:names:tc:SAML:2.0:assertion</code></td>
+<td align="left">The SAML V2.0 assertion namespace, defined in the schema [<a href="#saml-xsd">SAML-XSD</a>].</td>
+</tr>
+<tr>
+<td align="left"><code>xs</code></td>
+<td align="left"><code>http://www.w3.org/2001/XMLSchema</code></td>
+<td align="left">The XML Schema namespace, representing definitions of data types in [<a href="#xml-schema">XML-Schema</a>].</td>
+</tr>
+</tbody></table>
+<p><a name="structure"></a></p>
+<h3 id="14-structure">1.4. Structure</h3>
+<p>This specification uses the following typographical conventions in text: <code>&lt;ns:Element&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>, <code>OtherCode</code>.</p>
+<p><a name="attribute-sets"></a></p>
+<h2 id="2-attribute-sets">2. Attribute Sets</h2>
+<p>This section defines attribute sets based on attribute definitions in
+<a href="#attribute-definitions">section 3</a>. Common to all attribute sets is that each attribute MUST NOT
+be present more than once. An attribute that has more than one value
+MUST be provided as one attribute with multiple <code>&lt;AttributeValue&gt;</code>
+sub-elements in accordance with <a href="#attributes">section 3.1</a>.</p>
+<p>An identifier, named “Attribute Set Identifier”, and a URI, are defined
+for each attribute set as means for other documents to reference
+specific attribute sets.</p>
+<p>Each attribute set defines a number of mandatory attributes that MUST be
+released by an Attribute Provider<sup>*</sup> that provides attributes according
+to the given attribute set, and optionally recommended attributes that
+SHOULD be released as part of the attribute set if they are available to
+the provider.</p>
+<p><strong>Note</strong>: An Attribute Provider may also release other attributes, not
+specified by the defined attribute sets it supports. See further section
+6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish
+eID Framework” ([<a href="#sc-saml-profile">SC.SAML.Profile</a>]).</p>
+<p>In order to comply with a defined attribute set, the following attribute
+requirements apply:</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Definition</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong></td>
+<td align="left">Attributes that MUST be present.</td>
+</tr>
+<tr>
+<td align="left"><strong>RECOMMENDED</strong></td>
+<td align="left">Attributes that SHOULD be present, if available.</td>
+</tr>
+</tbody></table>
+<p>A defined attribute set does not define any rules for attributes other
+than those listed as required or recommended.</p>
+<blockquote>
+<p>[*]: An Attribute Provider is an entity that releases attributes to a requesting entity. In all practical cases within the Swedish eID Framework this entity is an Identity Provider or an Attribute Authority. Within the eIDAS Framework, the Swedish eIDAS node acts as the Attribute Provider for the Service Providers.</p>
+</blockquote>
+<p><a name="pseudonym-identity"></a></p>
+<h3 id="21-pseudonym-identity">2.1. Pseudonym Identity</h3>
+<p>Attribute set identifier: <strong>ELN-AP-Pseudonym-01</strong></p>
+<p>URI: <code>http://id.elegnamnden.se/ap/1.0/pseudonym-01</code></p>
+<p>This attribute set specifies the condition where there are no mandatory or recommended attributes.</p>
+<p><strong>Typical use</strong>: In a pseudonym attribute release policy that just provides a persistent <code>NameID</code> identifier in the assertion but no attributes.</p>
+<p><a name="natural-personal-identity-without-civic-registration-number"></a></p>
+<h3 id="22-natural-personal-identity-without-civic-registration-number">2.2. Natural Personal Identity without Civic Registration Number</h3>
+<p>Attribute set identifier: <strong>ELN-AP-NaturalPerson-01</strong></p>
+<p>URI: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
+<p>The “Personal Identity without Civic Registration Number” attribute set provides basic natural person information without revealing the civic registration number of the subject.</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong></td>
+<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name)</td>
+</tr>
+</tbody></table>
+<p><strong>Typical use</strong>: In an attribute release policy that provides basic username information together with a persistent <code>NameID</code> identifier in the assertion.</p>
+<p><a name="natural-personal-identity-with-civic-registration-number"></a></p>
+<h3 id="23-natural-personal-identity-with-civic-registration-number">2.3. Natural Personal Identity with Civic Registration Number</h3>
+<p>Attribute set identifier: <strong>ELN-AP-Pnr-01</strong></p>
+<p>URI: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
+<p>The “Personal Identity with Civic Registration Number” attribute set provides basic personal identity information including a Swedish civic registration number of the subject.</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong></td>
+<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name) <br /> <code>personalIdentityNumber</code> (National civic registration number)</td>
+</tr>
+<tr>
+<td align="left"><strong>RECOMMENDED</strong></td>
+<td align="left"><code>dateOfBirth</code> (Date of birth)</td>
+</tr>
+</tbody></table>
+<p><strong>Typical use</strong>: In an attribute release policy that provides basic username information together with the person’s Swedish civic registration number.</p>
+<p><a name="organizational-identity-for-natural-persons"></a></p>
+<h3 id="24-organizational-identity-for-natural-persons">2.4. Organizational Identity for Natural Persons</h3>
+<p>Attribute set identifier: <strong>ELN-AP-OrgPerson-01</strong></p>
+<p>URI: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
+<p>The “Organizational Identity for Natural Persons” attribute set provides basic organizational identity information about a person. The organizational identity does not necessarily imply that the subject has any particular relationship with or standing within the organization, but rather that this identity has been issued/provided by that organization for any particular reason (employee, customer, consultant, etc.).</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong></td>
+<td align="left"><code>displayName</code> (Display name)<sup>*</sup> <br /> <code>orgAffiliation</code> (Personal identifier and organizational identifier code)<sup>**</sup> <br /> <code>o</code> (Organization name)</td>
+</tr>
+<tr>
+<td align="left"><strong>RECOMMENDED</strong></td>
+<td align="left"><code>organizationIdentifier</code> (Organizational identifier code)<sup>***</sup></td>
+</tr>
+</tbody></table>
+<p><strong>Typical use</strong>: In an attribute release policy that provides basic organizational identity information about a natural person.</p>
+<p>The &quot;Organizational Identity for Natural Persons&quot; attribute set defines a minimum set of attributes needed to provide organizational identity information about a person. Should an attribute consumer require additional attributes, such as surname and given name, the personal identity number or an organizational unit name, this can be achieved by either requesting other attribute sets or by explicitly requesting individual attributes. See further section 6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish eID Framework” ([<a href="#sc-saml-profile">SC.SAML.Profile</a>]).</p>
+<blockquote>
+<p>[*]: The <code>displayName</code> attribute MAY contain personal information such as the given name or surname, but it MAY also be used as an anonymized display name, for example, &quot;Administrator 123&quot;. This is decided by the issuing organization.</p>
+</blockquote>
+<blockquote>
+<p>[**]: See section <a href="#the-orgaffiliation-attribute">3.2.5</a>.</p>
+</blockquote>
+<blockquote>
+<p>[***]: The organizational identifier can always be derived from the mandatory <code>orgAffiliation</code> attribute, but an attribute provider supporting the &quot;Organizational Identity for Natural Persons&quot; attribute set SHOULD also release the <code>organizationIdentifier</code> attribute individually. </p>
+</blockquote>
+<p><a name="eidas-natural-person-attribute-set"></a></p>
+<h3 id="25-eidas-natural-person-attribute-set">2.5. eIDAS Natural Person Attribute Set</h3>
+<p>Attribute set identifier: <strong>ELN-AP-eIDAS-NatPer-01</strong></p>
+<p>URI: <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></p>
+<p>The “eIDAS Natural Person Attribute Set” provides personal identity
+information for a subject that has been authenticated via the eIDAS
+Framework.</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong><sup>*</sup></td>
+<td align="left"><code>prid</code> (Provisional ID) <br /> <code>pridPersistence</code> (Provisional ID persistence indicator) <br /> <code>eidasPersonIdentifier</code> (Mapping of the eIDAS PersonIdentifier attribute) <br /> <code>dateOfBirth</code> (Date of birth) <br /> <code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>c</code> (Country code for the eIDAS country that authenticated the subject) <br /><code>transactionIdentifier</code> (ID of assertion issued by the member state node)<sup>**</sup></td>
+</tr>
+<tr>
+<td align="left"><strong>REQUIRED</strong><br />(if available)<sup>***</sup></td>
+<td align="left"><code>birthName</code> (Birth name) <br /> <code>placeOfBirth</code> (Place of birth) <br /> <code>eidasNaturalPersonAddress</code> (Address for natural person) <br /> <code>gender</code> (Gender)</td>
+</tr>
+<tr>
+<td align="left"><strong>RECOMMENDED</strong></td>
+<td align="left"><code>mappedPersonalIdentityNumber</code> (Mapped national civic registration number) <br /> <code>personalIdentityNumberBinding</code> (National civic registration number Binding(s))</td>
+</tr>
+</tbody></table>
+<p><strong>Typical use</strong>: In an attribute release policy implemented by an eIDAS
+connector that provides a complete set of attributes to a requesting
+Service Provider.</p>
+<p><strong>Note</strong>: The <code>mappedPersonalIdentityNumber</code> and <code>personalIdentityNumberBinding</code>
+attributes will be part of the attribute release if the attribute
+provider has access to enough information to provide a binding
+between eIDAS attributes and a Swedish identity number (see <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section
+3.3.2</a>).</p>
+<p>The eIDAS attribute set consists of “added” and “converted” attributes.</p>
+<p><strong>Added attributes</strong>: Attributes that are not provided by the member
+state node, but added by the
+Swedish eIDAS node in order to provide additional information about
+the authenticated subject obtained from relevant domestic attribute
+sources. The <code>prid</code>, <code>pridPersistence</code> and <code>personalIdentityNumber</code>
+attributes are “added attributes”.</p>
+<p><strong>Converted attributes</strong>: Attributes that are the result of a
+conversion process where an eIDAS attribute is converted into a
+single-value string type attribute defined within the Swedish eID
+Framework (see section <a href="#conversion-of-eidas-attributes">3.3.3</a>, “<a href="#conversion-of-eidas-attributes">Conversion of eIDAS Attributes</a>”). The
+reason for the conversion is to facilitate processing for attribute
+consumers. The eIDAS attributes are not simple string types, and this
+affects interoperability in a negative way since standard SAML
+software need to be modified to support these attributes. Therefore,
+the Swedish eID node will convert eIDAS attributes to their
+corresponding string value-typed attributes. The
+<code>eidasPersonIdentifier</code>, <code>sn</code>, <code>givenName</code> and <code>dateOfBirth</code> attributes are
+examples of “converted attributes”.</p>
+<blockquote>
+<p>[*]: Attributes “added” by the Swedish eID node and converted attributes for the mandatory attributes of the eIDAS minimum data set for natural persons.</p>
+</blockquote>
+<blockquote>
+<p>[**]: The transaction identifier attribute will contain the unique ID of the assertion that was issued by the member state node. This information together with the entityID of the member state node (found in the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element of an assertion) give a reference to the original assertion and authentication process.</p>
+</blockquote>
+<blockquote>
+<p>[***]: Converted attributes for the optional attributes of the eIDAS minimum data set for natural persons.</p>
+</blockquote>
+<p><a name="natural-person-identity-with-hsa-id"></a></p>
+<h3 id="26-natural-person-identity-with-hsa-id">2.6. Natural Person Identity with HSA-ID</h3>
+<p>Attribute set identifier: <strong>DIGG-AP-HSAid-01</strong></p>
+<p>URI: <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code></p>
+<p>The “Natural Person Identity with HSA-ID” attribute set provides basic personal identity information including an HSA-ID of the subject (see [<a href="#sambiattr">SambiAttr</a>]).</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute requirement</th>
+<th align="left">Attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>REQUIRED</strong></td>
+<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name) <br /> <code>employeeHsaId</code> (HSA-ID)</td>
+</tr>
+<tr>
+<td align="left"><strong>RECOMMENDED</strong></td>
+<td align="left"><code>dateOfBirth</code> (Date of birth)</td>
+</tr>
+</tbody></table>
+<p><strong>Typical use</strong>: In an attribute release policy that provides basic username information together with the person’s HSA-ID.</p>
+<p><a name="attribute-definitions"></a></p>
+<h2 id="3-attribute-definitions">3. Attribute Definitions</h2>
+<p><a name="attributes"></a></p>
+<h3 id="31-attributes">3.1. Attributes</h3>
+<p>The following attributes are defined for use within the attribute profile for the Swedish eID Framework:</p>
+<table>
+<thead>
+<tr>
+<th align="left">Attribute abbreviation</th>
+<th align="left">SAML attribute name</th>
+<th align="left">Description</th>
+<th align="left">Use within this specification</th>
+<th align="center">Multi-valued</th>
+<th align="left">Scoped</th>
+<th align="left">Example</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">sn</td>
+<td align="left">urn:oid:2.5.4.4</td>
+<td align="left">Surname</td>
+<td align="left">Registered surname.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Lindeman</td>
+</tr>
+<tr>
+<td align="left">givenName</td>
+<td align="left">urn:oid:2.5.4.42</td>
+<td align="left">Given Name</td>
+<td align="left">Registered given name.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Valfrid</td>
+</tr>
+<tr>
+<td align="left">displayName</td>
+<td align="left">urn:oid:2.16.840.1.<br/>113730.3.1.241</td>
+<td align="left">Display Name</td>
+<td align="left">A name in any preferred presentation format.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Valfrid Lindeman</td>
+</tr>
+<tr>
+<td align="left">gender</td>
+<td align="left">urn:oid:1.3.6.1.5.5.7.9.3</td>
+<td align="left">Gender</td>
+<td align="left">A one letter representation (“M”/”F”/”U” or “m”/“f”/”u”) representing the subject’s gender, where “M” represents male, “F” represents female and “U” is used for unspecified, or unknown, gender.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">M</td>
+</tr>
+<tr>
+<td align="left">personalIdentity-<br/>Number</td>
+<td align="left">urn:oid:1.2.752.29.4.13</td>
+<td align="left">National civic registration number/code</td>
+<td align="left">Swedish ”personnummer” or ”samordningsnummer” according to <a href="#skv704">SKV 704</a> and <a href="#skv707">SKV 707</a>. 12 digits without hyphen.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">195006262546</td>
+</tr>
+<tr>
+<td align="left">previousPersonal-<br/>IdentityNumber</td>
+<td align="left">urn:oid:1.2.752.201.3.15</td>
+<td align="left">A user&#39;s previous national civic registration number, see <a href="#the-previouspersonalidentitynumber-attribute">section 3.2.6</a> below.</td>
+<td align="left">See <code>personalIdentityNumber</code> above.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">197010632391</td>
+</tr>
+<tr>
+<td align="left">dateOfBirth</td>
+<td align="left">urn:oid:1.3.6.1.5.5.7.9.1</td>
+<td align="left">Date of birth</td>
+<td align="left">Date of birth expressed using the format YYYY-MM-DD.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">1950-06-26</td>
+</tr>
+<tr>
+<td align="left">birthName</td>
+<td align="left">urn:oid:1.2.752.201.3.8</td>
+<td align="left">Name at the time of birth</td>
+<td align="left">Full name of a person at birth.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Valfrid Danielsson</td>
+</tr>
+<tr>
+<td align="left">street</td>
+<td align="left">urn:oid:2.5.4.9</td>
+<td align="left">Street address</td>
+<td align="left">Street address.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Mosebacke torg 3</td>
+</tr>
+<tr>
+<td align="left">postOfficeBox</td>
+<td align="left">urn:oid:2.5.4.18</td>
+<td align="left">Post box</td>
+<td align="left">Post box.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Box 1122</td>
+</tr>
+<tr>
+<td align="left">postalCode</td>
+<td align="left">urn:oid:2.5.4.17</td>
+<td align="left">Postal code</td>
+<td align="left">Postal code.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">11826</td>
+</tr>
+<tr>
+<td align="left">l</td>
+<td align="left">urn:oid:2.5.4.7</td>
+<td align="left">Locality</td>
+<td align="left">Locality.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Stockholm</td>
+</tr>
+<tr>
+<td align="left">c</td>
+<td align="left">urn:oid:2.5.4.6</td>
+<td align="left">Country</td>
+<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">SE</td>
+</tr>
+<tr>
+<td align="left">placeOfBirth</td>
+<td align="left">urn:oid:1.3.6.1.5.5.7.9.2</td>
+<td align="left">Place of birth</td>
+<td align="left">A string representing the place of birth.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Stockholm</td>
+</tr>
+<tr>
+<td align="left">countryOfCitizenship</td>
+<td align="left">urn:oid:1.3.6.1.5.5.7.9.4</td>
+<td align="left">Country of citizenship</td>
+<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code representing a country of citizenship.</td>
+<td align="center">Yes</td>
+<td align="left">No</td>
+<td align="left">SE</td>
+</tr>
+<tr>
+<td align="left">countryOfResidence</td>
+<td align="left">urn:oid:1.3.6.1.5.5.7.9.5</td>
+<td align="left">Country of Residence</td>
+<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code representing the country of residence.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">SE</td>
+</tr>
+<tr>
+<td align="left">telephoneNumber</td>
+<td align="left">urn:oid:2.5.4.20</td>
+<td align="left">Telephone number</td>
+<td align="left">Telephone number.</td>
+<td align="center">Yes</td>
+<td align="left">No</td>
+<td align="left">+46890510</td>
+</tr>
+<tr>
+<td align="left">mobile</td>
+<td align="left">urn:oid:0.9.2342.<br/>19200300.100.1.41</td>
+<td align="left">Mobile number</td>
+<td align="left">Mobile number.</td>
+<td align="center">Yes</td>
+<td align="left">No</td>
+<td align="left">+46703419886</td>
+</tr>
+<tr>
+<td align="left">mail</td>
+<td align="left">urn:oid:0.9.2342.<br/>19200300.100.1.3</td>
+<td align="left">E-mail address</td>
+<td align="left">E-mail address.</td>
+<td align="center">Yes</td>
+<td align="left">Yes/No<sup>*</sup></td>
+<td align="left"><a href="mailto:&#118;&#102;&#108;&#64;&#109;&#x6f;&#x73;&#x65;&#98;&#97;&#99;&#x6b;&#101;&#x6d;&#111;&#110;&#97;&#114;&#107;&#x69;&#x2e;&#115;&#101;">&#118;&#102;&#108;&#64;&#109;&#x6f;&#x73;&#x65;&#98;&#97;&#99;&#x6b;&#101;&#x6d;&#111;&#110;&#97;&#114;&#107;&#x69;&#x2e;&#115;&#101;</a></td>
+</tr>
+<tr>
+<td align="left">o</td>
+<td align="left">urn:oid:2.5.4.10</td>
+<td align="left">Organization name</td>
+<td align="left">Registered organization name.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">Skatteverket</td>
+</tr>
+<tr>
+<td align="left">ou</td>
+<td align="left">urn:oid:2.5.4.11</td>
+<td align="left">Organizational unit name</td>
+<td align="left">Organizational unit name.</td>
+<td align="center">Yes</td>
+<td align="left">No</td>
+<td align="left">IT-Avdelningen</td>
+</tr>
+<tr>
+<td align="left">organizationIdentifier</td>
+<td align="left">urn:oid:2.5.4.97</td>
+<td align="left">Organizational identifier code</td>
+<td align="left">Swedish “organisationsnummer” according to <a href="#skv709">SKV 709</a>. 10 digits without hyphen.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">5562265719</td>
+</tr>
+<tr>
+<td align="left">orgAffiliation</td>
+<td align="left">urn:oid:1.2.752.201.3.1</td>
+<td align="left">&lt;uid&gt;@&lt;orgnr&gt;</td>
+<td align="left"><em>Personal ID</em> @ Swedish ”organisationsnummer” according to <a href="#skv709">SKV 709</a>. 10 digits without hyphen.</td>
+<td align="center">Yes</td>
+<td align="left">Yes</td>
+<td align="left">vlindman@5562265719<br />See <a href="#the-orgaffiliation-attribute">section 3.2.5</a> below.</td>
+</tr>
+<tr>
+<td align="left">transactionIdentifier</td>
+<td align="left">urn:oid:1.2.752.201.3.2</td>
+<td align="left">Transaction identifier</td>
+<td align="left">Transaction identifier for an event, e.g. an authentication process.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left"><em>9878HJ6687 (arbitrary string)</em></td>
+</tr>
+<tr>
+<td align="left">authContextParams</td>
+<td align="left">urn:oid:1.2.752.201.3.3</td>
+<td align="left">Authentication Context Parameters.</td>
+<td align="left">Key-value pairs from an authentication process. Defined by issuing entity.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-authcontextparams-attribute">section 3.2.1</a> below.</td>
+</tr>
+<tr>
+<td align="left">userCertificate</td>
+<td align="left">urn:oid:1.2.752.201.3.10</td>
+<td align="left">User certificate</td>
+<td align="left">Base64-encoding of a user certificate.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
+</tr>
+<tr>
+<td align="left">userSignature</td>
+<td align="left">urn:oid:1.2.752.201.3.11</td>
+<td align="left">User signature</td>
+<td align="left">Base64-encoding of a signature object applied by the user.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
+</tr>
+<tr>
+<td align="left">authServerSignature</td>
+<td align="left">urn:oid:1.2.752.201.3.13</td>
+<td align="left">Authentication server signature</td>
+<td align="left">Base64-encoding of a authentication server signature.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
+</tr>
+<tr>
+<td align="left">sad</td>
+<td align="left">urn:oid:1.2.752.201.3.12</td>
+<td align="left">Signature activation data</td>
+<td align="left">Signature activation data required by signature services.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-sad-attribute">section 3.2.3</a> below.</td>
+</tr>
+<tr>
+<td align="left">signMessageDigest</td>
+<td align="left">urn:oid:1.2.752.201.3.14</td>
+<td align="left">Sign message digest</td>
+<td align="left">Included in assertions as a proof that a user sign message was displayed.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#the-signmessagedigest-attribute">section 3.2.4</a> below.</td>
+</tr>
+<tr>
+<td align="left">prid</td>
+<td align="left">urn:oid:1.2.752.201.3.4</td>
+<td align="left">Provisional identifier</td>
+<td align="left">Unique identifier for an authentication performed against the eIDAS Framework. See <a href="#the-prid-and-pridpersistence-attributes">section 3.3.1</a> below.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">NO:5068907693</td>
+</tr>
+<tr>
+<td align="left">pridPersistence</td>
+<td align="left">urn:oid:1.2.752.201.3.5</td>
+<td align="left">Provisional identifier persistence indicator</td>
+<td align="left">Indicator for the expected persistence of the prid attribute. See <a href="#the-prid-and-pridpersistence-attributes">section 3.3.1</a> below.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">A</td>
+</tr>
+<tr>
+<td align="left">personalIdentity-<br/>NumberBinding</td>
+<td align="left">urn:oid:1.2.752.201.3.6</td>
+<td align="left">National civic registration number/code binding URI</td>
+<td align="left">URI(s) identifying the binding process(es) performed of the <code>mappedPersonalIdentityNumber</code> attribute added by eIDAS connector. See <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section 3.3.2</a> below.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/populationregister</code></td>
+</tr>
+<tr>
+<td align="left">mappedPersonal-<br />IdentityNumber</td>
+<td align="left">urn:oid:1.2.752.201.3.16</td>
+<td align="left">Mapped national civic registration number</td>
+<td align="left">A &quot;mapped&quot; personalIdentityNumber, see <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section 3.3.2</a>.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">195006262546</td>
+</tr>
+<tr>
+<td align="left">eidasPersonIdentifier</td>
+<td align="left">urn:oid:1.2.752.201.3.7</td>
+<td align="left">eIDAS uniqueness identifier for natural persons</td>
+<td align="left">Maps the eIDAS PersonIdentifier attribute to a string attribute within the scope of the Swedish eID Framework attribute set.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">ES/AT/02635542Y (Spanish eID number for an Austrian SP)</td>
+</tr>
+<tr>
+<td align="left">eidasNatural-<br/>PersonAddress</td>
+<td align="left">urn:oid:1.2.752.201.3.9</td>
+<td align="left">eIDAS Natural Person Address</td>
+<td align="left">Attribute for converting the eIDAS CurrentAddress attribute into an attribute having a string type value.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See <a href="#conversion-of-eidas-currentaddress">section 3.3.3.1</a> below.</td>
+</tr>
+<tr>
+<td align="left">employeeHsaId</td>
+<td align="left">urn:oid:1.2.752.29.6.2.1</td>
+<td align="left">HSA-ID</td>
+<td align="left">Person identifier used by Swedish health care organizations.</td>
+<td align="center">No</td>
+<td align="left">No</td>
+<td align="left">See [<a href="#sambiattr">SambiAttr</a>].</td>
+</tr>
+</tbody></table>
+<blockquote>
+<p>[*]: The <code>mail</code> attribute should be regarded as a scoped attribute (see <a href="#scoped-attributes">3.1.3</a> below) if the attribute release policy in use has stated it as scoped. Such a policy can for example be that the attribute is part of an attribute set (see <a href="#attribute-sets">section 2</a>) that documents the attribute as scoped. In all other cases the attribute is regarded as non-scoped.</p>
+</blockquote>
+<p><a name="attribute-string-values"></a></p>
+<h4 id="311-attribute-string-values">3.1.1. Attribute String Values</h4>
+<p>All attributes, unless stated otherwise in this table, hold string values using the UTF-8 character set using the <code>xs:string</code> data type. Certain attributes such as <code>mail</code>, <code>personalIdentityNumber</code>, <code>organizationIdentifier</code>, <code>telephoneNumber</code> and <code>mobile</code> use a restricted character set according to its defined usage within this specification.</p>
+<p>All attributes use the “caseIgnoreMatch” matching rule as defined by X.520 [<a href="#x520">X.520</a>]. That is, case-insensitive comparison where insignificant spaces are ignored.</p>
+<p><a name="multi-valued-attributes"></a></p>
+<h4 id="312-multi-valued-attributes">3.1.2. Multi-valued Attributes</h4>
+<p>Attributes with a “No” value in the column &quot;Multi-valued&quot; MUST NOT have more than one <code>&lt;AttributeValue&gt;</code> sub-element. Attributes with a “Yes” value in the column &quot;Multi-valued&quot; MAY have one or more <code>&lt;AttributeValue&gt;</code> sub-elements.</p>
+<p><a name="scoped-attributes"></a></p>
+<h4 id="313-scoped-attributes">3.1.3. Scoped Attributes</h4>
+<p>Attributes with a &quot;Yes&quot; value in the column &quot;Scoped&quot; are scoped attributes. A scoped attribute expresses values in a string-valued attribute of the form <code>value@scope</code>, where <code>scope</code> takes the form of a domain name or something similar such as an organizational identifier.</p>
+<p>An Identity Provider wishing to release scoped attributes must register the scopes with the federation operator. After the federation operator has authorized the Identity Provider for the given scopes, they are declared in the Identity Provider&#39;s metadata entry. See section 2.1.3.1 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] for details.    </p>
+<p>A Service Provider consuming a scoped attribute SHOULD assert that the issuing Identity Provider is authorized to issue attributes with the given scope by checking the Identity Provider&#39;s metadata entry as described in section 6.2.1 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+<p><strong>Note:</strong> The <code>value</code> part of a scoped attribute MAY contain a <code>@</code>-character, for example when the value part is an email address, or a User Principal Name (UPN). Therefore, consumers of scoped attributes MUST use the last <code>@</code>-character as a delimiting character when splitting a scoped attribute into its <code>value</code> and <code>scope</code> parts.</p>
+<p><a name="saml-attribute-format"></a></p>
+<h3 id="32-saml-attribute-format">3.2. SAML Attribute Format</h3>
+<p>The <code>&lt;saml:Attribute&gt;</code> element representing an attribute in <a href="#attributes">3.1</a> SHALL comply with the following requirements:</p>
+<ul class="list">
+<li><p>The <code>NameFormat</code> attribute SHALL have the value <code>urn:oasis:names:tc:SAML:2.0:attrname-format:uri</code>.</p>
+</li>
+<li><p>The <code>Name</code> attribute SHALL hold a URI according to the table in <a href="#attributes">section 3.1</a>.</p>
+</li>
+<li><p>The <code>FriendlyName</code> attribute is OPTIONAL.</p>
+</li>
+<li><p>All <code>&lt;AttributeValue&gt;</code> sub-elements SHALL, unless stated otherwise in the table in <a href="#attributes">section 3.1</a>, have an <code>xsi:type</code> attribute specifying the type <code>&quot;xs:string&quot;</code>.</p>
+</li>
+</ul>
+<p>The following is an example of the surname attribute. Its name is “urn:oid:2.5.4.4”, its friendly name is “sn” and the value is represented using a string type.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">xmlns:xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
+                           <span class="hljs-attr">FriendlyName</span>=<span class="hljs-string">&quot;sn&quot;</span>
+                           <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:2.5.4.4&quot;</span>
+                           <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>Eriksson<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span></code></pre><p><a name="the-authcontextparams-attribute"></a></p>
+<h4 id="321-the-authcontextparams-attribute">3.2.1. The authContextParams Attribute</h4>
+<p>The attribute <code>authContextParams</code> holds key-value pairs. Its purpose is to store key-value pairs representing data from an authentication process. The data stored in this attribute is generally not defined by the Swedish eID Framework, but instead by the issuing party (i.e., the Identity Provider).</p>
+<p>The <code>authContextParams</code> attribute is a non-empty single-value attribute where the attribute value contains the key-value pairs separated by semicolons. The key and value of each pair is separated by a ‘=’ character and both the key and value MUST be URL-encoded.</p>
+<p>Below follows an example of how the authContextParams attribute is populated with two key-value pairs, &quot;foo&quot; that stores the value &quot;ÅÄÖ&quot;, and &quot;bar&quot; that stores the value &quot;123&quot;.</p>
+<pre class="hljs"><code>...
+&lt;saml<span class="hljs-number">2</span>:Attribute xmlns:xsi<span class="hljs-operator">=</span><span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>    
+                           FriendlyName<span class="hljs-operator">=</span><span class="hljs-string">&quot;authContextParams&quot;</span>
+                           Name<span class="hljs-operator">=</span><span class="hljs-string">&quot;urn:oid:1.2.752.201.3.3&quot;</span>
+                           NameFormat<span class="hljs-operator">=</span><span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;
+  &lt;saml<span class="hljs-number">2</span>:AttributeValue xsi:<span class="hljs-keyword">type</span><span class="hljs-operator">=</span><span class="hljs-string">&quot;xs:string&quot;</span>&gt;foo<span class="hljs-operator">=</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%85</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%84</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%96</span><span class="hljs-comment">;bar=123&lt;/saml2:AttributeValue&gt;</span>
+&lt;/saml<span class="hljs-number">2</span>:Attribute&gt;
+...</code></pre><p><a name="the-usercertificate-and-usersignature-attributes"></a></p>
+<h4 id="322-the-usercertificate-usersignature-and-authserversignature-attributes">3.2.2. The userCertificate, userSignature and authServerSignature Attributes</h4>
+<p>Identity Providers that implement a PKI-based authentication method may
+make use of the <code>userCertificate</code> and <code>userSignature</code> attributes.</p>
+<p>The <code>userCertificate</code> attribute holds, as its value, a base64-encoding of
+the X.509 certificate presented by the subject during authentication.</p>
+<p>The <code>userSignature</code> attribute contains a base64-encoding of a signature
+object that was created by the subject during the authentication<sup>*</sup>
+process.</p>
+<p>The <code>authServerSignature</code> may be included in assertions in cases where there are requirements to include a digitally signed proof from the authentication server at which the end user authenticated. This is mainly useful in cases where the SAML Identity Provider delegates end user authentication to a subordinate authentication server.</p>
+<blockquote>
+<p>[*]: Note that an authentication process, may be “authentication for signature” as specified in section 7 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+</blockquote>
+<p><a name="the-sad-attribute"></a></p>
+<h4 id="323-the-sad-attribute">3.2.3. The sad Attribute</h4>
+<p>The <code>sad</code> attribute holds Signature Activation Data that is required by a
+signature service in order to service a signature request in accordance
+with CEN EN 419 241-2. The <code>sad</code> attribute holds a single string
+attribute value. The format of the string value is defined in the &quot;Signature Activation Protocol 
+for Federated Signing&quot; specification [<a href="#sc-sap">SC.SAP</a>].</p>
+<p><a name="the-signmessagedigest-attribute"></a></p>
+<h4 id="324-the-signmessagedigest-attribute">3.2.4. The signMessageDigest Attribute</h4>
+<p>The <code>signMessageDigest</code> attribute is included in an assertion as a proof that an Identity Provider displayed
+a sign message for the user and that the user actively confirmed acceptance of this sign message. This sign 
+message is the <code>SignMessage</code> extension that may be included in an authentication request by Signature Service 
+SP:s. See section 7 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] for details.</p>
+<p>The attribute value format for the <code>signMessageDigest</code> attribute is <code>digest-algorithm-identifier;sign-message-digest</code>, where
+<code>digest-algorithm-identifier</code> is the XML Security algorithm URI identifier of the selected digest algorithm and
+<code>sign-message-digest</code> is <code>base64(digest(msg))</code>. The <code>msg</code> is the UTF-8 encoded bytes of the sign message that was displayed. It equals the <code>csig:Message</code> element value of the <code>csig:SignMessage</code> ([<a href="#dssext">SC.DSS.Ext</a>]). Thus, if the <code>csig:Message</code> element is encrypted into a <code>csig:EncryptedMessage</code>, the element value after decryption should be used.</p>
+<p>Entities compliant with this specification MUST use <code>http://www.w3.org/2001/04/xmlenc#sha256</code> as the digest algorithm, 
+unless the recipient of the <code>signMessageDigest</code> attribute has declared another digest algorithm as preferred in its
+metadata entry (see section 2.1.1.3 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]). In those cases this algorithm MAY be used.</p>
+<p><strong>Example:</strong></p>
+<p>Suppose that the unencrypted message is &quot;I hereby confirm that I want to join example.com as a customer&quot;. This is
+represented as:</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;csig:Message&gt;</span>
+  <span class="hljs-attribute">SSBoZXJlYnkgY29uZmlybSB0aGF0IEkgd2FudCB0byBqb2luIGV4YW1wbGUuY29tIGFzIGEgY3VzdG9tZXI</span>=
+<span class="hljs-section">&lt;/csig:Message&gt;</span></code></pre><p>The input to the digesting operation is the value bytes of the <code>csig:Message</code> element which is UTF-8 encoded bytes
+of the actual sign message<sup>*</sup>.</p>
+<p>The <code>signMessageDigest</code> attribute for the above example will then be:</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute FriendlyName=<span class="hljs-string">&quot;signMessageDigest&quot;</span> Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.14&quot;</span>
+  NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xsd:string&quot;</span>&gt;</span>
+    <span class="hljs-attribute">http</span>://www.w<span class="hljs-number">3</span>.org/<span class="hljs-number">2001</span>/<span class="hljs-number">04</span>/xmlenc#sha<span class="hljs-number">256</span>;<span class="hljs-number">0</span>yKaSVsYeh+PX<span class="hljs-number">2</span>Q<span class="hljs-number">6</span>diqO<span class="hljs-number">2</span>w<span class="hljs-number">89</span>+a<span class="hljs-number">3</span>Dm<span class="hljs-number">303</span>tp<span class="hljs-number">3</span>AVjgxwj<span class="hljs-number">0</span>=
+  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
+<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p><a name="the-orgaffiliation-attribute"></a></p>
+<h4 id="325-the-orgaffiliation-attribute">3.2.5. The orgAffiliation Attribute</h4>
+<p>The <code>orgAffiliation</code> attribute is intended to be used as a primary identity attribute for personal organizational identities. It consists of a personal identifier <strong>and</strong> an organizational identifier code (<code>organizationIdentifier</code>). </p>
+<p>This specification does not impose any specific requirements concerning the personal identifier part of the attribute other than that it MUST be unique for the given organization.</p>
+<p><strong>Note</strong>: In the general case, an attribute consumer MUST NOT assume a particular format or meaning of the personal identifier part since different organizations may use different formats. An attribute consumer should also be aware that a personal identifier separated from its organizational identifier code can not be regarded as unique. </p>
+<p><strong>Note</strong>: The <code>orgAffiliation</code> is a <a href="#scoped-attributes">scoped attribute</a> meaning that producing and consuming such an attribute MUST follow the rules given in sections 2.1.3.1 and 6.2.1 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+<p><a name="the-previouspersonalidentitynumber-attribute"></a></p>
+<h4 id="326-the-previouspersonalidentitynumber-attribute">3.2.6. The previousPersonalIdentityNumber Attribute</h4>
+<p>The <code>personalIdentityNumber</code> attribute can contain a Swedish personal identity number (personnummer), [<a href="#skv704">SKV704</a>], or a Swedish coordination number (samordningsnummer), [<a href="#skv707">SKV707</a>]. All individuals born in Sweden or moving to Sweden with the intention 
+of staying one year or longer is assigned a personal identity number and registered in the
+population register. A coordination number may be assigned to a person that is not registered, 
+but has the need to communicate with various government authorities, healthcare institutions,
+higher education and banks.</p>
+<p>In some cases a person may hold a coordination number during a period before he or she is
+assigned a personal identity number. A typical use case is a person that seeks asylum and
+later is given a residence permit. In this case the person first may hold a coordination number
+and if a residence permit is given a personal identity number will be assigned.</p>
+<p>For a service provider this may lead to problems since the primary identifier for a person
+has changed. A login with the newly assigned identifier will not match the user account
+previously used by this individual.</p>
+<p>This profile defines the <code>previousPersonalIdentityNumber</code> attribute to enable matching a
+previously held identity number to a newly assigned identity number. The <code>previousPersonalIdentityNumber</code> attribute is typically released together with the &quot;new&quot; 
+<code>personalIdentityNumber</code> attribute in order to facilitate account matching at a service provider.</p>
+<p>This attribute is not part of any attribute sets defined in the profile. Attribute consumers
+wishing to receive the attribute should declare the these requirement in their metadata entries
+(using a <code>&lt;md:RequestedAttribute&gt;</code> element).</p>
+<p><a name="attributes-for-the-eidas-framework"></a></p>
+<h3 id="33-attributes-for-the-eidas-framework">3.3. Attributes for the eIDAS Framework</h3>
+<p><a name="the-prid-and-pridpersistence-attributes"></a></p>
+<h4 id="331-the-prid-and-pridpersistence-attributes">3.3.1. The prid and pridPersistence Attributes</h4>
+<p>Assertions (with attribute statements) issued from a member state eIDAS
+node contain a set of attributes identifying the authenticated subject.
+Attributes obtained from other conformant eIDAS nodes will provide an
+eIDAS unique identifier, but it can not be ruled out that the Swedish
+eIDAS node may be adopted to accept authentication from non eIDAS
+compliant nodes, such as when accepting authentication from countries
+outside of EU such as the USA.</p>
+<p>Therefore, the Swedish eIDAS connector enriches attribute statements
+with the provisional ID (<code>prid</code>) and provisional ID persistence
+(<code>pridPersistence</code>) attributes.</p>
+<p>The <code>prid</code> attribute is designed to provide one common unique attribute of
+the user in a common format regardless of the composition of the
+original attributes received from the authenticating source. The <code>prid</code>
+attribute value is not stored in any registry, but derived from the
+received attributes at each authentication instant according to defined
+algorithms specified in [<a href="#sc-constructed">SC.Constructed</a>]. The algorithm ensures that
+each <code>prid</code> is unique for each authenticated entity, but does not ensure
+persistence. If the attributes received for an entity changes over time,
+the <code>prid</code> attribute may also change dependent on the defined <code>prid</code>
+generation algorithm for that attribute source.</p>
+<p>The <code>pridPersistence</code> attribute provides an indication of the expected
+persistence over time for a present <code>prid</code> attribute value. The value of
+this attribute is determined from the selected <code>prid</code> generation algorithm
+in combination with the attribute source. For example, a <code>prid</code> derived
+from a Norwegian eIDAS unique identifier has longer persistence
+expectancy than a <code>prid</code> derived from the same attribute from the UK or
+Germany. This attribute helps Service Providers to apply different UI
+and service functions for users with different persistence expectancy.
+This may assist users with low persistence expectancy to regain control
+of their user account, should their <code>prid</code> change in the future.</p>
+<p>The specification “eIDAS Constructed Attributes Specification for the
+Swedish eID Framework”, [<a href="#sc-constructed">SC.Constructed</a>], declares the details for
+how the <code>prid</code> and <code>pridPersistence</code> attributes are generated and how they
+should be processed.</p>
+<p><a name="the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute"></a></p>
+<h4 id="332-the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attributes">3.3.2. The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes</h4>
+<p>When an authentication for a natural person is performed against the
+eIDAS Framework, the Swedish eIDAS connector will query the Identity Binding Service
+for a binding between the attributes found in the assertion received from the foreign
+eIDAS-node and a Swedish personal identity number.  If such a mapping exists, and the user consents to it being used, the assertion will be extended with a <code>mappedPersonalIdentityNumber</code> attribute holding the &quot;mapped&quot; Swedish civic registration number (&quot;personnummer&quot; or &quot;samordningsnummer&quot;).</p>
+<p>This mapping, or binding, can be performed using a number of different processes,
+each identified by a URI. Therefore, if the eIDAS connector extends an assertion with a 
+<code>mappedPersonalIdentityNumber</code> attribute, it MUST also include the <code>personalIdentityNumberBinding</code> attribute. This attribute contains a semicolon separated list of URI:s that identify the binding process applied to obtain the binding. See [<a href="#id-binding">ID-Binding</a>] for the possible values.</p>
+<p>If these bindings are acceptable for a Service Provider processing an assertion (containing the <code>mappedPersonalIdentityNumber</code> attribute), the Service Provider MAY treat the contents of the <code>mappedPersonalIdentityNumber</code> attribute as it would have received the <code>personalIdentityNumber</code> attribute, otherwise the Service Provider SHOULD NOT use the identity found in the <code>mappedPersonalIdentityNumber</code> attribute to log in the user.</p>
+<blockquote>
+<p><strong>Note</strong>: The reason that an ordinary <code>personalIdentityNumber</code> attribute is not
+used to represent a mapped civic registration number is that it is essential that
+the consuming entity always verifies that the binding process under which the 
+mapping was performed is acceptable, before proceeding with the authentication 
+process.</p>
+</blockquote>
+<p><a name="conversion-of-eidas-attributes"></a></p>
+<h4 id="333-conversion-of-eidas-attributes">3.3.3. Conversion of eIDAS Attributes</h4>
+<p>The attributes specified within eIDAS ([<a href="#eidas-attr">eIDAS.Attributes</a>]) does not use
+simple string type values, instead each attribute is represented using
+its own dedicated XML data type. This affects interoperability in a
+negative way since most standard SAML software need to be modified to
+support these attributes. Therefore, the Swedish eID Framework defines
+mappings for all eIDAS attributes to attributes having definitions that
+are more suitable for processing using standard SAML software.</p>
+<p>Below follows a listing of how the attributes for the eIDAS minimum data
+set for Natural Persons are converted into attributes supported by the
+Swedish eID Framework.</p>
+<table>
+<thead>
+<tr>
+<th align="left">eIDAS attribute</th>
+<th align="left">Swedish eID attribute</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">PersonIdentifier <br /> <code>http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier</code></td>
+<td align="left">eidasPersonIdentifier <br /> urn:oid:1.2.752.201.3.7</td>
+</tr>
+<tr>
+<td align="left">FamilyName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentFamilyName</code></td>
+<td align="left">sn <br /> urn:oid:2.5.4.4</td>
+</tr>
+<tr>
+<td align="left">FirstName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentGivenName</code></td>
+<td align="left">givenName <br /> urn:oid:2.5.4.42</td>
+</tr>
+<tr>
+<td align="left">DateOfBirth <br /> <code>http://eidas.europa.eu/attributes/naturalperson/DateOfBirth</code></td>
+<td align="left">dateOfBirth <br /> urn:oid:1.3.6.1.5.5.7.9.1</td>
+</tr>
+<tr>
+<td align="left">BirthName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/BirthName</code></td>
+<td align="left">birthName <br /> urn:oid:1.2.752.201.3.8</td>
+</tr>
+<tr>
+<td align="left">PlaceOfBirth <br /> <code>http://eidas.europa.eu/attributes/naturalperson/PlaceOfBirth</code></td>
+<td align="left">placeOfBirth <br /> urn:oid:1.3.6.1.5.5.7.9.2</td>
+</tr>
+<tr>
+<td align="left">CurrentAddress <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentAddress</code></td>
+<td align="left">eidasNaturalPersonAddress <br /> urn:oid:1.2.752.201.3.9 <br /> See <a href="#conversion-of-eidas-currentaddress">section 3.3.3.1</a> below.</td>
+</tr>
+<tr>
+<td align="left">Gender <br /> <code>http://eidas.europa.eu/attributes/naturalperson/Gender</code></td>
+<td align="left">gender <br /> urn:oid:1.3.6.1.5.5.7.9.3</td>
+</tr>
+<tr>
+<td align="left">Nationality<br /><code>http://eidas.europa.eu/attributes/naturalperson/Nationality</code></td>
+<td align="left">countryOfCitizenship<br />urn:oid:1.3.6.1.5.5.7.9.4</td>
+</tr>
+<tr>
+<td align="left">CountryOfBirth<br /><code>http://eidas.europa.eu/attributes/naturalperson/CountryOfBirth</code></td>
+<td align="left">Will be added as the last element of placeOfBirth (see above)</td>
+</tr>
+<tr>
+<td align="left">TownOfBirth<br /><code>http://eidas.europa.eu/attributes/naturalperson/TownOfBirth</code></td>
+<td align="left">Ignored if the eIDAS attribute PlaceOfBirth is assigned. Otherwise placed as first element of placeOfBirth.</td>
+</tr>
+<tr>
+<td align="left">CountryOfResidence<br /><code>http://eidas.europa.eu/attributes/naturalperson/CountryOfResidence</code></td>
+<td align="left">countryOfResidence<br />urn:oid:1.3.6.1.5.5.7.9.5</td>
+</tr>
+<tr>
+<td align="left">PhoneNumber<br /><code>http://eidas.europa.eu/attributes/naturalperson/PhoneNumber</code></td>
+<td align="left">telephoneNumber<br />urn:oid:2.5.4.20</td>
+</tr>
+<tr>
+<td align="left">EmailAddress<br /><code>http://eidas.europa.eu/attributes/naturalperson/EmailAddress</code></td>
+<td align="left">mail<br />urn:oid:0.9.2342.19200300.100.1.3</td>
+</tr>
+</tbody></table>
+<p><strong>Note</strong>: When converting an eIDAS attribute that makes use of
+“transliteration” (as described in section 2.4 of [<a href="#eidas-attr">eIDAS.Attributes</a>])
+attribute values having the <code>LatinScript</code> attribute set to <code>false</code> will not
+be part of the resulting attribute.</p>
+<p><a name="conversion-of-eidas-currentaddress"></a></p>
+<h5 id="3331-conversion-of-eidas-currentaddress">3.3.3.1. Conversion of eIDAS CurrentAddress</h5>
+<p>The eIDAS attribute <code>CurrentAddress</code> is defined in section 2.2.9 of
+[<a href="#eidas-attr">eIDAS.Attributes</a>]. Its value is a Base64-encoding of an XML-structure of
+the type CurrentAddressStructuredType.</p>
+<pre class="hljs"><code>&lt;xsd:complexType <span class="hljs-type">name</span>=&quot;CurrentAddressStructuredType&quot;&gt;
+  &lt;xsd:annotation&gt;
+    &lt;xsd:documentation&gt;
+      <span class="hljs-keyword">Current</span> address <span class="hljs-keyword">of</span> the <span class="hljs-keyword">natural</span> person.
+    &lt;/xsd:documentation&gt;
+  &lt;/xsd:annotation&gt;
+  &lt;xsd:<span class="hljs-keyword">sequence</span>&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PoBox&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;LocatorDesignator&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;LocatorName&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;CvaddressArea&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;Thoroughfare&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PostName&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;AdminunitFirstline&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;AdminunitSecondline&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PostCode&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
+  &lt;/xsd:<span class="hljs-keyword">sequence</span>&gt;
+&lt;/xsd:complexType&gt;</code></pre><p>An example of an instance of a CurrentAddress attribute would look as
+follows:</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute xmlns:xsi=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
+                           FriendlyName=<span class="hljs-string">&quot;CurrentAddress&quot;</span>
+                           Name=<span class="hljs-string">&quot;http://eidas.europa.eu/attributes/naturalperson/CurrentAddress&quot;</span>
+                           NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;eidas:CurrentAddressType&quot;</span>&gt;</span>
+    <span class="hljs-attribute">PGVpZGFzOkxvY2F0b3JEZXNpZ25hdG9yPjIyPC9laWRhczpMb2NhdG9yRGVzaWduYX</span>
+    <span class="hljs-attribute">Rvcj48ZWlkYXM6VGhvcm91Z2hmYXJlPkFyY2FjaWEgQXZlbnVlPC9laWRhczpUaG9y</span>
+    <span class="hljs-attribute">b3VnaGZhcmU</span>+DQo<span class="hljs-number">8</span>ZWlkYXM<span class="hljs-number">6</span>UG<span class="hljs-number">9</span>zdE<span class="hljs-number">5</span>hbWU+TG<span class="hljs-number">9</span>uZG<span class="hljs-number">9</span>uPC<span class="hljs-number">9</span>laWRhczpQb<span class="hljs-number">3</span>N<span class="hljs-number">0</span>TmFtZT
+    <span class="hljs-attribute">4NCjxlaWRhczpQb3N0Q29kZT5TVzFBIDFBQTwvZWlkYXM6UG9zdENvZGU</span>+
+  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
+<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p>The value is the Base64-encoding of the following XML-snippet:</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">eidas:LocatorDesignator</span>&gt;</span>22<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:LocatorDesignator</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">eidas:Thoroughfare</span>&gt;</span>Arcacia Avenue<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:Thoroughfare</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">eidas:PostName</span>&gt;</span>London<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:PostName</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">eidas:PostCode</span>&gt;</span>SW1A 1AA<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:Postcode</span>&gt;</span></code></pre><p>This is not easily processed by standard SAML-software, and requires
+several steps including XML-decoding of an incomplete XML-snippet.
+Therefore, the Swedish eID Framework defines the
+<code>eidasNaturalPersonAddress</code> attribute to be used when the Swedish eIDAS
+node converts the eIDAS <code>CurrentAddress</code> attribute.</p>
+<p>The <code>eidasNaturalPersonAddress</code> attribute is defined to be a non-empty
+single-value attribute containing key-value pairs separated by
+semicolons. The keys are element names from the
+<code>CurrentAddressStructuredType</code> type and the value-parts are their
+corresponding values. The key and value of each pair is separated by a
+‘=’ character and both the key and value MUST be URL-encoded.</p>
+<p>The eIDAS-attribute <code>CurrentAddress</code> above will thus be converted to the
+following attribute:</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">xmlns:xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
+                           <span class="hljs-attr">FriendlyName</span>=<span class="hljs-string">&quot;eidasNaturalPersonAddress&quot;</span>
+                           <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.9&quot;</span>
+                           <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+    LocatorDesignator=22;Thoroughfare=Arcacia%20Avenue;PostName=London;PostCode=SW1A%201AA
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span></code></pre><p><a name="references"></a></p>
+<h2 id="4-references">4. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="saml2subjattr"></a>
+<strong>[SAML2SubjAttr]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf">OASIS Standard, SAML V2.0 Subject Identifier Attributes Profile Version 1.0, January 2019</a>.</p>
+</blockquote>
+<p><a name="skv704"></a>
+<strong>[SKV704]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv704-8.pdf">Skatteverket, SKV 704 Utgåva 8,
+Personnummer</a>.</p>
+</blockquote>
+<p><a name="skv707"></a>
+<strong>[SKV707]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf">Skatteverket, SKV 707, Utgåva 2,
+Samordningsnummer</a>.</p>
+</blockquote>
+<p><a name="skv709"></a>
+<strong>[SKV709]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf">Skatteverket, SKV 709, Utgåva 8, Organisationsnummer</a>.</p>
+</blockquote>
+<p><a name="id-binding"></a>
+<strong>[ID-Binding]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS Identities to Records in the Swedish Population Register</a></p>
+</blockquote>
+<p><a name="x520"></a>
+<strong>[X.520]</strong></p>
+<blockquote>
+<p><a href="https://www.itu.int/rec/T-REC-X.520-201610-I/en">ITU-T X.520 - Open Systems Interconnection – The Directory: Selected attribute types</a>.</p>
+</blockquote>
+<p><a name="saml-xsd"></a>
+<strong>[SAML-XSD]</strong></p>
+<blockquote>
+<p>S. Cantor et al., SAML assertions schema. OASIS SSTC, March 2005.
+Document ID saml-schema-assertion-2.0. See
+<a href="http://www.oasisopen.org/committees/security/">http://www.oasisopen.org/committees/security/</a>.</p>
+</blockquote>
+<p><a name="xml-schema"></a>
+<strong>[XML-Schema]</strong></p>
+<blockquote>
+<p>XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28
+October 2004. See <a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>.</p>
+</blockquote>
+<p><a name="iso3166"></a>
+<strong>[ISO3166]</strong></p>
+<blockquote>
+<p>Codes for the representation of names of countries and their
+subdivisions Part 1: Country codes, ISO standard, ISO 3166-1.</p>
+</blockquote>
+<p><a name="sambiattr"></a>
+<strong>[SambiAttr]</strong></p>
+<blockquote>
+<p><a href="https://wiki.federationer.internetstiftelsen.se/pages/viewpage.action?pageId=46465316">Sambi Attributspecifikation</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-constructed"></a>
+<strong>[SC.Constructed]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="eidas-attr"></a>
+<strong>[eIDAS.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.4_final.pdf">eIDAS SAML Attribute Profile, version 1.4, 31 October 2023</a>.</p>
+</blockquote>
+<p><a name="sc-sap"></a>
+<strong>[SC.SAP]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="dssext"></a>
+<strong>[SC.DSS.Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="5-changes-between-versions">5. Changes between versions</h2>
+<p><strong>Changes between version 1.7 and version 1.8:</strong></p>
+<ul class="list">
+<li><p>In section 3.1.3, &quot;Scoped Attributes&quot;, a note about <code>@</code>-characters in scoped values was added.</p>
+</li>
+<li><p>Updated link to Sambi attribute specification.</p>
+</li>
+<li><p>Section 3.3.2, &quot;The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes&quot;, was updated.</p>
+</li>
+<li><p>Section 3.3.3, &quot;Conversion of eIDAS Attributes&quot;, was extended to contain mappings for the optional eIDAS attributes: Nationality, CountryOfBirth, TownOfBirth, CountryOfResidence, PhoneNumber and EmailAddress.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
+<ul class="list">
+<li><p>Section 2.4, &quot;Organizational Identity for Natural Persons&quot;, was updated to define a minimum set of attributes for providing personal orgazational identity information.</p>
+</li>
+<li><p>Section 3.2.5, &quot;The orgAffiliation Attribute&quot;, was introduced.</p>
+</li>
+<li><p>The concept of &quot;scoped attributes&quot; was introduced, see section 3.1.3.</p>
+</li>
+<li><p>The <code>previousPersonalIdentityNumber</code> attribute was added, see section 3.2.6.</p>
+</li>
+<li><p>The <code>mappedPersonalIdentityNumber</code> attribute was added (see section 3.3.2), and the
+attribute set &quot;eIDAS Natural Person Attribute Set&quot; (section 2.5) was changed so that
+a <code>mappedPersonalIdentityNumber</code> attribute is delivered instead of a 
+<code>personalIdentityNumber</code> attribute if the eIDAS identity can be mapped to a Swedish 
+identity number.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
+<ul class="list">
+<li><p>References were updated to point at the latest versions of the &quot;Tillitsramverk för Svensk e-legitimation&quot; and &quot;eIDAS SAML Attribute Profile&quot; specifications.</p>
+</li>
+<li><p>Section 2.5, &quot;eIDAS Natural Person Attribute Set&quot;, was updated so that the <code>c</code> (country) attribute is a required attribute for this attribute set.</p>
+</li>
+<li><p>The attribute <code>signMessageDigest</code> was introduced (see section 3.2.4).</p>
+</li>
+<li><p>The HSA-ID attribute was specified.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
+<ul class="list">
+<li>Section 3.2.3 was updated with a reference to the SAP specification as source for defining the content of the <code>sad</code> attribute.</li>
+<li>Fix of invalid links for SKV704 and SKV707.</li>
+<li>Section 2.3, &quot;Natural Personal Identity with Civic Registration Number (Personnummer)&quot;, was updated so that the <code>dateOfBirth</code>-attribute is listed as a recommended attribute for the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</li>
+</ul>
+<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
+<ul class="list">
+<li><p>Attributes for mapping eIDAS-attributes have been defined (section
+  3.1 and 3.3).</p>
+</li>
+<li><p>The eIDAS Natural Person Attribute Set has been defined (section
+  2.5).</p>
+</li>
+<li><p>The definition of the <code>gender</code>-attribute was extended to also include
+  “U” (for unspecified or unknown).</p>
+</li>
+<li><p>For interoperability and implementations reasons, the definition of
+  the <code>dateOfBirth</code>-attribute has been changed so that it is represented
+  as an <code>xs:string</code> type on the format YYYY-MM-DD, instead of the
+  <code>xs:date</code> type.</p>
+</li>
+<li><p>  Attributes <code>userCertificate</code>, <code>userSignature</code>, <code>authServerSignature</code> and <code>sad</code> were added.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
+<ul class="list">
+<li><p>This specification no longer uses the term “attribute profile” for
+  named collections of attributes for different scenarios, instead the
+  term “attribute set” is used.</p>
+</li>
+<li><p>Definitions of attribute sets (profiles) have been changed to be
+  more flexible and to focus only on which attributes that should be
+  included in an attribute release. Attribute set requirements now
+  include “required” and “recommended” attributes instead of
+  “required”, “allowed”, “if requested” and “prohibited”. See
+  section 2.</p>
+</li>
+<li><p>The contents of the previous chapter 2, “NameID”, were moved to the
+  “Deployment Profile for the Swedish eID Framework” document.</p>
+</li>
+<li><p>The attribute <code>displayName</code> is now specified as “required” for the
+  “Natural Personal Identity with Civic Registration Number
+  (Personnummer)” (ELN-AP-NaturalPerson-01) attribute set (profile).
+  See section 2.3.</p>
+</li>
+<li><p>The attributes <code>o</code> (Organization) and <code>displayName</code> are now specified as
+  “required” for the “Organizational Identity for Natural Persons”
+  (ELN-AP-OrgPerson-01) attribute set (profile). See section 2.4.</p>
+</li>
+<li><p>The attributes <code>givenName</code> and <code>sn</code> (surname) are now specified as
+  “required” for the “Natural Personal Identity without Civic
+  Registration Number” (ELN-AP-NaturalPerson-01) attribute set
+  (profile). See section 2.2.</p>
+</li>
+<li><p>The attributes <code>transactionIdentifier</code> and <code>authContextParams</code> were
+  introduced (see sections 3.1 and 3.2.1).</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li>Attribute Profiles are now also represented with valid URIs as well
+  as their textual identifiers.</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li>In chapter 3.4, “Organizational Identity for Natural Persons”, some
+  attributes were listed as both prohibited and allowed. This has been
+  fixed.</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html b/docs/december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
new file mode 100644
index 0000000..9dcc9ff
--- /dev/null
+++ b/docs/december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
@@ -0,0 +1,689 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Entity Categories for the Swedish eID Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</h1>
+<h3 id="version-19---2024-12-04">Version 1.9 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-311</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.2. <a href="#references-to-saml-20-standards-and-profiles">References to SAML 2.0 Standards and Profiles</a></p>
+<p> 1.3. <a href="#consuming-and-providing-services">Consuming and Providing Services</a></p>
+<p> 1.4. <a href="#use-in-discovery">Use in Discovery</a></p>
+<p> 1.5. <a href="#representation-of-entity-categories-in-metadata">Representation of Entity Categories in Metadata</a></p>
+</li>
+<li><p><a href="#definitions-for-service-entity-categories"><strong>Definitions for Service Entity Categories</strong></a></p>
+<p> 2.1. <a href="#natural-personal-identity-with-civic-registration-number">Natural Personal Identity with Civic Registration Number</a></p>
+<p> 2.1.1. <a href="#loa2-pnr">loa2-pnr</a></p>
+<p> 2.1.2. <a href="#loa3-pnr">loa3-pnr</a></p>
+<p> 2.1.3. <a href="#loa4-pnr">loa4-pnr</a></p>
+<p> 2.1.4. <a href="#eidas-pnr-delivery">eidas-pnr-delivery</a></p>
+<p> 2.2. <a href="#eidas-natural-person-attribute-set">eIDAS Natural Person Attribute Set</a></p>
+<p> 2.2.1. <a href="#eidas-naturalperson">eidas-naturalperson</a></p>
+<p> 2.3. <a href="#organizational-identity-for-natural-persons">Organizational Identity for Natural Persons</a></p>
+<p> 2.3.1. <a href="#loa2-orgid">loa2-orgid</a></p>
+<p> 2.3.2. <a href="#loa3-orgid">loa3-orgid</a></p>
+<p> 2.3.3. <a href="#loa4-orgid">loa4-orgid</a></p>
+<p> 2.4. <a href="#natural-personal-identity-without-civic-registration-number">Natural Personal Identity without Civic Registration Number</a></p>
+<p> 2.4.1. <a href="#loa2-name">loa2-name</a></p>
+<p> 2.4.2. <a href="#loa3-name">loa3-name</a></p>
+<p> 2.4.3. <a href="#loa4-name">loa4-name</a></p>
+</li>
+<li><p><a href="#definitions-for-service-property-categories"><strong>Definitions for Service Property Categories</strong></a></p>
+<p> 3.1. <a href="#mobile-auth">mobile-auth</a></p>
+<p> 3.2. <a href="#scal2">scal2</a></p>
+</li>
+<li><p><a href="#definitions-for-service-type-entity-categories"><strong>Definitions for Service Type Entity Categories</strong></a></p>
+<p> 4.1. <a href="#sigservice">sigservice</a></p>
+<p> 4.2. <a href="#public-sector-sp">public-sector-sp</a></p>
+<p> 4.3. <a href="#private-sector-sp">private-sector-sp</a></p>
+</li>
+<li><p><a href="#service-contract-categories"><strong>Service Contract Categories</strong></a></p>
+</li>
+<li><p><a href="#general-entity-categories"><strong>General Entity Categories</strong></a></p>
+<p> 6.1. <a href="#secure-authenticator-binding">secure-authenticator-binding</a></p>
+<p> 6.2. <a href="#accepts-coordination-number">accepts-coordination-number</a></p>
+<p> 6.3. <a href="#supports-user-message">supports-user-message</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This specification contains the Entity Category definitions that are
+defined for the Swedish eID Framework and that should be supported by
+Service Providers and Identity Providers that are part of the
+federation.</p>
+<p>The use of Entity Categories for the Swedish eID Framework is restricted
+to SAML metadata where Entity Categories are placed as SAML attributes
+under the <code>&lt;mdattr:EntityAttributes&gt;</code> element
+([<a href="#saml2metaattr">SAML2MetaAttr</a>]) for an <code>&lt;md:Extensions&gt;</code> element
+([<a href="#saml2meta">SAML2Meta</a>]).</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:EntityDescriptor</span> <span class="hljs-attr">entityID</span>=<span class="hljs-string">&quot;https://eid.example.com/entityid&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;</span>
+    ... 
+      <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
+                      <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xmlns:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+          http://id.elegnamnden.se/ec/1.0/loa3-pnr
+        <span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>    
+      <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>    
+    <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>    
+  <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>    
+  ...</code></pre><p><em>The Entity Category identifier
+<strong><code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></strong> specified as an entity
+attribute for a Service Provider or Identity Provider.</em></p>
+<p>Five types of Entity Categories are used within the federation:</p>
+<ul class="list">
+<li><p>Service entity category – Identifiers for entity categories
+  representing sets of requirements.</p>
+</li>
+<li><p>Service property categories – Identifiers for defined service
+  properties.</p>
+</li>
+<li><p>  Service type categories – Identifiers for defined service types.</p>
+</li>
+<li><p>  Service contract categories - Identifiers for labelling entities based on contracts or business agreements.</p>
+</li>
+<li><p>   General categories - Identifiers defined within the Swedish eID Framework for miscellaneous purposes.</p>
+</li>
+</ul>
+<p><a name="requirements-notation"></a></p>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The keywords &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
+&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
+document are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
+on deployment practices intended to foster both interoperability and
+guarantees of security and confidentiality needed to satisfy the
+requirements of many organizations that engage in the use of federated
+identity. Deviating may limit a deployment&#39;s ability to technically
+interoperate without additional negotiation, and should be undertaken
+with caution.</p>
+<p><a name="references-to-saml-20-standards-and-profiles"></a></p>
+<h3 id="12-references-to-saml-20-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
+<p>When referring to elements from the SAML 2.0 core specification
+[<a href="#saml2core">SAML2Core</a>], the following syntax is used:</p>
+<ul class="list">
+<li><p><code>&lt;saml2p:Element&gt;</code> – for elements from the SAML 2.0 Protocol
+  namespace.</p>
+</li>
+<li><p><code>&lt;saml2:Element&gt;</code> – for elements from the SAML 2.0 Assertion
+  namespace.</p>
+</li>
+</ul>
+<p>When referring to elements from the SAML 2.0 metadata specifications,
+the following syntax is used:</p>
+<ul class="list">
+<li><p>  <code>&lt;md:Element&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
+</li>
+<li><p>  <code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
+</li>
+</ul>
+<p><a name="consuming-and-providing-services"></a></p>
+<h3 id="13-consuming-and-providing-services">1.3. Consuming and Providing Services</h3>
+<p>Entity categories are mainly used for service matching. This allows
+matching of a consuming service with an appropriate providing service. A
+consuming service in this context is an assertion or attribute consuming
+service of a service provider (Service described through an
+<code>&lt;md:SPSSODescriptor&gt;</code> element in the federation metadata). A
+providing service in this context is a service, represented in the
+federation metadata, providing assertions to a service provider.</p>
+<p>The entity categories defined in this document have different meaning
+depending on whether they are declared by a consuming or a providing
+service. Further, different types of entity category identifiers defined
+in this document have different matching rules to determine whether
+particular providing service matches the requirements of a consuming
+service.</p>
+<p>These differences are outlined in the following table:</p>
+<table>
+<thead>
+<tr>
+<th align="left">EC type</th>
+<th align="left">Consuming service</th>
+<th align="left">Providing service</th>
+<th align="left">Service matching rule</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><strong>Service Entity Category</strong></td>
+<td align="left">Each declared category represents a set of requirements for the service.</td>
+<td align="left">Represents the ability to deliver assertions in accordance with each declared category.</td>
+<td align="left">At least one of the service entity categories declared by the consuming service MUST be declared by the providing service.</td>
+</tr>
+<tr>
+<td align="left"><strong>Service Property</strong></td>
+<td align="left">Represents a property of this service.</td>
+<td align="left">Represents the ability to deliver assertions to a consuming service that has the declared property.</td>
+<td align="left">All properties declared by the consuming service MUST be declared by the providing service.</td>
+</tr>
+<tr>
+<td align="left"><strong>Service Type</strong></td>
+<td align="left">Declares the type of service provided by this consuming service.</td>
+<td align="left">Not applicable.</td>
+<td align="left">No matching rule.</td>
+</tr>
+<tr>
+<td align="left"><strong>Service Contract</strong></td>
+<td align="left">Each declared category represents a contract, or business agreement, that the service is affiliated to.</td>
+<td align="left">Represents the contracts, or business agreements, under which the providing service may deliver services.</td>
+<td align="left">At least one of the service contract identifiers declared by a providing service must be declared by the consuming service. A providing service that does not declare any service contract identifiers match all consuming services regarding service contract matching.</td>
+</tr>
+<tr>
+<td align="left"><strong>General</strong></td>
+<td align="left">An entity category type for miscellaneous purposes.</td>
+<td align="left">An entity category type for miscellaneous purposes.</td>
+<td align="left">No general matching rule.<br />However, the meaning of a general entity category may be such that it affects matching.</td>
+</tr>
+</tbody></table>
+<p><a name="use-in-discovery"></a></p>
+<h3 id="14-use-in-discovery">1.4. Use in Discovery</h3>
+<p>Entity Categories in metadata are declarations of requirements and
+capabilities of Service Providers and Identity Providers. A discovery
+process may make use of these declared Entity Categories when performing
+filtering, i.e., when deciding which Identity Providers to present for
+the end-user. The filtering algorithm is very simple:</p>
+<p>For a Service Provider requesting discovery its metadata entry is
+scanned for Entity Category identifiers of the type Service Entity
+Category, Service Contract and Service Property. The algorithm then iterates over all
+Identity Providers found in the metadata repository for the
+federation. The discovery process SHOULD display Identity Providers as
+a plausible choice, if and only if, the following conditions apply;</p>
+<ul class="list">
+<li><p>the Identity Provider declares at least of the Service Entity Category 
+  identifiers declared by the Service Provider,</p>
+</li>
+<li><p>if the Identity Provider declares at least one Service Contract identifier,
+  the Service Provider must declare at least one of declared identifiers, and,</p>
+</li>
+<li><p>all the Service Property identifiers declared by the Service
+  Provider must be declared by the Identity Provider.</p>
+</li>
+</ul>
+<p><a name="representation-of-entity-categories-in-metadata"></a></p>
+<h3 id="15-representation-of-entity-categories-in-metadata">1.5. Representation of Entity Categories in Metadata</h3>
+<p>Entity categories defined in this document are placed in an entity’s
+metadata record as an attribute value within an entity category
+attribute (SAML attribute with name <code>http://macedir.org/entity-category</code>).
+If more than one entity category identifier is included in the metadata
+of a service, it MUST be placed as multiple attribute values within a
+single entity category attribute.</p>
+<pre class="hljs"><code>&lt;md:EntityDescriptor entityID=<span class="hljs-string">&quot;https://eid2.example.com/entityid&quot;</span>&gt;    
+  &lt;md:Extensions&gt;    
+    &lt;mdattr:EntityAttributes xmln<span class="hljs-variable">s:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;    
+    ...    
+      &lt;sam<span class="hljs-variable">l:Attribute</span> Name=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
+                      NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;    
+        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          http://id.elegnamnden.<span class="hljs-keyword">se</span>/<span class="hljs-keyword">ec</span>/<span class="hljs-number">1.0</span>/loa3-pnr
+        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;
+        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          http://id.swedenconnect.<span class="hljs-keyword">se</span>/contract/sc/<span class="hljs-number">1.0</span>/eidas
+        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;    
+        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          http://id.elegnamnden.<span class="hljs-keyword">se</span>/sprop/<span class="hljs-number">1.0</span>/mobile-auth
+        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;    
+      &lt;/sam<span class="hljs-variable">l:Attribute</span>&gt;    
+    &lt;/mdattr:EntityAttributes&gt;    
+  &lt;/md:Extensions&gt;    
+  ...</code></pre><p><em>Example of how entity categories are represented in metadata.</em></p>
+<p><a name="definitions-for-service-entity-categories"></a></p>
+<h2 id="2-definitions-for-service-entity-categories">2. Definitions for Service Entity Categories</h2>
+<p>This section contains a listing of Service Entity Categories that are defined within 
+the Swedish eID Framework. This listing may not be complete, and the federation operator
+may define additional categories.</p>
+<p>All service entity category identifiers are prefixed with
+<code>http://id.elegnamnden.se/ec</code> or <code>http://id.swedenconnect.se/ec</code> (defined after Aug. 2018).</p>
+<p>A service entity category identifies an arbitrary set of requirements and conditions that is required by the consuming service and provided by the providing service. Each service entity category specifies its own set of requirements and conditions. Typically, such requirements and conditions include requirements on level of assurance (LoA) and requirements on mandatory attributes. For contract or business agreement requirements <a href="#service-contract-categories">Service Contract Categories</a> should be used.</p>
+<p>A providing service declaring a service entity category that consists of both a level of assurance requirement and an attribute set MUST guarantee that the release of the given attributes are consistent with the level of assurance requirement.</p>
+<p>This specification does not impose any other limitations on what requirements or conditions that can be identified by a service entity category and there are no defined technical mechanisms to ensure that any service correctly implement any of these requirements. The main purpose of the service entity category is service matching in accordance with <a href="#consuming-and-providing-services">section 1.3</a> and any requirements and conditions that serves this purpose are considered valid.</p>
+<p><strong>Note</strong>: A providing service that does not comply with any of the defined service entity categories may define its own service entity category identifier in order to utilize the entity category matching rules. Any service entity category identifier defined outside of this specification should use the prefix <code>http://id.swedenconnect.se/ec/&lt;org&gt;</code>, where <code>org</code> is the defining organization&#39;s identifier.</p>
+<p><a name="natural-personal-identity-with-civic-registration-number"></a></p>
+<h3 id="21-natural-personal-identity-with-civic-registration-number">2.1. Natural Personal Identity with Civic Registration Number</h3>
+<p>This section define Service Entity Categories that has attribute requirements 
+according to the &quot;Natural Personal Identity with Civic Registration Number&quot; 
+(<code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>) attribute set as defined in section 2.3 
+of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].</p>
+<p><strong>Note</strong>: The <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code> attribute set includes the <code>personalIdentityNumber</code> attribute. See section <a href="#accepts-coordination-number">6.2</a>, &quot;<a href="#accepts-coordination-number">accepts-coordination-number</a>&quot;, for specific requirements concerning delivering a coordination number in this attribute. </p>
+<p><a name="loa2-pnr"></a></p>
+<h4 id="211-loa2-pnr">2.1.1. loa2-pnr</h4>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa2-pnr</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
+<blockquote>
+<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
+<p><a name="loa3-pnr"></a></p>
+<h4 id="212-loa3-pnr">2.1.2. loa3-pnr</h4>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
+<blockquote>
+<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
+<p><a name="loa4-pnr"></a></p>
+<h4 id="213-loa4-pnr">2.1.3. loa4-pnr</h4>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa4-pnr</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
+<p><a name="eidas-pnr-delivery"></a></p>
+<h4 id="214-eidas-pnr-delivery">2.1.4. eidas-pnr-delivery</h4>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/eidas-pnr-delivery</code></p>
+<p><strong>Description</strong>: For asserting a Swedish identity to a foreign service provider via the Swedish eIDAS Proxy Service. This entity category MUST NOT be set by any entities other than Identity Providers providing identity assertions to the Swedish eIDAS Proxy Service and by the Swedish eIDAS Proxy Service itself.</p>
+<p>Attribute release is based on the &quot;Natural Personal Identity with Civic Registration Number&quot; attribute set with the addition of a mandatory <code>dateOfBirth</code>-attribute (<code>urn:oid:1.3.6.1.5.5.7.9.1</code>). The reason for the mandatory <code>dateOfBirth</code>-attribute is that this information is required by the eIDAS minimum dataset and therefore must be obtained by the receiving eIDAS Proxy Service. Date of birth can not always reliably be derived from the <code>personalIdentityNumber</code> attribute.</p>
+<p>It is the responsibility of the Swedish eIDAS Proxy Service to transform these attributes into eIDAS attributes.</p>
+<p><strong>LoA-identifier</strong>: Not applicable</p>
+<blockquote>
+<p>An Identity Provider delivering assertions to the eIDAS framework is obliged to announce which levels that it supports by including the corresponding eIDAS authentication context URIs defined in section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>] as assurance certification attributes in its metadata as described in section 2.1.3 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code> where the <code>dateOfBirth</code> attribute (<code>urn:oid:1.3.6.1.5.5.7.9.1</code>) is mandatory.</p>
+<p><a name="eidas-natural-person-attribute-set"></a></p>
+<h3 id="22-eidas-natural-person-attribute-set">2.2. eIDAS Natural Person Attribute Set</h3>
+<p><a name="eidas-naturalperson"></a></p>
+<h4 id="221-eidas-naturalperson">2.2.1. eidas-naturalperson</h4>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/eidas-naturalperson</code></p>
+<p><strong>Description</strong>: User authentication according to any of the eIDAS assurance levels and attribute release according to “eIDAS Natural Person Attribute Set” (see section 2.5 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]).</p>
+<p><strong>LoA-identifier</strong>:   Not applicable</p>
+<blockquote>
+<p>It does not make sense to specify the level of assurance for a Service
+Entity Categories intended for eIDAS since this information is not known
+to the Swedish eIDAS-node.</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></p>
+<p><strong>Note</strong>: Attribute release according to the <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code> attribute set may include the <code>mappedPersonalIdentityNumber</code> attribute. See section <a href="#accepts-coordination-number">6.2</a>, &quot;<a href="#accepts-coordination-number">accepts-coordination-number</a>&quot;, for specific requirements concerning delivering a coordination number in this attribute.</p>
+<p><a name="organizational-identity-for-natural-persons"></a></p>
+<h3 id="23-organizational-identity-for-natural-persons">2.3. Organizational Identity for Natural Persons</h3>
+<p>This section define Service Entity Categories that has attribute requirements 
+according to the &quot;Organizational Identity for Natural Persons&quot; 
+(<code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>) attribute set as defined in section 2.4 
+of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].</p>
+<p><a name="loa2-orgid"></a></p>
+<h4 id="231-loa2-orgid">2.3.1. loa2-orgid</h4>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa2-orgid</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
+<blockquote>
+<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
+<p><a name="loa3-orgid"></a></p>
+<h4 id="232-loa3-orgid">2.3.2. loa3-orgid</h4>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa3-orgid</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
+<blockquote>
+<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
+<p><a name="loa4-orgid"></a></p>
+<h4 id="233-loa4-orgid">2.3.3. loa4-orgid</h4>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa4-orgid</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
+<blockquote>
+<p>Or a corresponding LoA 4 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
+<p><a name="natural-personal-identity-without-civic-registration-number"></a></p>
+<h3 id="24-natural-personal-identity-without-civic-registration-number">2.4. Natural Personal Identity without Civic Registration Number</h3>
+<p>This section define Service Entity Categories that has attribute requirements 
+according to the &quot;Natural Personal Identity without Civic Registration Number&quot; 
+(<code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>) attribute set as defined in section 2.2 
+of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].</p>
+<p><a name="loa2-name"></a></p>
+<h3 id="241-loa2-name">2.4.1. loa2-name</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa2-name</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
+<blockquote>
+<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
+<p><a name="loa3-name"></a></p>
+<h3 id="242-loa3-name">2.4.2. loa3-name</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa3-name</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
+<blockquote>
+<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
+<p><a name="loa4-name"></a></p>
+<h3 id="243-loa4-name">2.4.3. loa4-name</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa4-name</code></p>
+<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#se-trust">SE.Trust</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
+<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
+<blockquote>
+<p>Or a corresponding LoA 4 URI (see section 3.1.1 of [<a href="#sc-registry">SC.Registry</a>]).</p>
+</blockquote>
+<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
+<p><a name="definitions-for-service-property-categories"></a></p>
+<h2 id="3-definitions-for-service-property-categories">3. Definitions for Service Property Categories</h2>
+<p>A Service Property Entity Category identifier is specified as an
+attribute value in the entity category attribute in the federation
+metadata and has the purpose of representing a particular service
+property.</p>
+<p>All Service Type identifiers are prefixed with
+<strong><code>http://id.elegnamnden.se/sprop</code></strong>.</p>
+<p><a name="mobile-auth"></a></p>
+<h3 id="31-mobile-auth">3.1. mobile-auth</h3>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/sprop/1.0/mobile-auth</code></p>
+<p><strong>Description</strong>: A service property declaring that the service is adapted to mobile clients and MUST allow users to authenticate using a mobile device that is used to access such service.</p>
+<p>For a providing service, i.e. an Identity Provider, inclusion of the
+mobile-auth category states that the Identity Provider supports
+authentication using mobile devices, <strong>and</strong> that the end-user interface
+of the Identity Provider is adapted for mobile clients.</p>
+<p>Note that an Identity Provider may of course support authentication for
+both desktop and mobile users. In these cases the service must be able
+to display end user interfaces for both types of clients.</p>
+<p>A discovery process will use this Service Property when performing
+filtering of possible Identity Providers, as described in <a href="#use-in-discovery-services">1.4</a>, “<a href="#use-in-discovery-services">Use in
+Discovery</a>”. This means that a consuming service may include the
+mobile-auth category in its metadata in order to have the discovery
+process especially displaying Identity Providers that offer
+authentication using mobile devices.</p>
+<p><a name="scal2"></a></p>
+<h3 id="32-scal2">3.2. scal2</h3>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/sprop/1.0/scal2</code></p>
+<p><strong>Description</strong>: A service property declaring that the service is adapted to support Sole Control Assurance Level 2 (SCAL2) in accordance with [<a href="#sc-sap">SC.SAP</a>]. </p>
+<p>For a providing service, i.e. an Identity Provider, inclusion of the
+scal2 service property states that the Identity Provider will return a &quot;SAD&quot; in response to a <code>SADRequest</code> in an authentication requests from a signing service.</p>
+<p>For consuming services, Signature Services MAY include this service property if all authentication requests from the 
+particular Signature Service include a <code>SADRequest</code> extension. A Service Provider that is not declared as a Signature Service MUST NOT include this service property in its metadata.</p>
+<p><a name="definitions-for-service-type-entity-categories"></a></p>
+<h2 id="4-definitions-for-service-type-entity-categories">4. Definitions for Service Type Entity Categories</h2>
+<p>A Service Type Entity Category identifier is specified as an entity
+attribute in the federation metadata and has the purpose of representing
+a particular service type.</p>
+<p>All Service Type identifiers are prefixed with
+<strong><code>http://id.elegnamnden.se/st</code></strong>.</p>
+<p><a name="sigservice"></a></p>
+<h3 id="41-sigservice">4.1. sigservice</h3>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/sigservice</code></p>
+<p><strong>Description</strong>:  A service type for a Service Provider that provides electronic signature services within the Swedish eID framework.</p>
+<p><a name="public-sector-sp"></a></p>
+<h3 id="42-public-sector-sp">4.2. public-sector-sp</h3>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code></p>
+<p><strong>Description</strong>: A service type that indicates that a Service Provider is a &quot;public sector&quot; SP. This category MUST be used by public sector Service Providers wishing to use eIDAS authentication so that the Swedish eIDAS connector may include this information in the eIDAS authentication request. For other types of Service Providers its use is determined by the federation policy.</p>
+<p><a name="private-sector-sp"></a></p>
+<h3 id="43-private-sector-sp">4.3. private-sector-sp</h3>
+<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code></p>
+<p><strong>Description</strong>: A service type that indicates that a Service Provider is a &quot;private sector&quot; SP. This category MUST be used by private sector Service Providers wishing to use eIDAS authentication so that the Swedish eIDAS connector may include this information in the eIDAS authentication request. For other types of Service Providers its use is determined by the federation policy.</p>
+<p><a name="service-contract-categories"></a></p>
+<h2 id="5-service-contract-categories">5. Service Contract Categories</h2>
+<p>Service Contract Entity Category identifiers are indented for performing service matching based on contracts, or business agreements, between providing and consuming services.</p>
+<p>All Service Contract identifiers are prefixed with <code>http://id.swedenconnect.se/contract/&lt;org&gt;</code>, where <code>org</code> is identifier for the defining organization.</p>
+<p>The meaning of different contracts and business agreements are out of scope for this specification, instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.</p>
+<p><a name="general-entity-categories"></a></p>
+<h2 id="6-general-entity-categories">6. General Entity Categories</h2>
+<p>An entity category of the General Entity Category type is a category that does not fit into any of the other category types regarding definitions and matching rules.</p>
+<p>General category identifiers are prefixed with <code>http://id.swedenconnect.se/general-ec</code>.</p>
+<p><a name="secure-authenticator-binding"></a></p>
+<h3 id="61-secure-authenticator-binding">6.1. secure-authenticator-binding</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code></p>
+<p><strong>Description</strong>: Some authentication schemes use an authentication device (<em>authenticator</em>) that 
+is external, i.e., not bound to the user agent. These types of authentication schemes may be
+vulnerable to certain types of phishing attacks where a fraudster who controls the user agent can
+trick, or persuade, the user to initiate an operation on the authentication device. </p>
+<p>A typical example of the threat described above is where an Identity Provider implements an
+authentication scheme that uses a mobile app as the authenticator. In those cases the user
+normally enters some input (often the user identity) in the web browser (user agent) that is
+then used by the Identity Provider to initiate an authentication session against the app running
+on the user&#39;s mobile device. The problem here is that there is no way we can now that the
+person initiating the operation in the web browser by entering a user identity is the same 
+person who opens, and performs the authentication in the app. </p>
+<p>In order to prevent attacks of this type many authentication schemes offer alternative ways
+of initiating authentication (or signature) sessions, where some sort of binding between the
+user agent and the authentication device is performed. A good example of this is when 
+Identity Providers prompt the user to scan a QR-code displayed in the web browser using the 
+authentication app instead of prompting for the user identity. This effectively binds the
+user agent to the same physical location as the authentication device, and in practice
+makes the attacks described above impossible.</p>
+<p>This profile defines the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> 
+entity category to be declared by Service Providers that require that a secure authenticator
+binding is performed by the Identity Providers supporting this.</p>
+<p>An Identity Provider that supports different methods of initiating authentication, or signature,
+operations, and where at least one of these methods is a &quot;secure authenticator binding&quot; SHOULD
+declare the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity
+category in its metadata.</p>
+<p>An Identity Provider that has declared the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> category in its metadata MUST perform a secure authenticator binding for requests sent
+from Service Providers that have declared this entity category in their metadata entries.</p>
+<p><a name="accepts-coordination-number"></a></p>
+<h3 id="62-accepts-coordination-number">6.2. accepts-coordination-number</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code></p>
+<p><strong>Description</strong>: A special purpose entity category that is declared by Service Providers
+to announce that they accept a Swedish coordination number (samordningsnummer), [<a href="#skv707">SKV707</a>], being delivered in the <code>personalIdentityNumber</code> (<code>urn:oid:1.2.752.29.4.13</code>) attribute.</p>
+<p>The <code>personalIdentityNumber</code> is defined in section 3.1 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>] to contain either a Swedish personal identity number, [<a href="#skv704">SKV704</a>], or a Swedish coordination number, [<a href="#skv707">SKV707</a>]. However, how to utilize coordination numbers in
+electronic services is, or has been, unclear. Not all Service Providers want, or are able to, use these types of identifiers. Therefore, this specification defines the &quot;accepts coordination
+number&quot; category as an opt-in feature for those Service Providers that can accept a <code>personalIdentityNumber</code> attribute to contain a coordination number as well as a personal identity number.</p>
+<p>An Identity Provider conformant with this specification MUST NOT deliver a coordination number
+in the <code>personalIdentityNumber</code> attribute unless the receiving Service Provider has declared 
+the <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> entity category
+in its metadata.</p>
+<p><strong>Note</strong>: This entity category does <strong>not</strong> apply to the eIDAS specific attribute
+<code>mappedPersonalIdentityNumber</code>, see section 3.3.2 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].
+Thus, a coordination number may be included in this attribute even if the Service Provider
+has not declared the entity category. </p>
+<p><a name="supports-user-message"></a></p>
+<h3 id="63-supports-user-message">6.3. supports-user-message</h3>
+<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code></p>
+<p><strong>Description</strong>: Service Providers may include the <code>&lt;umsg:UserMessage&gt;</code> extension in authentication requests for the purpose of displaying a custom &quot;user message&quot; for the authentication users, see [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>]. An Identity Provider announces support for this extension by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category.</p>
+<p><a name="references"></a></p>
+<h2 id="7-references">7. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2meta"></a>
+<strong>[SAML2Meta]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">OASIS Standard, Metadata for the OASIS Security Assertion Markup
+Language (SAML) V2.0, March
+2005.</a></p>
+</blockquote>
+<p><a name="saml2metaattr"></a>
+<strong>[SAML2MetaAttr]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html">OASIS Committee Specification, SAML V2.0 Metadata Extension for
+Entity Attributes Version 1.0, August
+2009.</a></p>
+</blockquote>
+<p><a name="entcat"></a>
+<strong>[EntCat]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc8409">RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types</a>.</p>
+</blockquote>
+<p><a name="skv704"></a>
+<strong>[SKV704]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv704-8.pdf">Skatteverket, SKV 704 Utgåva 8,
+Personnummer</a>.</p>
+</blockquote>
+<p><a name="skv707"></a>
+<strong>[SKV707]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf">Skatteverket, SKV 707, Utgåva 2,
+Samordningsnummer</a>.</p>
+</blockquote>
+<p><a name="se-trust"></a>
+<strong>[SE.Trust]</strong></p>
+<blockquote>
+<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverket för Svensk e-legitimation</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
+</blockquote>
+<p><a name="sc-saml-attrs"></a>
+<strong>[SC.SAML.Attrs]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-sap"></a>
+<strong>[SC.SAP]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
+</blockquote>
+<p><a name="sc-saml-umsg"></a>
+<strong>[SC.SAML.UMsg]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="8-changes-between-versions">8. Changes between versions</h2>
+<p><strong>Changes between version 1.8 and version 1.9:</strong></p>
+<ul class="list">
+<li><p>Fixed some broken links.</p>
+</li>
+<li><p>Section 6.2, &quot;accepts-coordination-number&quot;, was updated with changed logic for
+the <code>mappedPersonalIdentityNumber</code> attribute.</p>
+</li>
+<li><p>Added section 6.3, &quot;supports-user-message&quot;, with a definition for the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.7 and version 1.8:</strong></p>
+<ul class="list">
+<li><p>Section 2 was re-structured where new entity categories for loaX-orgid and loaX-name.</p>
+</li>
+<li><p>The Service Entity Category loa3-hsaid was removed. Its use is out of scope for 
+the Swedish eID Framework. However, it may be defined by the federation operator.</p>
+</li>
+<li><p>Section 6.2, accepts-coordination-number, defining the general entity category 
+<code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> was added.
+This category introduces an opt-in feature for accepting Swedish coordination numbers
+delivered in the <code>personalIdentityNumber</code> attribute.</p>
+</li>
+<li><p>For many services entity categories we have added the following text under the &quot;LoA-identifier&quot; requirement: &quot;Or a corresponding LoA X URI&quot;. This means that the service entity category
+also applies to variants to the official LoA URI (defined in [<a href="#sc-registry">SC.Registry</a>]).</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
+<ul class="list">
+<li><p>A new entity category type, Service Contract, was added to section 5.</p>
+</li>
+<li><p>The reference [EntCat] now refers to <a href="https://tools.ietf.org/html/rfc8409">RFC-8409</a> instead of 
+<a href="https://tools.ietf.org/html/draft-young-entity-category">https://tools.ietf.org/html/draft-young-entity-category</a>.</p>
+</li>
+<li><p>Chapter 6, &quot;General Entity Categories&quot;, introduced a general entity category type for miscellaneous purposes.</p>
+</li>
+<li><p>Section 6.1, &quot;secure-authenticator-binding&quot;, was added defining the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category.</p>
+</li>
+<li><p>Section 2.6, &quot;loa3-hsaid&quot;, was added. This section defines a service entity category for LoA3 where HSA-ID is the primary identity attribute.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
+<ul class="list">
+<li><p>The Service Property Category &quot;scal2&quot; was added to section 3.2.</p>
+</li>
+<li><p>Section 2.5, &quot;eidas-pnr-delivery&quot;, was updated to also require attribute release of the <code>dateOfBirth</code>-attribute.</p>
+</li>
+<li><p>Section 2.1, &quot;loa3-pnr&quot;, was updated with a restriction stating that the <code>personalIdentityNumber</code> only may contain a Swedish personal identity number (&quot;personnummer&quot;) and not a coordination number (&quot;samordningsnummer&quot;), if attribute release is made in <code>loa3-pnr</code> scope.</p>
+</li>
+<li><p>The loa3-hsaid Service Entity Category was defined in section 2.6.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
+<ul class="list">
+<li><p>Introduced the Service Entity Category “eidas-naturalperson”
+  (section 2.4) for support of authentication against the eIDAS
+  Framework.</p>
+</li>
+<li><p>Introduced the Service Entity Category &quot;eidas-pnr-delivery&quot; (section 2.5) for use by Swedish Identity Providers delivering assertions to Service Providers within the eIDAS federation.</p>
+</li>
+<li><p>  Added the Service Type Entity Categories &quot;public-sector-sp&quot; and &quot;private-sector-sp&quot; to section 4.</p>
+</li>
+<li><p>  Minor changes regarding discovery.</p>
+</li>
+<li><p>  Updates to explanatory text in chapter 2 about usage of service entity categories.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
+<ul class="list">
+<li><p>Version 1.3 of [Eid2Attributes] changed the terms “attribute
+  profiles” to “attribute sets”. This specification has therefore been
+  updated to reflect these changes.</p>
+</li>
+<li><p>Chapter 1.5, “Representation of Entity Categories in Metadata”, was
+  added to illustrate how entity categories are represented in
+  metadata.</p>
+</li>
+<li><p>Clarifications regarding the definition of Service Entity Categories
+  were made to chapter 2.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
+<ul class="list">
+<li><p>In chapter 1.4, “Use in Discovery Services”, the text that referred
+  to the Discovery Service usage of Service Property Entity Categories
+  when rendering user interfaces was removed.</p>
+</li>
+<li><p>In chapter 3.1, “mobile-auth”, changes were made to reflect that the
+  use of mobile-auth no longer governs which type of end user
+  interface the Discovery Service should render.</p>
+</li>
+<li><p>In chapter 2, “Definitions for Service Entity Categories”, URIs for
+  attribute profiles were added in definitions of the service entity
+  categories.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li>In chapter 2, “Definitions for Service Entity Categories”, two new
+  service entity categories have been defined, loa2-pnr and loa4-pnr.</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li><p>  The service property category mobile-auth was added.</p>
+</li>
+<li><p>Changes was made to chapter 1.4, “Use in Discovery Services”, where
+  mobile-auth was referred.</p>
+</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html b/docs/december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
new file mode 100644
index 0000000..882b1b6
--- /dev/null
+++ b/docs/december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
@@ -0,0 +1,683 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Implementation Profile for using OASIS DSS in Central Signing Services</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="implementation-profile-for-using-oasis-dss-in-central-signing-services">Implementation Profile for using OASIS DSS in Central Signing Services</h1>
+<h3 id="version-16---2024-12-04">Version 1.6 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-312</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#terminology">Terminology</a></p>
+<p> 1.2. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.3. <a href="#namespace-references">Namespace references</a></p>
+<p> 1.4. <a href="#identification">Identification</a></p>
+<p> 1.5. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#sign-request-and-response-messages"><strong>Sign request and response messages</strong></a></p>
+<p> 2.1. <a href="#sign-requests">Sign Requests</a></p>
+<p> 2.1.1. <a href="#signature-on-sign-requests">Signature on Sign Requests</a></p>
+<p> 2.1.2. <a href="#data-to-be-signed">Data To Be Signed</a></p>
+<p> 2.1.3. <a href="#dss-extension">DSS Extension</a></p>
+<p> 2.1.3.1. <a href="#version">Version</a></p>
+<p> 2.1.3.2. <a href="#conditions">Conditions</a></p>
+<p> 2.1.3.3. <a href="#signer">Signer</a></p>
+<p> 2.1.3.4. <a href="#identityprovider">IdentityProvider</a></p>
+<p> 2.1.3.5. <a href="#signrequester">SignRequester</a></p>
+<p> 2.1.3.6 <a href="#signservice">SignService</a></p>
+<p> 2.1.3.7. <a href="#requestedsignaturealgorithm">RequestedSignatureAlgorithm</a></p>
+<p> 2.1.3.8. <a href="#signmessage">SignMessage</a></p>
+<p> 2.1.3.8.1. <a href="#signmessage-element">SignMessage Element</a></p>
+<p> 2.1.3.8.2. <a href="#requesting-identity-provider-to-display-signmessage">Requesting Identity Provider to Display SignMessage</a></p>
+<p> 2.1.3.9. <a href="#certrequestproperties">CertRequestProperties</a></p>
+<p> 2.1.3.9.1. <a href="#authncontextclassref">AuthnContextClassRef</a></p>
+<p> 2.1.3.9.2. <a href="#requestedcertattributes">RequestedCertAttributes</a></p>
+<p> 2.2. <a href="#sign-responses">Sign Responses</a></p>
+<p> 2.2.1. <a href="#signature-on-sign-responses">Signature on Sign Responses</a></p>
+<p> 2.2.2. <a href="#sign-response-status-information">Sign Response Status Information</a></p>
+<p> 2.2.3. <a href="#generated-signature">Generated Signature</a></p>
+<p> 2.2.4. <a href="#dss-extension">DSS Extension</a></p>
+<p> 2.2.4.1. <a href="#version2">Version</a></p>
+<p> 2.2.4.2. <a href="#responsetime">ResponseTime</a></p>
+<p> 2.2.4.3. <a href="#request">Request</a></p>
+<p> 2.2.4.4. <a href="#signerassertioninfo">SignerAssertionInfo</a></p>
+<p> 2.2.4.5. <a href="#signaturecertificatechain">SignatureCertificateChain</a></p>
+</li>
+<li><p><a href="#http-post-binding"><strong>HTTP POST Binding</strong></a></p>
+<p> 3.1. <a href="#message-exchange-model">Message Exchange Model</a></p>
+<p> 3.1.1. <a href="#sign-request-xhtml-form">Sign Request XHTML Form</a></p>
+<p> 3.1.2. <a href="#sign-response-xhtml-form">Sign Response XHTML Form</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+<p> 4.1. <a href="#normative-references">Normative References</a></p>
+<p> 4.2. <a href="#informative-references">Informative References</a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This document specifies an implementation profile for exchange of sign
+requests and responses using the OASIS DSS protocol [<a href="#dss">DSS</a>], enhanced by
+the DSS Extensions for Federated Central Signing Services [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>Section 2 defines the sign request and response messages and section 3
+defines the transport of these messages using HTTP POST.</p>
+<p><a name="terminology"></a></p>
+<h3 id="11-terminology">1.1. Terminology</h3>
+<table>
+<thead>
+<tr>
+<th>Term</th>
+<th>Defined meaning</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>User</strong></td>
+<td>The entity requested to sign a document.</td>
+</tr>
+<tr>
+<td><strong>Requesting Service</strong></td>
+<td>The service requesting the signature on a particular document by a particular user.</td>
+</tr>
+<tr>
+<td><strong>Signing Service</strong></td>
+<td>A centralized service that manages the process to authenticate the user that has been requested to sign a document, and the process to obtain the user’s signature on the requested document.</td>
+</tr>
+</tbody></table>
+<p><a name="requirements-notation"></a></p>
+<h3 id="12-requirements-notation">1.2. Requirements Notation</h3>
+<p>The keywords <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
+<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
+[<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations. When these words are
+not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="namespace-references"></a></p>
+<h3 id="13-namespace-references">1.3. Namespace references</h3>
+<p>Conventional XML namespace prefixes are used throughout the listings in
+this specification to stand for their respective namespaces as follows,
+whether or not a namespace declaration is present in the example:</p>
+<table>
+<thead>
+<tr>
+<th>Prefix</th>
+<th>XML Namespace</th>
+<th>Comments</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>csig</td>
+<td><code>http://id.elegnamnden.se/csig/1.1/dss-ext/ns</code></td>
+<td>For the DSS extension namespace [<a href="#dss-ext">DSS-Ext</a>] (default namespace).</td>
+</tr>
+<tr>
+<td>dss</td>
+<td><code>urn:oasis:names:tc:dss:1.0:core:schema</code></td>
+<td>The DSS core namespace [<a href="#dss">DSS</a>].</td>
+</tr>
+<tr>
+<td>ds</td>
+<td><code>http://www.w3.org/2000/09/xmldsig\#</code></td>
+<td>The XML Signature Syntax and Processing specification [<a href="#xmlsig">XMLSig</a>] and its governing schema [<a href="#xmlsig-xsd">XMLSig-XSD</a>].</td>
+</tr>
+<tr>
+<td>saml</td>
+<td><code>urn:oasis:names:tc:SAML:2.0:assertion</code></td>
+<td>The SAML V2.0 assertion namespace, defined in the schema [<a href="#saml-xsd">SAML-XSD</a>].</td>
+</tr>
+</tbody></table>
+<hr>
+<p><a name="identification"></a></p>
+<h3 id="14-identification">1.4. Identification</h3>
+<p>The following URI identifier identifies this profile:</p>
+<blockquote>
+<p><strong><code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code></strong></p>
+</blockquote>
+<p><a name="structure"></a></p>
+<h3 id="15-structure">1.5. Structure</h3>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;EidElement&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
+<code>OtherCode</code>.</p>
+<p><a name="sign-request-and-response-messages"></a></p>
+<h2 id="2-sign-request-and-response-messages">2. Sign Request and Response Messages</h2>
+<p>This section defines a profile for sign requests and responses using the
+OASIS DSS standard [<a href="#dss">DSS</a>] in combination with “DSS extensions for
+Federated Central Signing Services” [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>In the following sections the OASIS DSS standard is referred to as “DSS”
+and the DSS extensions are referred to as “DSS-Ext”.</p>
+<p>Conformance with this implementation profile requires full conformance
+with DSS and DSS-Ext. In case of conflict between DSS-Ext and DSS,
+DSS-Ext is the normative one. In case of differences between this
+implementation profile and DSS-Ext, this implementation profile is the
+normative one.</p>
+<p><a name="sign-requests"></a></p>
+<h3 id="21-sign-requests">2.1. Sign Requests</h3>
+<p>Sign requests are carried in a <code>&lt;dss:SignRequest&gt;</code> element according to requirements and conditions of the following subsections.</p>
+<p>The <code>&lt;dss:SignRequest&gt;</code> element MUST have a <code>Profile</code> attribute with the value <code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code>, which specifies conformance to this implementation profile.</p>
+<p>The <code>&lt;dss:SignRequest&gt;</code> element MUST have a <code>RequestID</code> attribute with a value that uniquely identifies this request. The <code>RequestID</code> value MUST be a random generated value with at least 128 bit entropy and a length of at least 20 bytes.</p>
+<p><a name="signature-on-sign-requests"></a></p>
+<h4 id="211-signature-on-sign-requests">2.1.1. Signature on Sign Requests</h4>
+<p>Sign requests MUST be signed. The signature MUST have a Same-Document URI-Reference (URI=””) to ensure that the signature covers the complete <code>&lt;dss:SignRequest&gt;</code> element.</p>
+<p>The resulting <code>&lt;ds:Signature&gt;</code> element MUST be placed inside the <code>&lt;dss:OptionalInputs&gt;</code> element in accordance with section 5 of [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>The Signature Service MUST NOT process the sign request unless the signature of the sign request can be authenticated as originating from a legitimate Requesting Service.</p>
+<p><a name="data-to-be-signed"></a></p>
+<h4 id="212-data-to-be-signed">2.1.2. Data To Be Signed</h4>
+<p>A representation of the document to be signed MUST be provided in accordance with section 4.1 of [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>Data to be signed MUST be provided in a <code>&lt;SignTaskData&gt;</code> element.</p>
+<p>The <code>&lt;SignTasks&gt;</code> element MAY contain one or more <code>&lt;SignTaskData&gt;</code> elements, representing one or more requested signatures.</p>
+<p><a name="dss-extension"></a></p>
+<h4 id="213-dss-extension">2.1.3. DSS Extension</h4>
+<p>The <code>&lt;dss:OptionalInput&gt;</code> element of the sign request MUST contain a
+<code>&lt;SignRequestExtension&gt;</code> element according to requirements and
+conditions of the following subsections.</p>
+<p><a name="version"></a></p>
+<h5 id="2131-version">2.1.3.1. Version</h5>
+<p>The <code>Version</code> attribute giving the version number of the [<a href="#dss-ext">DSS-Ext</a>] specification
+SHOULD be set to the version number that is supported by the sender.
+If absent, the default value &quot;1.1&quot; MUST be assumed.</p>
+<p><a name="conditions"></a></p>
+<h5 id="2132-conditions">2.1.3.2. Conditions</h5>
+<p>A <code>&lt;saml:Conditions&gt;</code> element MUST be present. This element MUST NOT
+contain any information in addition to what is defined in section 3.1 of
+[<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>If the <code>&lt;saml:Conditions&gt;</code> element contains the <code>NotBefore</code> and/or <code>NotOnOrAfter</code> attributes, the Signature Service consuming these values MAY consider them in its processing. However, a Signature Service MUST have a limitation on the maximum age of received messages, and if <code>NotOnOrAfter</code> exceeds this limitation, the <code>NotOnOrAfter</code> value MUST be ignored.</p>
+<p>This specification does not state how long the message age limitation should be. However, it is RECOMMENDED that it does not exceed 3 minutes. </p>
+<p><a name="signer"></a></p>
+<h5 id="2133-signer">2.1.3.3. Signer</h5>
+<p>The Requesting Service MAY include a <code>&lt;Signer&gt;</code> element containing the SAML attributes that 
+are necessary in order to uniquely identify the signer. The present attributes MUST match the attributes
+that are provided for this signer when authenticating the signer using the Identity Provider specified in the <code>&lt;IdentityProvider&gt;</code> element.</p>
+<p>It is RECOMMENDED that a Signature Requester that has authenticated the user before sending a 
+signature request includes relevant SAML attributes in the <code>&lt;Signer&gt;</code> element. If this is not done, 
+the identity of the signer needs to be verified after the signature process has completed in order to ensure
+that the authenticated user was the signer.</p>
+<p>The Signing Service MUST match all attribute values provided in the
+<code>&lt;Signer&gt;</code> element with SAML attributes provided for this signer
+subject in a valid assertion obtained from the specified Identity
+Provider.</p>
+<p>If any of the attributes specified in the <code>&lt;Signer&gt;</code> element cannot
+be found or matched with a corresponding attribute value from an
+obtained assertion from the specified Identity Provider, the Signing
+Service MUST reject the sign request.  </p>
+<p><a name="identityprovider"></a></p>
+<h5 id="2134-identityprovider">2.1.3.4. IdentityProvider</h5>
+<p>This element MUST be present, specifying the SAML entityID of the
+Identity Provider that MUST be used to authenticate the signer. The
+Signing Service MUST NOT generate the requested signature unless the
+signer is successfully authenticated through this Identity Provider.</p>
+<p><a name="signrequester"></a></p>
+<h5 id="2135-signrequester">2.1.3.5. SignRequester</h5>
+<p>This element MUST be present, specifying the identity of the Requesting
+Service in the form of its SAML entityID.</p>
+<p><a name="signservice"></a></p>
+<h5 id="2136-signservice">2.1.3.6 SignService</h5>
+<p>This element MUST be present, specifying the SAML entityID of the
+Signing Service that is the target of this sign request.</p>
+<p><a name="requestedsignaturealgorithm"></a></p>
+<h5 id="2137-requestedsignaturealgorithm">2.1.3.7. RequestedSignatureAlgorithm</h5>
+<p>This element MAY be present, specifying a URI that identifies a
+signature algorithm that the Requesting Service prefers to be used when
+generating the requested signature.</p>
+<p>When this element is absent, the default signing algorithm is RSA with
+SHA-256, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</code>.</p>
+<p><a name="signmessage"></a></p>
+<h5 id="2138-signmessage">2.1.3.8. SignMessage</h5>
+<p><a name="signmessage-element"></a></p>
+<h6 id="21381-signmessage-element">2.1.3.8.1. SignMessage Element</h6>
+<p>This element MAY be present to provide information that the Identity
+Provider MAY display for the user before obtaining the user’s consent to
+sign. The message MAY be provided in clear text or in encrypted form.
+The attribute <code>MustShow</code> MUST be set to <code>true</code> if the Identity Provider is
+required to show this message to the user. When the message is provided
+in encrypted form, the <code>DisplayEntity</code> attribute MUST include the entityID
+of the Identity Provider holding the private decryption key. The
+encryption key included in the metadata of the identified Identity
+Provider SHOULD be used to encrypt the message.</p>
+<p>The message MUST be encoded using UTF-8 and MUST be using one of the
+formats plain text, HTML or markdown. The appropriate MIME type must be
+declared in the <code>MimeType</code> attribute.</p>
+<p>For messages in HTML format, the message MUST NOT contain tags and
+attributes for each tag other than those listed in the following table:</p>
+<table>
+<thead>
+<tr>
+<th>HTML Tags</th>
+<th>Type</th>
+<th>Allowed attributes</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>h1, h2, h3, h4</td>
+<td>Headings</td>
+<td>style</td>
+</tr>
+<tr>
+<td>div, span, p</td>
+<td>Section</td>
+<td>style</td>
+</tr>
+<tr>
+<td>table, tr, td</td>
+<td>Table</td>
+<td>style</td>
+</tr>
+<tr>
+<td>b, strong</td>
+<td>Highlight</td>
+<td>style</td>
+</tr>
+<tr>
+<td>i, u, br</td>
+<td>Format</td>
+<td>&nbsp;</td>
+</tr>
+<tr>
+<td>ol, ul, li</td>
+<td>List</td>
+<td>&nbsp;</td>
+</tr>
+</tbody></table>
+<p>Allowed HTML entities for character replacement SHALL be restricted to
+<code>amp</code>, <code>gt</code>, <code>lt</code>, <code>quot</code> and <code>nbsp</code> (in the form <code>&amp;entity-name;</code>).</p>
+<p>HTML messages MUST NOT contain any URI references to data outside the
+message and MUST NOT contain any JavaScript in any form.</p>
+<p><a name="requesting-identity-provider-to-display-signmessage"></a></p>
+<h6 id="21382-requesting-identity-provider-to-display-signmessage">2.1.3.8.2. Requesting Identity Provider to Display SignMessage</h6>
+<p>The means through which the Service Provider requests the Identity
+Provider to display a sign message is defined in section 7.1.1 of “Deployment Profile
+for the Swedish eID Framework” [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+<p>In addition to the requirements in section 7.1.1 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] the 
+Signature Service MUST apply the following process regarding the inclusion of the
+<code>AuthnContextClassRef</code> URI to include in the <code>AuthnRequest</code> sent to the Identity Provider 
+when authenticating the user for signing:</p>
+<ol class="list">
+<li><p>Determine requested LoA (Level of Assurance) by either:</p>
+</li>
+<li><p>Get the LoA, or LoA:s, from the <code>AuthnContextClassRef</code> specified in the sign request as <code>CertRequestProperties</code>, or</p>
+</li>
+<li><p>if the LoA reference from the sign request is absent then use the default LoA according to the governing policy.</p>
+</li>
+<li><p>Include the LoA URI(s) from the step above as <code>RequestedAuthnContext</code> if supported by the Identity Provider.
+If none of the LoA:s are supported by the Identity Provider, fail signing and return an error sign response,
+indicating a request failure (the requested LoA(s) was inconsistent with the specified Identity Provider).</p>
+</li>
+</ol>
+<p><a name="certrequestproperties"></a></p>
+<h5 id="2139-certrequestproperties">2.1.3.9. CertRequestProperties</h5>
+<p>This element MAY be present to provide requested properties of generated
+signature certificates according to section 3.1.1 of [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>When the <code>CertType</code> attribute is present with a value of <code>QC/SSCD</code> the signature service MUST request authentication in accordance with section 7.1.2 of “Deployment Profile for the Swedish eID Framework” [<a href="#sc-saml-profile">SC.SAML.Profile</a>], or reject the request.</p>
+<p><a name="authncontextclassref"></a></p>
+<h6 id="21391-authncontextclassref">2.1.3.9.1. AuthnContextClassRef</h6>
+<p>This element MAY be present to specify the Level of Assurance(s) required
+in order to issue the signing certificate. </p>
+<p><a name="requestedcertattributes"></a></p>
+<h6 id="21392-requestedcertattributes">2.1.3.9.2. RequestedCertAttributes</h6>
+<p>This element MAY be present to specify any number of attributes that the
+Requesting Service requires or requests to be included as a
+representation of the subject in the signature certificate that is
+generated with the requested signature.</p>
+<p>The Signature Service MUST NOT generate the requested signature unless
+it can obtain attribute values from an authoritative source for all
+requested attributes that is marked as &quot;required&quot;. The Signature service
+SHOULD attempt to provide all &quot;requested&quot; attributes.</p>
+<p>The Signing Service MAY use an Attribute Authority as complementary
+source to obtain requested attribute values, as long as the identity
+assertion provided by the specified Identity Provider is sufficient to
+uniquely identify the signer. The Sign Requester MAY provide one or more
+SAML entityID identifiers of Attribute Authorities in
+<code>&lt;AttributeAuthority&gt;</code> elements, which could be used to obtain an
+attribute value for the requested attribute.</p>
+<p>It is left to local policy of the Signature Service whether it accepts
+any <code>DefaultValue</code> attribute value for any requested attributes as being
+provided by an authoritative source. If a <code>DefaultValue</code> is accepted as
+authoritative, it MUST NOT conflict with any attributes received by the
+specified Identity Provider or Attribute Authority when authenticating
+the signer. If the requested attribute is provided by the Identity
+Provider or any Attribute Authority used by the Signing Service, then
+these values MUST be used over the <code>DefaultValue</code>.</p>
+<p><a name="sign-responses"></a></p>
+<h3 id="22-sign-responses">2.2. Sign Responses</h3>
+<p>Sign responses are carried in a <code>&lt;dss:SignResponse&gt;</code> element
+according to requirements and conditions of the following subsections.</p>
+<p>The <code>&lt;dss:SignResponse&gt;</code> element MUST have a <code>Profile</code> attribute with
+the value <code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code>, which
+specifies conformance to this implementation profile.</p>
+<p>The <code>&lt;dss:SignResponse&gt;</code> element MUST have a <code>RequestID</code> attribute
+with a value that is identical to the sign request that is being
+serviced through this sign response.</p>
+<p><a name="signature-on-sign-responses"></a></p>
+<h4 id="221-signature-on-sign-responses">2.2.1. Signature on Sign Responses</h4>
+<p>Sign responses MUST be signed. The signature MUST have a Same-Document
+URI-Reference (URI=””) to ensure that the signature covers the complete
+<code>&lt;dss:SignResponse&gt;</code> element.</p>
+<p>The resulting <code>&lt;ds:Signature&gt;</code> element MUST be placed inside the
+<code>&lt;dss:OptionalOutputs&gt;</code> element in accordance with section 5 of
+[<a href="#dss-ext">DSS-Ext</a>].</p>
+<p><a name="sign-response-status-information"></a></p>
+<h4 id="222-sign-response-status-information">2.2.2. Sign Response Status Information</h4>
+<p>Implementations of this specification MUST return a
+<code>&lt;dss:ResultMajor&gt;</code> value and MAY return a <code>&lt;dss:ResultMinor&gt;</code>
+value. Implementations of this specification are released from the
+requirement to return any of the listed values of
+<code>&lt;dss:ResultMinor&gt;</code>, specified in the DSS standard, when returning
+the <code>&lt;dss:ResultMajor&gt;</code> value
+<code>urn:oasis:names:tc:dss:1.0:resultmajor:Success</code>, since all the listed
+<code>&lt;dss:ResultMinor&gt;</code> values relates to signature validation and not
+signature creation.</p>
+<p>With the exception above, the response values defined in section 2.6 of the DSS standard, amended by status identifiers defined below<sup>*</sup> SHOULD be used.</p>
+<p>| <strong>URL</strong> | <strong>Description</strong> |
+| :--- | :--- | :--- |
+| <code>http://id.elegnamnden.se/sig-status/1.0/req-expired</code> | The time window for the signature request has expired. |
+| <code>http://id.elegnamnden.se/sig-status/1.0/user-mismatch</code> | The authenticated user does not match the signer identity attributes in the request.
+| <code>http://id.elegnamnden.se/sig-status/1.0/unsupported-loa</code> | The requested level of assurance for user authentication is not supported. |
+| <code>http://id.elegnamnden.se/sig-status/1.0/sigmessage-error</code> | A requirement to display sign message was included in the sign request, but the sign service could not establish that the sign message was displayed to the user. |
+| <code>http://id.elegnamnden.se/sig-status/1.0/user-cancel</code> | The end user cancelled the signature operation. |
+| <code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code> | The authentication during the signature operation failed. |
+| <code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code> | The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud). |</p>
+<p><strong>Note:</strong> The <code>authn-failed</code> and <code>security-violation</code> codes were introduced for version 1.5 (of [<a href="#dss-ext">DSS-Ext</a>]), and a client not supporting this version will fail to understand these error codes. Whether a Signature Service checks the client version support or not before using these codes are out of scope for this profile. </p>
+<blockquote>
+<p>[*]: Also listed in section 3.1.7 of [<a href="#sc-registry">SC.Registry</a>].</p>
+</blockquote>
+<p><a name="generated-signature"></a></p>
+<h4 id="223-generated-signature">2.2.3. Generated Signature</h4>
+<p>The generated signature result data SHALL be provided in
+<code>&lt;SignTaskData&gt;</code> element according to section 4.1.1 of [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>One <code>&lt;SignTaskData&gt;</code> element shall be provided for each successfully
+generated signature as a result of the corresponding request.</p>
+<p><a name="dss-extension"></a></p>
+<h4 id="224-dss-extension">2.2.4. DSS Extension</h4>
+<p>The <code>&lt;dss:OptionalInput&gt;</code> element of the sign response MUST contain
+a <code>&lt;SignResponseExtension&gt;</code> element according to requirements and
+conditions of the following subsections.</p>
+<p><a name="version2"></a></p>
+<h5 id="2241-version">2.2.4.1. Version</h5>
+<p>The version of the [<a href="#dss-ext">DSS-Ext</a>] specification under which the 
+request was processed and response was constructed. This version MUST be the same
+version as given in the <code>SignRequestExtension</code> (see section <a href="#version">2.1.3.1</a>, &quot;<a href="#version">Version</a>)&quot;.</p>
+<p>For backwards compatibility reasons that attribute MAY be absent if version &quot;1.1&quot; was requested. 
+Otherwise, it MUST be set.</p>
+<p><a name="responsetime"></a></p>
+<h5 id="2242-responsetime">2.2.4.2. ResponseTime</h5>
+<p>The <code>&lt;ResponseTime&gt;</code> element MUST be present in the response.</p>
+<p><a name="request"></a></p>
+<h5 id="2243-request">2.2.4.3. Request</h5>
+<p>The <code>&lt;Request&gt;</code> element MAY be present in a response. However, it is RECOMMENDED not to include this
+element since it makes the response message unnecessary large, instead the requester of a sign operation
+is expected to save the request message in its session for later use when processing a response message.</p>
+<p><a name="signerassertioninfo"></a></p>
+<h5 id="2244-signerassertioninfo">2.2.4.4. SignerAssertionInfo</h5>
+<p>The <code>&lt;SignerAssertionInfo&gt;</code> element MUST be present if the signer
+has been successfully authenticated using the specified Identity
+Provider. The present <code>&lt;ContextInfo&gt;</code> child element MUST include an
+<code>&lt;AssertionRef&gt;</code> child element. The <code>&lt;AssertionRef&gt;</code> child
+element MUST contain the value of the <code>ID</code> attribute of the root element
+of the SAML assertion used to authenticate the signer.</p>
+<p><a name="signaturecertificatechain"></a></p>
+<h5 id="2245-signaturecertificatechain">2.2.4.5. SignatureCertificateChain</h5>
+<p>The <code>&lt;SignatureCertificateChain&gt;</code> element MUST be present if a
+certificate was issued to the signer. This element MUST provide a
+complete chain of certificates up to a self-signed root certificate.</p>
+<p>All signature values according to section <a href="#generated-signature">2.2.3</a> MUST be verifiable using
+the signer certificate provided in this element.</p>
+<p><a name="http-post-binding"></a></p>
+<h2 id="3-http-post-binding">3. HTTP POST Binding</h2>
+<p>This section specifies the protocol binding
+for transport of sign request and sign response messages using HTTP POST. This
+protocol binding implements the message exchange model in section <a href="#message-exchange-model">3.1</a>.</p>
+<p>This process is technically equivalent to the procedures implemented by
+SAML HTTP POST bindings [<a href="#saml2bind">SAML2Bind</a>], section 3.5.</p>
+<p><a name="message-exchange-model"></a></p>
+<h3 id="31-message-exchange-model">3.1. Message Exchange Model</h3>
+<p>Sign request and response messages are exchanged between the Requesting
+Service and the Signing Service with the user acting as an intermediary
+through a user agent (typically a web browser) according to the
+following message flow:</p>
+<p><img src="img/dssprof-msg-exch-model.png"></img></p>
+<ol class="list">
+<li><p>The user agent initiates the signing process by an HTTP request to
+ the Service Provider, for example caused by the user clicking a
+ button on a web page.</p>
+</li>
+<li><p>The Service Provider responds to the user agent with an XHTML form,
+ containing a Base64 encoded sign request.</p>
+</li>
+<li><p>A JavaScript in the XHTML form causes the user agent to send the
+ sign request to the Signing Service using HTTP POST.</p>
+</li>
+<li><p>The user interacts with the Signing Service to complete the
+ requested signature.</p>
+</li>
+<li><p>The Signing Service responds to the user agent with an XHTML form,
+ containing a Base64 encoded sign response.</p>
+</li>
+<li><p>A JavaScript in the XHTML form causes the user agent to send the
+ sign response to the Service Provider using HTTP POST.</p>
+</li>
+<li><p>The Service Provider processes the sign response and a confirmation
+ or status message is returned to the user agent.</p>
+</li>
+</ol>
+<p>The steps 1,4 and 7 are part of the service infrastructure and are
+outside the scope of this HTTP POST binding specification.</p>
+<p><a name="sign-request-xhtml-form"></a></p>
+<h4 id="311-sign-request-xhtml-form">3.1.1. Sign Request XHTML Form</h4>
+<p>The sign request XHTML form SHALL have functional properties that are
+equivalent to the following implementation example:</p>
+<pre class="hljs"><code><span class="hljs-meta">&lt;?xml version=&#x27;1.0&#x27; encoding=&#x27;UTF-8&#x27;?&gt;</span>
+<span class="hljs-meta">&lt;!DOCTYPE <span class="hljs-meta-keyword">html</span> <span class="hljs-meta-keyword">PUBLIC</span> <span class="hljs-meta-string">&#x27;-//W3C//DTD XHTML 1.1//EN&#x27;</span> <span class="hljs-meta-string">&#x27;http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd&#x27;</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">html</span> <span class="hljs-attr">xmlns</span>=<span class="hljs-string">&#x27;http://www.w3.org/1999/xhtml&#x27;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&#x27;en&#x27;</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">body</span> <span class="hljs-attr">onload</span>=<span class="hljs-string">&#x27;document.forms[0].submit()&#x27;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">noscript</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">p</span>&gt;</span><span class="hljs-tag">&lt;<span class="hljs-name">strong</span>&gt;</span>Note:<span class="hljs-tag">&lt;/<span class="hljs-name">strong</span>&gt;</span> Since your browser does not support JavaScript,
+    you must press the Continue button once to proceed.<span class="hljs-tag">&lt;/<span class="hljs-name">p</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">noscript</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">form</span> <span class="hljs-attr">action</span>=<span class="hljs-string">&#x27;https://csig.example.com/signrequest&#x27;</span> <span class="hljs-attr">method</span>=<span class="hljs-string">&#x27;post&#x27;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">div</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;Binding&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;POST/XML/1.0&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;RelayState&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;56345145a482995d&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;EidSignRequest&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;PD94bWw…WVzdD4=&#x27;</span>/&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">div</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">noscript</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">div</span>&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;submit&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;Continue&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;/<span class="hljs-name">div</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">noscript</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">form</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">body</span>&gt;</span></code></pre><p>The form’s action attribute specifies the URL to the Signing Service and
+the form MUST have a method attribute with the value “post”.</p>
+<p>The form MUST provide the following parameters:</p>
+<table>
+<thead>
+<tr>
+<th>Parameter</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Binding</td>
+<td>“POST/XML/1.0” Identifying implementation of this binding specification</td>
+</tr>
+<tr>
+<td>RelayState</td>
+<td>This parameter MUST contain the value of the <code>RequestID</code> attribute of the <code>&lt;dss:SignRequest&gt;</code> element that is present in the base64 encoded sign request.</td>
+</tr>
+<tr>
+<td>EidSignRequest</td>
+<td>Base64 encoded sign request.</td>
+</tr>
+</tbody></table>
+<p><a name="sign-response-xhtml-form"></a></p>
+<h5 id="312-sign-response-xhtml-form">3.1.2. Sign Response XHTML Form</h5>
+<p>The sign response XHTML form SHALL have functional properties that are
+equivalent to the following implementation example:</p>
+<pre class="hljs"><code><span class="hljs-meta">&lt;?xml version=&#x27;1.0&#x27; encoding=&#x27;UTF-8&#x27;?&gt;</span>
+<span class="hljs-meta">&lt;!DOCTYPE <span class="hljs-meta-keyword">html</span> <span class="hljs-meta-keyword">PUBLIC</span> <span class="hljs-meta-string">&#x27;-//W3C//DTD XHTML 1.1//EN&#x27;</span> <span class="hljs-meta-string">&#x27;http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd&#x27;</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">html</span> <span class="hljs-attr">xmlns</span>=<span class="hljs-string">&#x27;http://www.w3.org/1999/xhtml&#x27;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&#x27;en&#x27;</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">body</span> <span class="hljs-attr">onload</span>=<span class="hljs-string">&#x27;document.forms[0].submit()&#x27;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">noscript</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">p</span>&gt;</span><span class="hljs-tag">&lt;<span class="hljs-name">strong</span>&gt;</span>Note:<span class="hljs-tag">&lt;/<span class="hljs-name">strong</span>&gt;</span> Since your browser does not support JavaScript,
+    you must press the Continue button once to proceed.<span class="hljs-tag">&lt;/<span class="hljs-name">p</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">noscript</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">form</span> <span class="hljs-attr">action</span>=<span class="hljs-string">&#x27;https://sp.example.com/sigResponseHandler&#x27;</span> <span class="hljs-attr">method</span>=<span class="hljs-string">&#x27;post&#x27;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">div</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;Binding&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;POST/XML/1.0&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;RelayState&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;56345145a482995d&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;hidden&#x27;</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&#x27;EidSignResponse&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;PD94bWw…WVzdD4=&#x27;</span>/&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">div</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">noscript</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">div</span>&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&#x27;submit&#x27;</span> <span class="hljs-attr">value</span>=<span class="hljs-string">&#x27;Continue&#x27;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;/<span class="hljs-name">div</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">noscript</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">form</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">body</span>&gt;</span></code></pre><p>The form’s action attribute specifies the URL to the requesting Service
+Provider. This URL MUST specify a URL from the
+<code>&lt;saml:AudienceRestriction&gt;</code> element that was provided in the
+corresponding sign request. The form MUST have a method attribute with
+the value “post”.</p>
+<p>The form MUST provide the following parameters:</p>
+<table>
+<thead>
+<tr>
+<th>Parameter</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Binding</td>
+<td>“POST/XML/1.0” Identifying implementation of this binding specification</td>
+</tr>
+<tr>
+<td>RelayState</td>
+<td>This parameter MUST contain the value of the <code>RequestID</code> attribute of the <code>&lt;dss:SignResponse&gt;</code> element that is present in the base64 encoded sign request.</td>
+</tr>
+<tr>
+<td>EidSignResponse</td>
+<td>Base64 encoded sign response.</td>
+</tr>
+</tbody></table>
+<p><a name="references"></a></p>
+<h2 id="4-references">4. References</h2>
+<p><a name="normative-references"></a></p>
+<h3 id="41-normative-references">4.1. Normative References</h3>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="dss"></a>
+<strong>[DSS]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html">OASIS Standard - Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0, April 11, 2007</a>.</p>
+</blockquote>
+<p><a name="saml-xsd"></a>
+<strong>[SAML-XSD]</strong></p>
+<blockquote>
+<p>S. Cantor et al., SAML assertions schema. OASIS SSTC, March 2005. Document ID: saml-schema-assertion-2.0. See <a href="http://www.oasisopen.org/committees/security/">http://www.oasisopen.org/committees/security/</a>.</p>
+</blockquote>
+<p><a name="xmlsig"></a>
+<strong>[XMLSig]</strong></p>
+<blockquote>
+<p>D. Eastlake et al, <a href="https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">XML-Signature Syntax and Processing, W3C Recommendation, February 2002</a>.</p>
+</blockquote>
+<p><a name="xmlsig-xsd"></a>
+<strong>[XMLSig-XSD]</strong></p>
+<blockquote>
+<p>XML Signature Schema. World Wide Web Consortium. See <a href="https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd</a>.</p>
+</blockquote>
+<p><a name="dss-ext"></a>
+<strong>[DSS-Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
+</blockquote>
+<p><a name="informative-references"></a></p>
+<h3 id="42-informative-references">4.2. Informative References</h3>
+<p><a name="saml2bind"></a>
+<strong>[SAML2Bind]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf">OASIS Standard, Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, March 2005</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="5-changes-between-versions">5. Changes between versions</h2>
+<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
+<ul class="list">
+<li><p>Section 2.2.2, &quot;Sign Response Status Information&quot;, now defines the DSS status codes previously only appearing in [<a href="#sc-registry">SC.Registry</a>]. The status codes <code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code> and <code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code> were also introduced.</p>
+</li>
+<li><p>Section 2.1.3.2, &quot;Conditions&quot;, was updated with requirements on how to interpret <code>NotBefore</code> and/or <code>NotOnOrAfter</code> values.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
+<ul class="list">
+<li><p>The requirements in section 2.2.4.3, &quot;Request&quot;, were updated. The <code>Request</code> element is no longer mandatory to include in a response message.</p>
+</li>
+<li><p>Sections 2.1.3.1 and 2.2.4.1 defining the requirements concerning the use of the <code>Version</code> attribute in <code>SignRequestExtension</code> and <code>SignResponseExtension</code> elements were updated in order to implement support for newer versions of the DSS extension specification.</p>
+</li>
+<li><p>Section 2.1.3.3, &quot;Signer&quot;, was updated so that it is no longer required to supply the <code>&lt;csig:Signer&gt;</code> element. This enables use cases where the user is not known at the time of signature initiation.  </p>
+</li>
+</ul>
+<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
+<ul class="list">
+<li><p>Updates of references and change of logotype.</p>
+</li>
+<li><p>Updates to section 2.1.3.8.2, &quot;Requesting Identity Provider to Display SignMessage&quot;, with a more simple
+process of determining the Level of Assurance URI to include in requests.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
+<ul class="list">
+<li>In section 2.1.3.9, &quot;CertRequestProperties&quot;, a requirement to adapt authentication request procedures when the requested signature is a qualified electronic signature was added.</li>
+</ul>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li>In section 2.2.2, a reference to section 3.1.5 in [SC.Registry] was changed to section 3.1.7.</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li><p>This profile now refers to version 1.1 of the “DSS Extensions for
+  Federated Central Signing Services” specification.</p>
+</li>
+<li><p>Changes were made to section 2.1.3.8, “SignMessage”, in order to
+  define usage of the <code>&lt;SignMessage&gt;</code> element.</p>
+</li>
+<li><p>The URI identifier that identifies this profile has been changed
+  from <code>http://id.elegnamnden.se/csig/1.0/eid2-dss/profile</code> to
+  <code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code>.</p>
+</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html b/docs/december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html
new file mode 100644
index 0000000..8ee4f82
--- /dev/null
+++ b/docs/december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html
@@ -0,0 +1,350 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Certificate Profile for Certificates Issued by Central Signing Services</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="certificate-profile-for-certificates-issued-by-central-signing-services">Certificate Profile for Certificates Issued by Central Signing Services</h1>
+<h3 id="version-12---2020-01-17">Version 1.2 - 2020-01-17</h3>
+<p>Registration number: <strong>2019-313</strong> (<em>previously: ELN-0608</em>)</p>
+<hr>
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirement-key-words">Requirement key words</a></p>
+<p> 1.2. <a href="#xml-namespace-references">XML namespace references</a></p>
+<p> 1.3. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#certificate-profile"><strong>Certificate Profile</strong></a></p>
+<p> 2.1. <a href="#standards">Standards</a></p>
+<p> 2.2. <a href="#qualified-and-pkc-certificates">Qualified and PKC Certificates</a></p>
+<p> 2.3. <a href="#certificate-content">Certificate Content</a></p>
+<p> 2.3.1. <a href="#subject-attributes-and-name-forms">Subject Attributes and Name Forms</a></p>
+<p> 2.3.1.1. <a href="#person-identifier-attributes">Person Identifier Attributes</a></p>
+<p> 2.3.1.1.1. <a href="#data-source">Data Source</a></p>
+<p> 2.3.1.1.2. <a href="#data-format">Data Format</a></p>
+<p> 2.3.1.2. <a href="#other-attribute-requirements">Other Attribute Requirements</a></p>
+<p> 2.3.2. <a href="#authentication-context-and-attribute-mapping">Authentication Context and Attribute Mapping</a></p>
+<p> 2.3.2.1. <a href="#extended-authentication-information">Extended Authentication Information</a></p>
+<p> 2.3.3. <a href="#certificate-policy">Certificate Policy</a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This document specifies a certificate profile for certificates issued by
+a signature service based on the OASIS DSS protocol [<a href="#dss">DSS</a>], enhanced by
+the DSS Extensions for Federated Central Signing Services [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p><a name="requirement-key-words"></a></p>
+<h3 id="11-requirement-key-words">1.1. Requirement key words</h3>
+<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
+<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
+[<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations. When these words are
+not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="xml-namespace-references"></a></p>
+<h3 id="12-xml-namespace-references">1.2. XML namespace references</h3>
+<p>The prefix <strong>saci:</strong> stands for the SAML Authentication Context Information XML Schema 
+namespace, <code>http://id.elegnamnden.se/auth-cont/1.0/saci</code>.</p>
+<blockquote>
+<p>Schema location URL: <a href="https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-SAML-1.0.xsd">https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-SAML-1.0.xsd</a></p>
+</blockquote>
+<p>The prefix <strong>sacex:</strong> stands for the Extended Authentication Information XML Schema
+namespace, <code>http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info</code>.</p>
+<blockquote>
+<p>Schema location URL: <a href="https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-ExtAuthInfo-1.0.xsd">https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-ExtAuthInfo-1.0.xsd</a></p>
+</blockquote>
+<p><a name="structure"></a></p>
+<h3 id="13-structure">1.3. Structure</h3>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;Eid2Element&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
+<code>OtherCode</code>.</p>
+<p><a name="certificate-profile"></a></p>
+<h2 id="2-certificate-profile">2. Certificate Profile</h2>
+<p><a name="standards"></a></p>
+<h3 id="21-standards">2.1. Standards</h3>
+<p>The following standards provides normative requirements for this
+certificate profile:</p>
+<table>
+<thead>
+<tr>
+<th>Standard</th>
+<th>Function</th>
+<th>Reference</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>RFC 5280</td>
+<td>Main certificate standard</td>
+<td>[<a href="#rfc5280">RFC5280</a>]</td>
+</tr>
+<tr>
+<td>RFC 7773</td>
+<td>Authentication context extension</td>
+<td>[<a href="#rfc7773">RFC7773</a>]</td>
+</tr>
+<tr>
+<td>EN 319 411-1</td>
+<td>Policy requirements for PKC certificates</td>
+<td>[<a href="#eu-pol-ncp">EU-POL-NCP</a>]</td>
+</tr>
+<tr>
+<td>EN 319 411-2</td>
+<td>Policy requirements for Qualified certificates</td>
+<td>[<a href="#eu-pol-qc">EU-POL-QC</a>]</td>
+</tr>
+<tr>
+<td>EN 319 412-1</td>
+<td>Definitions of semantic identifies and formatting rules for identity data</td>
+<td>[<a href="#eu-cert-gen">EU-CERT-GEN</a>]</td>
+</tr>
+<tr>
+<td>EN 319 412-2</td>
+<td>Certificate profile for certificates issued to natural persons</td>
+<td>[<a href="#eu-cert-np">EU-CERT-NP</a>]</td>
+</tr>
+<tr>
+<td>EN 319 412-5</td>
+<td>Declaration of qualified certificate properties</td>
+<td>[<a href="#eu-cert-qc">EU-CERT-QC</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="qualified-and-pkc-certificates"></a></p>
+<h3 id="22-qualified-and-pkc-certificates">2.2. Qualified and PKC Certificates</h3>
+<p>This profile supports both Qualified Certificates as well as certificates that are not Qualified Certificates, here named PKC certificates (Public Key Certificates).</p>
+<p>All profile requirements apply to both Qualified Certificates and to PKC certificates unless it is explicitly stated that a particular requirement applies only to PKC or Qualified Certificates.</p>
+<p><a name="certificate-content"></a></p>
+<h3 id="23-certificate-content">2.3. Certificate Content</h3>
+<p>All certificates SHALL be fully compliant with  [<a href="#rfc5280">RFC5280</a>] and [<a href="#en-cert-np">EU-CERT-NP</a>]. All Qualified Certificates SHALL also implement mandatory QC statements as defined in [<a href="#eu-cert-qc">EU-CERT-QC</a>].</p>
+<p><a name="subject-attributes-and-name-forms"></a></p>
+<h4 id="231-subject-attributes-and-name-forms">2.3.1. Subject Attributes and Name Forms</h4>
+<p><a name="person-identifier-attributes"></a></p>
+<h5 id="2311-person-identifier-attributes">2.3.1.1. Person Identifier Attributes</h5>
+<p><a name="data-source"></a></p>
+<h6 id="23111-data-source">2.3.1.1.1. Data Source</h6>
+<p>All certificates SHALL contain a unique person identifier, carried in the <code>serialNumber</code> attribute (OID 2.5.4.5) in the subject field. The person identifier SHALL be obtained from the Identity Provider in the form of a SAML attribute. For PKC certificates, the SAML attribute SHOULD be one of the attributes listed below. For Qualified Certificates, the SAML attribute SHALL be one of the attributes listed below.</p>
+<table>
+<thead>
+<tr>
+<th>Attribute</th>
+<th>Attribute name</th>
+<th>Specification</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Swedish Personal Identity Number (personnummer)</td>
+<td>urn:oid:1.2.752.29.4.13</td>
+<td>[<a href="#attrspec">AttrSpec</a>]</td>
+</tr>
+<tr>
+<td>Provisional ID</td>
+<td>urn:oid:1.2.752.201.3.4</td>
+<td>[<a href="#attrspec">AttrSpec</a>]</td>
+</tr>
+<tr>
+<td>eIDAS Person Identifier</td>
+<td>urn:oid:1.2.752.201.3.7</td>
+<td>[<a href="#attrspec">AttrSpec</a>]</td>
+</tr>
+</tbody></table>
+<p><a name="data-format"></a></p>
+<h6 id="23111-data-format">2.3.1.1.1. Data Format</h6>
+<p>The identifier data obtained from the SAML assertion SHALL be stored in the <code>serialNumber</code> attribute using one of the following formats:</p>
+<ul class="list">
+<li>using exactly the same format as it was obtained from the SAML attribute, or,</li>
+<li>using conventions specified in [<a href="#eu-cert-gen">EU-CERT-GEN</a>] as defined below.</li>
+</ul>
+<p>When storing a person identifier in the <code>serialNumber</code> attribute in accordance with [<a href="#eu-cert-gen">EU-CERT-GEN</a>], the certificate SHALL include a semantics identifier as specified in section 5.1 of  [<a href="#eu-cert-gen">EU-CERT-GEN</a>].</p>
+<p><strong>Swedish Personal Identity Number (personnummer)</strong></p>
+<p>When the identifier is a Swedish personal identity number (personnummer) the semantics identifier SHALL be a natural person semantics identifier using the identity type reference &quot;PNO&quot;.</p>
+<blockquote>
+<p>Example: PNOSE-194911172296</p>
+</blockquote>
+<p><strong>Provisional ID</strong></p>
+<p>When the identifier is a provisional ID the semantics identifier SHALL be a natural person semantics identifier using a local national identity type reference &quot;PI:SE&quot;.</p>
+<blockquote>
+<p>Example: PI:SE-NO:16043700158</p>
+</blockquote>
+<p>This identifier illustrates that the identifier is a Provisional ID (PI) as defined in Sweden (SE) followed by a hyphen (-) and the actual provisional ID for a person from Norway (NO:16043700158).</p>
+<p>When the identity type reference is &quot;PI:SE&quot;, the <code>nameRegistrationAuthorities</code> element of SemanticsInformation shall be present and shall contain a <code>uniformResourceIdentifier</code> <code>generalName</code> with the following value:</p>
+<blockquote>
+<p><code>http://id.elegnamnden.se/eln/name-registration-authority</code></p>
+</blockquote>
+<p><strong>eIDAS Person Identifier</strong></p>
+<p>eIDAS person identifier attributes MAY be stored in the serial number attribute having exactly the same format as received from the SAML attribute listed above, supported by providing a semantics identifier according to [<a href="#eu-cert-gen">EU-CERT-GEN</a>] identified by the OID <code>0.4.0.194121.1.3</code>.</p>
+<p><strong>NOTE:</strong></p>
+<blockquote>
+<p>A new version of the [<a href="#eu-cert-gen">EU-CERT-GEN</a>] is processed for approval at the time of publication of this document. The new version will specify a semantics identifier for storing eIDAS person identifier attributes using the semantics identifier OID <code>0.4.0.194121.1.3</code>. This semantics identifier (<code>id-etsi-qcs-semanticsId-eIDASNatural</code>) is not yet present in the latest published version of the standard.</p>
+</blockquote>
+<p><a name="other-attribute-requirements"></a></p>
+<h5 id="2312-other-attribute-requirements">2.3.1.2. Other Attribute Requirements</h5>
+<p>An e-mail address, when present, SHALL be stored in a Subject Alternative Name extension as an rfc822Name.</p>
+<p><a name="authentication-context-and-attribute-mapping"></a></p>
+<h4 id="232-authentication-context-and-attribute-mapping">2.3.2. Authentication Context and Attribute Mapping</h4>
+<p>Certificates MUST include an <code>AuthContextExtension</code> according to [<a href="#rfc7773">RFC7773</a>]. This extension SHALL include one SAML Authentication Context Information element identified by the XML schema namespace identifier:</p>
+<blockquote>
+<p><code>http://id.elegnamnden.se/auth-cont/1.0/saci</code></p>
+</blockquote>
+<p>The <code>&lt;saci:SAMLAuthContext&gt;</code> element SHALL contain both an <code>&lt;saci:AuthContextInfo&gt;</code> element as well as an <code>&lt;saci:IdAttributes&gt;</code> element.</p>
+<p>The <code>&lt;saci:IdAttributes&gt;</code> element SHALL contain one <code>&lt;saci:AttributeMapping&gt;</code> element for each 
+subject attribute or other name form that was obtained from a SAML attribute in the SAML 
+assertion used to authenticate the signer as part of the signature creation process. Each
+<code>&lt;saci:AttributeMapping&gt;</code> element SHALL provide the <code>&lt;saml:AttributeValue&gt;</code> that were obtained from
+the SAML assertion.</p>
+<p><a name="extended-authentication-information"></a></p>
+<h5 id="2321-extended-authentication-information">2.3.2.1. Extended Authentication Information</h5>
+<p>In addition to the attributes of <code>&lt;saci:AuthContextInfo&gt;</code> it is possible to provide additional authentication information through the extensibility of the <code>&lt;saci:AuthContextInfo&gt;</code> element which allows inclusion of a sequence of any element.</p>
+<p>One such element is defined in this section, the <code>&lt;sacex:ExtAuthInfo&gt;</code> element.</p>
+<p>This element MAY be included to provide a name of a parameter and its associated value. </p>
+<p>This element MAY be used to carry the value of any single valued attribute from the associated SAML assertion as long as the SAML attribute value is not composed of a complex type. When used to carry a SAML attribute value, the value of the <code>&lt;sacex:ExtAuthInfo&gt;</code> element SHALL be identical to the content of the SAML attribute value element and the <code>Name</code> attribute SHALL hold the same value as the <code>Name</code> attribute of the corresponding SAML attribute.</p>
+<p>The <code>&lt;sacex:ExtAuthInfo&gt;</code> element is defined by the following XML Schema:</p>
+<pre class="hljs"><code><span class="hljs-meta">&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">xs:schema</span> <span class="hljs-attr">xmlns:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> <span class="hljs-attr">elementFormDefault</span>=<span class="hljs-string">&quot;qualified&quot;</span>
+    <span class="hljs-attr">targetNamespace</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>
+    <span class="hljs-attr">xmlns:sacex</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>&gt;</span>
+    
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:element</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;ExtAuthInfo&quot;</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&quot;sacex:ExtAuthInfoType&quot;</span> /&gt;</span>
+
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:complexType</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;ExtAuthInfoType&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">xs:extension</span> <span class="hljs-attr">base</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">xs:attribute</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;required&quot;</span> /&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">xs:anyAttribute</span> <span class="hljs-attr">namespace</span>=<span class="hljs-string">&quot;##any&quot;</span> <span class="hljs-attr">processContents</span>=<span class="hljs-string">&quot;lax&quot;</span> /&gt;</span>
+      <span class="hljs-tag">&lt;/<span class="hljs-name">xs:extension</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">xs:complexType</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">xs:schema</span>&gt;</span></code></pre><p><strong>Example:</strong></p>
+<p>The following example illustrates inclusion of the content of a transaction identifier SAML 
+attribute as extended authentication information.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saci:SAMLAuthContext</span>
+    <span class="hljs-attr">xmlns:saci</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/auth-cont/1.0/saci&quot;</span>
+    <span class="hljs-attr">xmlns:sacext</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saci:AuthContextInfo</span> <span class="hljs-attr">IdentityProvider</span>=<span class="hljs-string">&quot;http://eid.example.com/idp&quot;</span>
+      <span class="hljs-attr">AuthenticationInstant</span>=<span class="hljs-string">&quot;2020-01-10T17:02:46.000Z&quot;</span>
+      <span class="hljs-attr">AuthnContextClassRef</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/loa/1.0/loa3&quot;</span>
+      <span class="hljs-attr">AssertionRef</span>=<span class="hljs-string">&quot;_936e075dc2725b016de57b9a0624c766&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">sacext:ExtAuthInfo</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.2&quot;</span>&gt;</span>dc6ac7656H89bfb51<span class="hljs-tag">&lt;/<span class="hljs-name">sacext:ExtAuthInfo</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">saci:AuthContextInfo</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saci:IdAttributes</span>&gt;</span>...<span class="hljs-tag">&lt;/<span class="hljs-name">saci:IdAttributes</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saci:SAMLAuthContext</span>&gt;</span></code></pre><p><a name="certificate-policy"></a></p>
+<h4 id="233-certificate-policy">2.3.3. Certificate Policy</h4>
+<p>Certificates SHALL contain at least one referenced certificate policy. PKC certificates SHALL contain at least one reference to a policy identified in [<a href="#eu-pol-ncp">EU-POL-NCP</a>]. Qualified Certificates SHALL reference at least one certificate policy identified in [<a href="#eu-pol-qc">EU-POL-QC</a>].</p>
+<p><a name="normative-references"></a></p>
+<h2 id="3-normative-references">3. Normative References</h2>
+<p><a name="dss"></a>
+<strong>[DSS]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html">OASIS Standard - Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0, April 11, 2007</a>.</p>
+</blockquote>
+<p><a name="dss-ext"></a>
+<strong>[DSS-Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="attrspec"></a>
+<strong>[AttrSpec]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework.</a></p>
+</blockquote>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="rfc3739"></a>
+<strong>[RFC3739]</strong></p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc3739.txt">Santesson, S., Nystrom, M., and T. Polk, &quot;Internet X.509 Public Key
+Infrastructure: Qualified Certificates Profile&quot;, RFC 3739, March
+2004</a>.</p>
+</blockquote>
+<p><a name="rfc5280"></a>
+<strong>[RFC5280]</strong></p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc5280.txt">Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and
+W. Polk, &quot;Internet X.509 Public Key Infrastructure Certificate and
+Certificate Revocation List (CRL) Profile&quot;, RFC 5280, May 2008</a>.</p>
+</blockquote>
+<p><a name="rfc7773"></a>
+<strong>[RFC7773]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7773">RFC-7773: Authentication Context Certificate Extension</a></p>
+</blockquote>
+<p><a name="eu-pol-ncp"></a>
+<strong>[EU-POL-NCP]</strong></p>
+<blockquote>
+<p>ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements.</p>
+</blockquote>
+<p><a name="eu-pol-ncp"></a>
+<strong>[EU-POL-QC]</strong></p>
+<blockquote>
+<p>ETSI EN 319 411-2, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates</p>
+</blockquote>
+<p><a name="eu-cert-gen"></a>
+<strong>[EU-CERT-GEN]</strong></p>
+<blockquote>
+<p>ETSI EN 319 412-1, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures.</p>
+</blockquote>
+<p><a name="eu-cert-np"></a>
+<strong>[EU-CERT-NP]</strong></p>
+<blockquote>
+<p>ETSI EN 319 412-2, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons.</p>
+</blockquote>
+<p><a name="eu-cert-qc"></a>
+<strong>[EU-CERT-QC]</strong></p>
+<blockquote>
+<p>ETSI EN 319 412-5, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements.</p>
+</blockquote>
+<p><a name="skv704"></a>
+<strong>[SKV704]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv704-8.pdf">Skatteverket, SKV 704 utgåva 8, Personnummer, September
+2007</a>.</p>
+</blockquote>
+<p><a name="skv707"></a>
+<strong>[SKV707]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf">Skatteverket, SKV 707, Utgåva 2,
+Samordningsnummer</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="4-changes-between-versions">4. Changes between versions</h2>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li><p>Update of logotype, fixes of typos and reference list.</p>
+</li>
+<li><p>Section 2.3.2.1, &quot;Extended Authentication Information&quot;, was added.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li>Removed the requirement to store &quot;personnummer&quot; or &quot;samordningsnummer&quot;.</li>
+<li>Updated standards references to remove old deprecated standards and replace them with the currently published documents.</li>
+<li>Specified optional support for using semantics identifiers in accordance with ETSI EN 319 412-1 to specify that the serialNumber attribute contains a Swedish &quot;personnummer&quot; or &quot;samordningsnummer&quot;, Provisional ID or eIDAS person identifier.</li>
+<li>Added requirement to specify ETSI policy identifiers.</li>
+<li>Fix of invalid links for SKV704 and SKV707.</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html b/docs/december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html
new file mode 100644
index 0000000..ec4276d
--- /dev/null
+++ b/docs/december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html
@@ -0,0 +1,1668 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>DSS Extension for Federated Central Signing Services</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="dss-extension-for-federated-central-signing-services">DSS Extension for Federated Central Signing Services</h1>
+<h3 id="version-15---2024-12-04">Version 1.5 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-314</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#terminology">Terminology</a></p>
+<p> 1.1.1. <a href="#keywords">Keywords</a></p>
+<p> 1.1.2. <a href="#structure">Structure</a></p>
+<p> 1.1.3. <a href="#definitions">Definitions</a></p>
+<p> 1.2. <a href="#schema-organization-and-namespaces">Schema Organization and Namespaces</a></p>
+<p> 1.3. <a href="#common-data-types">Common Data Types</a></p>
+<p> 1.3.1. <a href="#string-values">String values</a></p>
+<p> 1.3.2. <a href="#uri-values">URI Values</a></p>
+<p> 1.3.3. <a href="#time-values">Time Values</a></p>
+<p> 1.3.4. <a href="#mime-types-for-dsstransformeddata">MIME Types for &lt;dss:TransformedData&gt;</a></p>
+</li>
+<li><p><a href="#common-protocol-structures"><strong>Common Protocol Structures</strong></a></p>
+<p> 2.1. <a href="#type-anytype">Type AnyType</a></p>
+</li>
+<li><p><a href="#federated-signing-dss-extensions"><strong>Federated Signing DSS Extensions</strong></a></p>
+<p> 3.1. <a href="#element-signrequestextension">Element &lt;SignRequestExtension&gt;</a></p>
+<p> 3.1.1. <a href="#type-certrequestpropertiestype">Type CertRequestPropertiesType</a></p>
+<p> 3.1.1.1. <a href="#type-requestedattributestype">Type RequestedAttributesType</a></p>
+<p> 3.1.2. <a href="#element-signmessage">Element &lt;SignMessage&gt;</a></p>
+<p> 3.2. <a href="#element-signresponseextension">Element &lt;SignResponseExtension&gt;</a></p>
+<p> 3.2.1. <a href="#type-signerassertioninfotype">Type SignerAssertionInfoType</a></p>
+<p> 3.2.1.1. <a href="#type-contextinfotype">Type ContextInfoType</a></p>
+<p> 3.2.1.2. <a href="#type-samlassertionstype">Type SAMLAssertionsType</a></p>
+<p> 3.2.2. <a href="#type-certificatechaintype">Type CertificateChainType</a></p>
+</li>
+<li><p><a href="#extensions-to-dssinputdocuments-and-dsssignatureobject"><strong>Extensions to &lt;dss:InputDocuments&gt; and &lt;dss:SignatureObject&gt;</strong></a></p>
+<p> 4.1. <a href="#element-signtasks">Element &lt;SignTasks&gt;</a></p>
+<p> 4.1.1. <a href="#element-signtaskdata">Element &lt;SignTaskData&gt;</a></p>
+<p> 4.1.1.1. <a href="#type-adesobjecttype">Type AdESObjectType</a></p>
+</li>
+<li><p><a href="#signing-sign-requests-and-responses"><strong>Signing Sign Requests and Responses</strong></a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p>Appendix A. <a href="#appendix-a.xml-schema"><strong>XML Schema</strong></a></p>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This specification defines elements that extend the
+<code>&lt;dss:SignRequest&gt;</code> and <code>&lt;dss:SignResponse&gt;</code> elements of
+[<a href="#dss">OASIS-DSS</a>].</p>
+<p>One element <code>&lt;SignRequestExtension&gt;</code> is defined for extending sign
+requests and one element <code>&lt;SignResponseExtension&gt;</code> is defined for
+extending sign responses. The <code>&lt;SignTasks&gt;</code> element extends the
+<code>&lt;dss:InputDocuments&gt;</code> element of sign requests and
+<code>&lt;dss:SignatureObject&gt;</code> element of sign responses.</p>
+<p>These extensions to the DSS protocols provide essential protocol
+elements in a scenario where:</p>
+<ul class="list">
+<li><p>The user&#39;s signature is requested by a service with which the user
+  has an active session and where this service has authenticated the
+  user using a SAML assertion.</p>
+</li>
+<li><p>  The service provider holds the data to be signed.</p>
+</li>
+<li><p>The central signing service is requested to authenticate the user
+  with the same Identity Provider that was used to authenticate the
+  user to the Service Provider.</p>
+</li>
+</ul>
+<p>This particular use case is relevant when a user logs in to a service
+using a federated identity, where the user at some point is required to
+sign some data such as a tax declaration or payment transaction. The
+user is forwarded to the signing service together with a sign request
+from the Service Provider, specifying the information to be signed
+together with the conditions for signing. After completed signing, the
+user is returned to the Service Provider together with a sign response
+from which the Service Provider can assemble a complete signed document,
+signed by the user.</p>
+<p>This scenario requires more information in both sign requests and sign
+responses than the original DSS core standard provides, and it also
+requires the capability to let the service provider sign the sign
+request.</p>
+<p><a name="terminology"></a></p>
+<h3 id="11-terminology">1.1. Terminology</h3>
+<p><a name="keywords"></a></p>
+<h4 id="111--keywords">1.1.1.  Keywords</h4>
+<p>The keywords <em>MUST</em>, <em>MUST NOT</em>, <em>REQUIRED</em>, <em>SHALL</em>, <em>SHALL NOT</em>,
+<em>SHOULD</em>, <em>SHOULD NOT</em>, <em>RECOMMENDED</em>, <em>MAY</em>, and <em>OPTIONAL</em> are to be
+interpreted as described in [<a href="#rfc2119">RFC 2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations.</p>
+<p>When these words are not capitalized, they are meant in their
+natural-language sense.</p>
+<p><a name="structure"></a></p>
+<h4 id="112-structure">1.1.2. Structure</h4>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;ThisSpecifictionElements&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, Attribute,
+<strong>Datatype</strong>, OtherCode.</p>
+<p>Listings of DSS schemas appear like this.</p>
+<p><a name="definitions"></a></p>
+<h4 id="113-definitions">1.1.3. Definitions</h4>
+<p><strong>Identity Provider</strong></p>
+<blockquote>
+<p>An Identity Provider that is assigned to authenticate the signer.</p>
+</blockquote>
+<p><strong>Signing Service</strong></p>
+<blockquote>
+<p>A Signing Service that receives sign requests and responds with sign
+responses according to this specification.</p>
+</blockquote>
+<p><strong>Service Provider</strong></p>
+<blockquote>
+<p>A service that has identified the signer through the user&#39;s Identity
+Provider and requests that the signer signs some data using the
+Central Signing Service.</p>
+</blockquote>
+<p><a name="schema-organization-and-namespaces"></a></p>
+<h3 id="12-schema-organization-and-namespaces">1.2. Schema Organization and Namespaces</h3>
+<p>The structures described in this specification are contained in the XML
+schema for this protocol [<a href="#csig-xsd">Csig-XSD</a>]. All schema
+listings in the current document are excerpts from the complete XML
+schema. </p>
+<p>This schema is associated with the following XML namespace:</p>
+<p><code>http://id.elegnamnden.se/csig/1.1/dss-ext/ns</code></p>
+<p>Compliance with this specification requires support of the latest version of 
+the [<a href="#csig-xsd">Csig-XSD</a>] schema which is 1.1.3.</p>
+<p>If a future, non backwards compatible, version of this specification is needed, it will use a
+different namespace.</p>
+<p>Conventional XML namespace prefixes are used in the schema:</p>
+<ul class="list">
+<li><p>The prefix <code>csig</code>: stands for this specification&#39;s XML schema
+  namespace [<a href="#csig-xsd">Csig-XSD</a>].</p>
+</li>
+<li><p>The prefix <code>dss</code>: stands for the DSS core namespace
+  [<a href="#dss">OASIS-DSS</a>].</p>
+</li>
+<li><p>The prefix <code>ds</code>: stands for the W3C XML Signature namespace
+  [<a href="#xmldsig">XMLDSIG</a>].</p>
+</li>
+<li><p>The prefix <code>xs</code>: stands for the W3C XML Schema namespace
+  [<a href="#schema1">Schema1</a>].</p>
+</li>
+<li><p>The prefix <code>saml</code>: stands for the OASIS SAML Schema namespace
+  [<a href="#saml">SAML2.0</a>].</p>
+</li>
+<li><p>The prefix <code>xades</code>: stands for the ETSI XAdES Schema namespace
+  [<a href="#xades">XAdES</a>].</p>
+</li>
+</ul>
+<p>Applications MAY use different namespace prefixes, and MAY use whatever
+namespace defaulting/scoping conventions they desire, as long as they
+are compliant with the Namespaces in XML specification
+[<a href="#xml-ns">XML-ns</a>].</p>
+<p>The following schema fragment defines the XML namespaces and other
+header information for this specification&#39;s core XML schema:</p>
+<pre class="hljs"><code>&lt;xs:schema xmlns:<span class="hljs-attribute">xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> 
+    <span class="hljs-attribute">elementFormDefault</span>=<span class="hljs-string">&quot;qualified&quot;</span>
+    xmlns:<span class="hljs-attribute">ds</span>=<span class="hljs-string">&quot;http://www.w3.org/2000/09/xmldsig#&quot;</span>
+    <span class="hljs-attribute">targetNamespace</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/dss-ext/ns&quot;</span>
+    xmlns:<span class="hljs-attribute">saml</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>
+    xmlns:<span class="hljs-attribute">xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
+    xmlns:<span class="hljs-attribute">dss</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:dss:1.0:core:schema&quot;</span>
+    xmlns:<span class="hljs-attribute">csig</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/dss-ext/ns&quot;</span>&gt;
+    &lt;xs:import <span class="hljs-attribute">namespace</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>
+        <span class="hljs-attribute">schemaLocation</span>=<span class="hljs-string">&quot;saml-schema-assertion-2.0.xsd&quot;</span>/&gt;</code></pre><p><a name="common-data-types"></a></p>
+<h3 id="13-common-data-types">1.3. Common Data Types</h3>
+<p>The following sections define how to use and interpret common data types
+that appear throughout the specification.</p>
+<p><a name="string-values"></a></p>
+<h4 id="131-string-values">1.3.1. String values</h4>
+<p>All string values have the type <strong>xs:string</strong>, which is built in to the
+W3C XML Schema Datatypes specification [<a href="#schema2">Schema2</a>]. Unless
+otherwise noted in this specification or particular profiles, all
+strings in this specification MUST consist of at least one
+non-whitespace character (whitespace is defined in the XML
+Recommendation [<a href="#xml">XML</a>] Section 2.3).</p>
+<p>Unless otherwise noted in this specification, all elements that have the
+XML Schema <strong>xs:string</strong> type, or a type derived from that, MUST be
+compared using an exact binary comparison. In particular,
+implementations MUST NOT depend on case-insensitive string comparisons,
+normalization or trimming of whitespace, or conversion of
+locale-specific formats such as numbers or currency. This requirement is
+intended to conform to the W3C working group note &quot;Requirements for String
+Identity, Matching, and String Indexing&quot; [<a href="https://www.w3.org/TR/charreq/">W3C-CHAR</a>].</p>
+<p><a name="uri-values"></a></p>
+<h4 id="132-uri-values">1.3.2. URI Values</h4>
+<p>All SAML URI reference values have the type <strong>xs:anyURI</strong>, which is
+built in to the W3C XML Schema Datatypes specification
+[<a href="#schema2">Schema2</a>].</p>
+<p>Unless otherwise indicated in this specification, all URI reference
+values used within defined elements or attributes MUST consist of at
+least one non-whitespace character, and are REQUIRED to be absolute
+[<a href="#rfc3986">RFC 3986</a>].</p>
+<p>Note that this specification makes use of URI references as identifiers,
+such as status codes, format types, attribute and system entity names,
+etc. In such cases, it is essential that the values be both unique and
+consistent, such that the same URI is never used at different times to
+represent different underlying information.</p>
+<p><a name="time-values"></a></p>
+<h4 id="133-time-values">1.3.3. Time Values</h4>
+<p>All time values have the type <strong>xs:dateTime</strong>, which is built in to the
+W3C XML Schema Datatypes specification [<a href="#schema2">Schema2</a>], and
+MUST be expressed in UTC form, with no time zone component.</p>
+<p>Implementations SHOULD NOT rely on time resolution finer than
+milliseconds. Implementations MUST NOT generate time instants that
+specify leap seconds.</p>
+<p><a name="mime-types-for-dsstransformeddata"></a></p>
+<h4 id="134-mime-types-for-dsstransformeddata">1.3.4. MIME Types for &lt;dss:TransformedData&gt;</h4>
+<p>The following MIME type is defined for transformed data included in a
+<code>&lt;dss:Base64Data&gt;</code> element within a <code>&lt;dss:TransformedData&gt;</code>
+element in a <code>&lt;dss:SignRequest&gt;</code>.</p>
+<p><strong>application/cms-signed-attributes</strong></p>
+<blockquote>
+<p>This MIME type identifies that the data contained in the
+<code>&lt;dss:Base64Data&gt;</code> element, is a DER encoded CMS signed attributes
+structure [<a href="#rfc5652">RFC 5652</a>]. This data is useful when signing
+a PDF document in cases where the whole PDF document is not included
+in the request. The signature on a PDF document is generated by
+signing the hash of a CMS signed attributes structure representing the
+PDF document to be signed. These signed attributes include data that
+a Signing Service may want to check before signing, such as the
+claimed signing time.</p>
+</blockquote>
+<p><a name="common-protocol-structures"></a></p>
+<h2 id="2-common-protocol-structures">2. Common Protocol Structures</h2>
+<p>The following sections describe XML structures and types that are used
+in multiple places.</p>
+<p><a name="type-anytype"></a></p>
+<h3 id="21-type-anytype">2.1. Type AnyType</h3>
+<p>The <strong>AnyType</strong> complex type allows arbitrary XML element content within
+an element of this type (see section 3.2.1 Element Content
+[<a href="#xml">XML</a>]).</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">xs:complexType</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;AnyType&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:sequence</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">xs:any</span> <span class="hljs-attr">processContents</span>=<span class="hljs-string">&quot;lax&quot;</span> <span class="hljs-attr">minOccurs</span>=<span class="hljs-string">&quot;0&quot;</span> <span class="hljs-attr">maxOccurs</span>=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">xs:sequence</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">xs:complexType</span>&gt;</span></code></pre><p><a name="federated-signing-dss-extensions"></a></p>
+<h2 id="3-federated-signing-dss-extensions">3. Federated Signing DSS Extensions</h2>
+<p>This section defines elements that extend the <code>&lt;dss:SignRequest&gt;</code>
+and <code>&lt;dss:SignResponse&gt;</code> elements of the DSS Signing Protocol.</p>
+<p><a name="element-signrequestextension"></a></p>
+<h3 id="31-element-signrequestextension">3.1. Element &lt;SignRequestExtension&gt;</h3>
+<p>The <code>&lt;SignRequestExtension&gt;</code> element allows a requesting service to
+add essential sign request information to a DSS Sign request. When
+present, this element MUST be included in the <code>&lt;dss:OptionalInputs&gt;</code>
+element in a DSS Sign Request. This element&#39;s
+<strong>SignRequestExtensionType</strong> complex type includes the following
+attributes and elements:</p>
+<p><code>Version</code> [Optional] (Default <code>1.1</code>)</p>
+<blockquote>
+<p>The version of this specification supported by the sender. If absent, 
+the version value defaults to &quot;1.1&quot;. </p>
+</blockquote>
+<blockquote>
+<p>This attribute provides means for the receiving
+service to determine the expected semantics of the request based on the
+protocol version. </p>
+</blockquote>
+<blockquote>
+<p>The receiving service MUST use the same version
+in the resulting response, see <a href="#element-signresponseextension">section 3.2</a>.
+If the receiving service does not support the requested version, the service 
+MUST refuse to process the request and respond with an error message where 
+<code>&lt;dss:ResultMajor&gt;</code> is set to <code>urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError</code>
+and the <code>&lt;dss:ResultMinor&gt;</code> is set to <code>urn:oasis:names:tc:dss:1.0:resultminor:NotSupported</code>.</p>
+</blockquote>
+<p><code>&lt;RequestTime&gt;</code> [Required]</p>
+<blockquote>
+<p>The time when this request was created.</p>
+</blockquote>
+<p><code>&lt;saml:Conditions&gt;</code> [Required]</p>
+<blockquote>
+<p>This element MUST include the element <code>&lt;saml:AudienceRestriction&gt;</code> which in
+turn MUST contain one <code>&lt;saml:Audience&gt;</code> element, specifying the return URL for
+any resulting Sign Response message.</p>
+</blockquote>
+<p><code>&lt;Signer&gt;</code> [Optional]</p>
+<blockquote>
+<p>The identity of the signer expressed as a sequence of SAML attributes
+using the <strong>saml:AttributeStatementType</strong> complex type. If this
+element is present, then the Signing Service MUST verify that the
+authenticated identity of the signer is consistent with the attributes
+in this element.</p>
+</blockquote>
+<p><code>&lt;IdentityProvider&gt;</code> [Required]</p>
+<blockquote>
+<p>The SAML entityID of the Identity Provider that MUST be used to
+authenticate the signer before signing. The entitID value is specified
+using the <strong>saml:NameIDType</strong> complex type and MUST include a <code>Format</code>
+attribute with the value
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</code>.</p>
+</blockquote>
+<p><code>&lt;AuthnProfile&gt;</code> [Optional]</p>
+<blockquote>
+<p>An opaque string that can be used to inform the Signing Service about specific
+requirements regarding the user authentication at the given Identity Provider (see above).
+This specification does not define any possible values or semantics for the element.</p>
+</blockquote>
+<blockquote>
+<p><strong>Note:</strong> If this element is set, the <code>Version</code> attribute of the <code>SignRequestExtension</code> element MUST be set to &quot;1.4&quot; or higher. Implementations prior to version 1.4 of this specification do not support the element.</p>
+</blockquote>
+<p><code>&lt;SignRequester&gt;</code> [Required]</p>
+<blockquote>
+<p>The SAML entityID of the service that sends this request to the
+Signing Service. The entityID value is specified using the
+<strong>saml:NameIDType</strong> complex type and MUST include a <code>Format</code> attribute
+with the value <code>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</code>.</p>
+</blockquote>
+<p><code>&lt;SignService&gt;</code> [Required]</p>
+<blockquote>
+<p>The SAML entityID of the service to which this Sign Request is sent.
+The entityID value is specified using the <strong>saml:NameIDType</strong> complex
+type and MUST include a <code>Format</code> attribute with the value
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</code>.</p>
+</blockquote>
+<p><code>&lt;RequestedSignatureAlgorithm&gt;</code> [Optional]</p>
+<blockquote>
+<p>An identifier of the signature algorithm the requesting service
+prefers when generating the requested signature.</p>
+</blockquote>
+<p><code>&lt;SignMessage&gt;</code> [Optional]</p>
+<blockquote>
+<p>Optional sign message with information to the signer about the
+requested signature.</p>
+</blockquote>
+<p><code>&lt;CertRequestProperties&gt;</code> [Optional]</p>
+<blockquote>
+<p>An optional set of requested properties of the signature certificate
+that is generated as part of the signature process.</p>
+</blockquote>
+<p><code>&lt;OtherRequestInfo&gt;</code> [Optional]</p>
+<blockquote>
+<p>Any additional inputs to the request extension.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;SignRequestExtension&gt;</code>
+element and its <strong>SignRequestExtensionType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;xs:element <span class="hljs-type">name</span>=&quot;SignRequestExtension&quot; <span class="hljs-keyword">type</span>=&quot;csig:SignRequestExtensionType&quot; /&gt;
+
+&lt;xs:complexType <span class="hljs-type">name</span>=&quot;SignRequestExtensionType&quot;&gt;
+  &lt;xs:<span class="hljs-keyword">sequence</span>&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:RequestTime&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;saml:Conditions&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:Signer&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:IdentityProvider&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:AuthnProfile&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:SignRequester&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:SignService&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:RequestedSignatureAlgorithm&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:CertRequestProperties&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:SignMessage&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:OtherRequestInfo&quot; minOccurs=&quot;0&quot; /&gt;
+  &lt;/xs:<span class="hljs-keyword">sequence</span>&gt;
+  &lt;xs:<span class="hljs-keyword">attribute</span> <span class="hljs-type">name</span>=&quot;Version&quot; <span class="hljs-keyword">type</span>=&quot;xs:string&quot; use=&quot;optional&quot; default=&quot;1.1&quot; /&gt;
+&lt;/xs:complexType&gt;</code></pre><p><a name="type-certrequestpropertiestype"></a></p>
+<h4 id="311-type-certrequestpropertiestype">3.1.1. Type CertRequestPropertiesType</h4>
+<p>The <strong>CertRequestPropertiesType</strong> complex type is used to specify
+requested properties of the signature certificate that is associated
+with the generated signature.</p>
+<p>The <strong>CertRequestPropertiesType</strong> complex type has the following
+attributes and elements:</p>
+<p><code>CertType</code> [Default &quot;PKC&quot;]</p>
+<blockquote>
+<p>An enumeration of certificate types, default &quot;PKC&quot;. The supported
+values are &quot;PKC&quot;, &quot;QC&quot; and &quot;QC/SSCD&quot;. &quot;QC&quot; means that the certificate
+is requested to be a Qualified Certificate according to legal
+definitions in national law governing the issuer. &quot;QC/SSCD&quot; means a
+Qualified Certificate where the private key is declared to be residing
+within a Secure Signature Creation Device according to national law.
+&quot;PKC&quot; (Public Key Certificate) means a certificate that is not a
+Qualified Certificate.</p>
+</blockquote>
+<p><code>&lt;saml:AuthnContextClassRef&gt;</code> [Optional]</p>
+<blockquote>
+<p>URI(s) identifying the requested level of assurance that authentication
+of the signature certificate subject MUST comply with in order to
+complete signing and certificate issuance. A Signing Service MUST NOT
+issue signature certificates and generate the requested signature
+unless the authentication process used to authenticate the requested
+signer meets one of the requested level of assurance URI:s expressed 
+in this element. </p>
+<p>If this element is absent, the locally configured policy of
+the Signing Service is assumed. This can either mean that the Signing Service
+includes one or more locally configured URI:s in the <code>saml:RequestedAuthnContext</code> element
+of the <code>saml:AuthnRequest</code> issued to authenticate the user, or that no 
+<code>saml:RequestedAuthnContext</code> element is included in the <code>saml:AuthnRequest</code>.
+In the latter case the Signature Service puts no requirements on the
+required level of assurance.</p>
+</blockquote>
+<blockquote>
+<p><strong>Note:</strong> If more than one URI is given, the <code>Version</code> attribute of the <code>SignRequestExtension</code> element MUST be set to &quot;1.4&quot; or higher. Implementations prior to version 1.4 of this specification assume that this element may only contain one URI.</p>
+</blockquote>
+<p><code>&lt;RequestedCertAttributes&gt;</code> [Optional]</p>
+<blockquote>
+<p>Element holding a SAML entity ID of an Attribute Authority that MAY be
+used to obtain an attribute value for the requested attribute. The
+entityID value is specified using the <strong>saml:NameIDType</strong> complex type
+and MUST include a Format attribute with the value
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</code>.</p>
+</blockquote>
+<p><code>&lt;OtherProperties&gt;</code> [Optional]</p>
+<blockquote>
+<p>Other requested properties of the signature certificate.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>CertRequestPropertiesType</strong>
+complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;CertRequestPropertiesType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AuthnContextClassRef&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:RequestedCertAttributes&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherProperties&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> default=<span class="hljs-string">&quot;PKC&quot;</span> name=<span class="hljs-string">&quot;CertType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;PKC&quot;</span>/&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;QC&quot;</span>/&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;QC/SSCD&quot;</span>/&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedCertAttributes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:RequestedAttributesType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherProperties&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> /&gt;</code></pre><p><a name="type-requestedattributestype"></a></p>
+<h5 id="3111-type-requestedattributestype">3.1.1.1. Type RequestedAttributesType</h5>
+<p>The <strong>RequestedAttributesType</strong> complex type is used to represent
+requests for subject attributes in a signer certificate that is
+associated with the signer of the generated signature as a result of the
+sign request. This protocol is designed to accommodate the scenario
+where the Signing Service generates the signer key and the signer
+certificate at the time of signing and where the Signing Service
+collects the user&#39;s attributes from a SAML assertion. However, this
+element can also be used as a requirement for attributes in existing
+certificates, where the Signing Service can determine if the existing
+signing certificate matches the requirements of the requesting service.</p>
+<p>The <strong>RequestedAttributesType</strong> has the following element:</p>
+<p><code>&lt;RequestedCertAttribute&gt;</code> [One or More]</p>
+<blockquote>
+<p>Information of type <strong>MappedAttributeType</strong> about a requested
+certificate attribute.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>RequestedAttributesType</strong>
+complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedAttributesType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedCertAttribute&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:MappedAttributeType&quot;</span> 
+      maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p>The <strong>MappedAttributeType</strong> complex type has the following elements and
+attributes:</p>
+<p><code>CertAttributeRef</code> [Optional]</p>
+<blockquote>
+<p>A reference to the certificate attribute or name type where the
+requester wants to store this attribute value. The information in this
+attribute depends on the selected <code>CertNameType</code> attribute value. If the
+<code>CertNameType</code> is &quot;<strong>rdn</strong>&quot; or &quot;<strong>sda</strong>&quot;, then this attribute MUST
+contain a string representation of an object identifier (OID). If the
+<code>CertNameType</code> is &quot;<strong>san</strong>&quot; (Subject Alternative Name) and the target
+name is a GeneralName, then this attribute MUST hold a string
+representation of the tag value of the target GeneralName type, e.g.
+&quot;1&quot; for rfc822Name (e-mail) or &quot;2&quot; for dNSName. If the <code>CertNameType</code> is
+&quot;<strong>san</strong>&quot; and the target name form is an OtherName, then this
+attribute value MUST include a string representation of the object
+identifier of the target OtherName form.</p>
+<p>Representation of an OID as a string in this attribute MUST consist of
+a sequence of integers delimited by a dot. This string MUST not
+contain white space or line breaks. Example: &quot;2.5.4.32&quot;.</p>
+</blockquote>
+<p><code>CertNameType</code> [Optional]</p>
+<blockquote>
+<p>An enumeration of the target name form for storing the associated SAML
+attribute value in the certificate. The available values are &quot;rdn&quot; for
+storing the attribute value as an attribute in a Relative
+Distinguished Name in the subject field of the certificate, &quot;san&quot; for
+storing the attribute value in a subject alternative name extension
+and &quot;sda&quot; for storing the attribute value in a subject directory
+attribute extension. The default value for this attribute is &quot;rdn&quot;.</p>
+</blockquote>
+<p><code>FriendlyName</code> [Optional]</p>
+<blockquote>
+<p>An optional friendly name of the subject attribute, e.g. &quot;givenName&quot;.
+Note that this name does not need to map to any particular naming
+convention and its value MUST NOT be used by the Signing Service for
+attribute type mapping. This name is present for display purposes
+only.</p>
+</blockquote>
+<p><code>DefaultValue</code> [Optional]</p>
+<blockquote>
+<p>An optional default value for the requested attribute. This value MAY
+be used by the Signing Service if no authoritative value for the
+attribute can be obtained when the Signing Service authenticates the
+user. This value MUST NOT be used by the Signing Service unless this
+value is consistent with a defined policy at the Signing Service. A
+typical valid use of this attribute is to hold a default countryName
+attribute value that matches a set of allowed countryName values. By
+accepting the default attribute value provided in this attribute, the
+Signing Service accept the requesting service as an authoritative
+source for this particular requested attribute.</p>
+</blockquote>
+<p><code>Required</code> [Optional] (Default <code>false</code>)</p>
+<blockquote>
+<p>If this attribute is set to true, the Signing Service MUST ensure that
+the signing certificate contains a subject attribute of the requested
+type, or else the Signing Service MUST NOT generate the requested
+signature.</p>
+</blockquote>
+<p><code>&lt;AttributeAuthority&gt;</code> [Zero or More]</p>
+<blockquote>
+<p>Element holding an entityID of an Attribute Authority that MAY be
+used to obtain an attribute value for the requested attribute. The
+entityID value is specified using the <strong>saml:NameIDType</strong> complex type
+and MUST include a <code>Format</code> attribute with the value
+<code>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</code>.</p>
+</blockquote>
+<p><code>&lt;SamlAttributeName&gt;</code> [Zero or More]</p>
+<blockquote>
+<p>Element of type <strong>PreferredSAMLAttributeNameType</strong> complex type
+holding a name of a SAML subject attribute that is allowed to provide
+the content value for the requested certificate attribute.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>MappedAttributeType</strong>
+complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MappedAttributeType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AttributeAuthority&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span>
+      maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SamlAttributeName&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:PreferredSAMLAttributeNameType&quot;</span>
+      maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;CertAttributeRef&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;CertNameType&quot;</span> default=<span class="hljs-string">&quot;rdn&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;rdn&quot;</span>/&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;san&quot;</span>/&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;sda&quot;</span>/&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;FriendlyName&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;DefaultValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Required&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:boolean&quot;</span> default=<span class="hljs-string">&quot;false&quot;</span> /&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p>The <strong>PreferredSAMLAttributeNameType</strong> complex type holds a string value
+of a SAML attribute name. This attribute name SHALL be mapped against
+attribute names in <code>&lt;saml:Attribute&gt;</code> elements representing the
+subject in a SAML assertion that is used to authenticate the signer.</p>
+<p>The <strong>PreferredSAMLAttributeNameType</strong> complex type has the following
+attribute:</p>
+<p><code>Order</code> [Optional]</p>
+<blockquote>
+<p>An integer specifying the order of preference of this SAML attribute.
+If more than one SAML attribute is listed, the SAML attribute with the
+lowest <code>Order</code> integer value that is present as a subject attribute in
+the SAML assertion, SHALL be used. SAML attributes with an absent
+<code>Order</code> attribute SHALL be treated as having an order value of 0.
+Multiple SAML attributes with an identical <code>Order</code> attribute values
+SHALL be treated as having equal priority.</p>
+</blockquote>
+<p>The following schema fragment defines the
+<strong>PreferredSAMLAttributeNameType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PreferredSAMLAttributeNameType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Order&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:int&quot;</span> default=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="element-signmessage"></a></p>
+<h4 id="312-element-signmessage">3.1.2. Element &lt;SignMessage&gt;</h4>
+<p>The <code>&lt;SignMessage&gt;</code> element holds a message to the signer with
+information about what is being signed. The sign message is provided
+either in plain text using the <code>&lt;Message&gt;</code> child element or as an
+encrypted message using the <code>&lt;EncryptedMessage&gt;</code> child element. This
+element&#39;s <strong>SignMessageType</strong> complex type includes the following
+attributes and elements:</p>
+<p><code>MustShow</code> [Optional] (Default <code>false</code>)</p>
+<blockquote>
+<p>When this attribute is set to <code>true</code> then the requested signature MUST
+NOT be created unless this message has been displayed and accepted by
+the signer. The default is <code>false</code>.</p>
+</blockquote>
+<p><code>DisplayEntity</code> [Optional]</p>
+<blockquote>
+<p>The entityID of the entity responsible for displaying the sign message
+to the signer. When the sign message is encrypted, then this entity is
+also the holder of the private decryption key necessary to decrypt the
+sign message.</p>
+</blockquote>
+<p><code>MimeType</code> [Optional] (Default <code>text</code>)</p>
+<blockquote>
+<p>The MIME type defining the message format. This is an enumeration of
+the valid attribute values <code>text</code> (plain text), <code>text/html</code> (html) or
+<code>text/markdown</code> (markdown). This specification does not specify any
+particular restrictions on the provided message, but it is RECOMMENDED
+that sign message content is restricted to a limited set of valid tags
+and attributes, and that the display entity performs filtering to
+enforce these restrictions before displaying the message. The means
+through which parties agree on such restrictions are outside the scope
+of this specification, but one valid option to communicate such
+restrictions could be through federation metadata.</p>
+</blockquote>
+<p><code>&lt;Message&gt;</code> [Choice]</p>
+<blockquote>
+<p>The base64 encoded sign message in unencrypted form. The message MUST
+be encoded using UTF-8.</p>
+</blockquote>
+<p><code>&lt;EncryptedMessage&gt;</code> [Choice]</p>
+<blockquote>
+<p>An encrypted <code>&lt;Message&gt;</code> element. </p>
+</blockquote>
+<blockquote>
+<p>Either a <code>&lt;Message&gt;</code> or an <code>&lt;EncryptedMessage&gt;</code> element MUST be present.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;SignMessage&gt;</code> element
+and the <strong>SignMessageType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignMessageType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:choice</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Message&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:EncryptedMessage&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:choice</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;MustShow&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:boolean&quot;</span> default=<span class="hljs-string">&quot;false&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;DisplayEntity&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;MimeType&quot;</span> default=<span class="hljs-string">&quot;text&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text/html&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text/markdown&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##other&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span> /&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>/&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;EncryptedMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:EncryptedElementType&quot;</span>/&gt;</code></pre><p><a name="element-signresponseextension"></a></p>
+<h3 id="32-element-signresponseextension">3.2. Element &lt;SignResponseExtension&gt;</h3>
+<p>The <code>&lt;SignResponseExtension&gt;</code> element is an extension that
+allows a requesting service to add essential sign response information
+to the sign response. When present, this element MUST be included in the
+<code>&lt;dss:OptionalOutputs&gt;</code> element in a <code>&lt;dss:SignResponse&gt;</code>
+element.</p>
+<p>This element&#39;s <strong>SignResponseExtensionType</strong> complex type includes the
+following attributes and elements:</p>
+<p><code>Version</code> [Optional] (Default <code>1.1</code>)</p>
+<blockquote>
+<p>The version of this specification under which the response message was produced. 
+If absent, the version value
+defaults to &quot;1.1&quot;. This attribute provides means for the receiving
+service to determine the expected semantics of the response based on the
+protocol version.</p>
+</blockquote>
+<blockquote>
+<p><strong>Note:</strong> The sender MUST use the same version number as received in the <code>Version</code>
+attribute of the <code>SignRequestExtension</code> (see <a href="#element-signrequestextension">section 3.1</a>).</p>
+</blockquote>
+<p><code>&lt;ResponseTime&gt;</code> [Required]</p>
+<blockquote>
+<p>The time when the sign response was created.</p>
+</blockquote>
+<p><code>&lt;Request&gt;</code> [Optional]</p>
+<blockquote>
+<p>A base64 encoded signed <code>&lt;dss:SignRequest&gt;</code> element that contains
+the request related to this sign response. This element MAY be
+present if signing was successful.</p>
+</blockquote>
+<p><code>&lt;SignerAssertionInfo&gt;</code> [Optional]</p>
+<blockquote>
+<p>An element of type <strong>SignerAssertionInfoType</strong> holding information
+about how the signer was authenticated by the sign service as well as
+information about subject attribute values present in the SAML
+assertion authenticating the signer, which was incorporated into the
+signer certificate. This element MUST be present if signing was
+successful.</p>
+</blockquote>
+<p><code>&lt;SignatureCertificateChain&gt;</code> [Optional]</p>
+<blockquote>
+<p>An element of type <strong>CertificateChainType</strong> holding the signer
+certificate as well as other certificates that may be used to validate
+the signature. This element MUST be present if signing was successful
+and MUST contain all certificates that are necessary to compile a
+complete and functional signed document. Certificates in
+<code>&lt;SignatureCertificateChain&gt;</code> MUST be provided in sequence with
+the signature certificate first followed by any CA certificates that
+can be used to verify the previous certificate in the sequence, ending
+with a self-signed root certificate.</p>
+</blockquote>
+<p><code>&lt;OtherResponseInfo&gt;</code> [Optional]</p>
+<blockquote>
+<p>Optional sign response elements of type <strong>AnyType</strong>.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;SignResponseExtension&gt;</code>
+element and the <strong>SignResponseExtensionType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;xs:element <span class="hljs-type">name</span>=&quot;SignResponseExtension&quot; <span class="hljs-keyword">type</span>=&quot;csig:SignResponseExtensionType&quot; /&gt;
+
+&lt;xs:complexType <span class="hljs-type">name</span>=&quot;SignResponseExtensionType&quot;&gt;
+  &lt;xs:<span class="hljs-keyword">sequence</span>&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:ResponseTime&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:Request&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:SignerAssertionInfo&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:SignatureCertificateChain&quot; minOccurs=&quot;0&quot; /&gt;
+    &lt;xs:element <span class="hljs-keyword">ref</span>=&quot;csig:OtherResponseInfo&quot; minOccurs=&quot;0&quot; /&gt;
+  &lt;/xs:<span class="hljs-keyword">sequence</span>&gt;
+  &lt;xs:<span class="hljs-keyword">attribute</span> <span class="hljs-type">name</span>=&quot;Version&quot; <span class="hljs-keyword">type</span>=&quot;xs:string&quot; default=&quot;1.1&quot; /&gt;
+&lt;/xs:complexType&gt;
+
+&lt;xs:element <span class="hljs-type">name</span>=&quot;ResponseTime&quot; <span class="hljs-keyword">type</span>=&quot;xs:dateTime&quot; /&gt;
+&lt;xs:element <span class="hljs-type">name</span>=&quot;Request&quot; <span class="hljs-keyword">type</span>=&quot;xs:base64Binary&quot; /&gt;
+&lt;xs:element <span class="hljs-type">name</span>=&quot;SignerAssertionInfo&quot; <span class="hljs-keyword">type</span>=&quot;csig:SignerAssertionInfoType&quot; /&gt;
+&lt;xs:element <span class="hljs-type">name</span>=&quot;SignatureCertificateChain&quot; <span class="hljs-keyword">type</span>=&quot;csig:CertificateChainType&quot; /&gt;
+&lt;xs:element <span class="hljs-type">name</span>=&quot;OtherResponseInfo&quot; <span class="hljs-keyword">type</span>=&quot;csig:AnyType&quot; /&gt;</code></pre><p><a name="type-signerassertioninfotype"></a></p>
+<h4 id="321-type-signerassertioninfotype">3.2.1. Type SignerAssertionInfoType</h4>
+<p>The <strong>SignerAssertionInfoType</strong> complex type has the following elements:</p>
+<p><code>&lt;ContextInfo&gt;</code> [Required]</p>
+<blockquote>
+<p>This element of type <strong>ContextInfoType</strong> holds information about SAML
+authentication context related to signer authentication through a SAML
+assertion.</p>
+</blockquote>
+<p><code>&lt;saml:AttributeStatement&gt;</code> [Required]</p>
+<blockquote>
+<p>This element of type <strong>saml:AttributeStatementType</strong> (see
+[<a href="#saml">SAML2.0</a>]) holds subject attributes obtained from the
+SAML assertion used to authenticate the signer at the Signing Service.
+For integrity reasons, this element SHOULD only provide information
+about SAML attribute values that maps to subject identity information
+in the signer&#39;s certificate.</p>
+</blockquote>
+<p><code>&lt;SamlAssertions&gt;</code> [Zero or More]</p>
+<blockquote>
+<p>Any number of relevant SAML assertions that was relevant for
+authenticating the signer and signer&#39;s identity attributes at the
+Signing Service.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>SignerAssertionInfoType</strong>
+complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignerAssertionInfoType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:ContextInfo&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AttributeStatement&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SamlAssertions&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ContextInfo&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:ContextInfoType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SamlAssertions&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SAMLAssertionsType&quot;</span> /&gt;</code></pre><p><a name="type-contextinfotype"></a></p>
+<h5 id="3211-type-contextinfotype">3.2.1.1. Type ContextInfoType</h5>
+<p>The <strong>ContextInfoType</strong> complex type has the following elements:</p>
+<p><code>&lt;IdentityProvider&gt;</code>[Required]</p>
+<blockquote>
+<p>The entityID of the Identity Provider that authenticated the signer to
+the Signing Service.</p>
+</blockquote>
+<p><code>&lt;AuthenticationInstant&gt;</code> [Required]</p>
+<blockquote>
+<p>The time when the Signing Service authenticated the signer.</p>
+</blockquote>
+<p><code>&lt;saml:AuthnContextClassRef&gt;</code> [Required]</p>
+<blockquote>
+<p>A URI reference to the authentication context class (see
+[<a href="#saml">SAML2.0</a>]).</p>
+</blockquote>
+<p><code>&lt;ServiceID&gt;</code> [Optional]</p>
+<blockquote>
+<p>An arbitrary identifier of the instance of the Signing Service that
+authenticated the signer.</p>
+</blockquote>
+<p><code>&lt;AuthType&gt;</code> [Optional]</p>
+<blockquote>
+<p>An arbitrary identifier of the service used by the Signing Service to
+authenticate the signer (e.g. &quot;shibboleth&quot;.)</p>
+</blockquote>
+<p><code>&lt;AssertionRef&gt;</code> [Optional]</p>
+<blockquote>
+<p>A reference to the assertion used to identify the signer. This MAY be
+the ID attribute of a <code>&lt;saml:Assertion&gt;</code> element but MAY also be
+any other reference that can be used to locate and identify the
+assertion.</p>
+</blockquote>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;ContextInfoType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;IdentityProvider&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AuthenticationInstant&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:dateTime&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AuthnContextClassRef&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ServiceID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AuthType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AssertionRef&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="type-samlassertionstype"></a></p>
+<h5 id="3212-type-samlassertionstype">3.2.1.2. Type SAMLAssertionsType</h5>
+<p>The <strong>SAMLAssertionsType</strong> is used to store the bytes of an arbitrary
+number of SAML assertions (see [<a href="#saml">SAML2.0</a>]). This complex
+type has the following elements:</p>
+<p><code>&lt;Assertion&gt;</code>[One or More]</p>
+<blockquote>
+<p>One or more SAML assertions represented by the bytes of each
+assertion. Assertions are stored as byte data to ensure that the
+signature on each assertion can be validated. Assertions stored in
+this element MUST retain its original canonical format so that any
+signature on the assertion can be validated.</p>
+</blockquote>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SAMLAssertionsType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Assertion&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="type-certificatechaintype"></a></p>
+<h4 id="322-type-certificatechaintype">3.2.2. Type CertificateChainType</h4>
+<p>This complex type can be used to hold a sequence of X.509 certificates.
+Certificates MUST be provided in sequence with the end-entity
+certificate first in the sequence followed by any CA certificates that
+can be used to verify the previous certificate in the sequence, ending
+with a self-signed root certificate.</p>
+<p>The <strong>CertificateChainType</strong> complex type has the following elements:</p>
+<p><code>&lt;X509Certificate&gt;</code> [One or More]</p>
+<blockquote>
+<p>An X.509 certificate [<a href="#rfc5280">RFC 5280</a>] that is part of a
+certificate chain that can be used to verify the generated signature.
+The certificate SHALL be represented as a base64Binary of the DER
+encoded certificate.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>CertificateChainType</strong>
+complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;CertificateChainType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;X509Certificate&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="extensions-to-dssinputdocuments-and-dsssignatureobject"></a></p>
+<h2 id="4-extensions-to-dssinputdocuments-and-dsssignatureobject">4. Extensions to &lt;dss:InputDocuments&gt; and &lt;dss:SignatureObject&gt;</h2>
+<p>This section defines elements that extends the
+<code>&lt;dss:InputDocuments&gt;</code> element of DSS sign requests and the
+<code>&lt;dss:SignatureObject&gt;</code> element of DSS sign responses by inclusion
+in their respective <code>&lt;dss:Other&gt;</code> element.</p>
+<p><a name="element-signtasks"></a></p>
+<h3 id="41-element-signtasks">4.1. Element &lt;SignTasks&gt;</h3>
+<p>The <code>&lt;SignTasks&gt;</code> element, when present, MUST appear either in the
+<code>&lt;dss:Other&gt;</code> element of the <code>&lt;dss:InputDocuments&gt;</code> element of a
+sign request or in the <code>&lt;dss:Other&gt;</code> element of the
+<code>&lt;dss:SignatureObject&gt;</code> element of a sign response.</p>
+<p>This element holds information about sign tasks that are requested in a
+sign request and returned in a sign response. If information about a
+sign task is provided using this element in a sign request, then the
+corresponding signature result data MUST also be provided using this
+element in the sign response.</p>
+<p>This element&#39;s <strong>SignTasksType</strong> complex type includes the following
+attributes and elements:</p>
+<p><code>&lt;SignTaskData&gt;</code> [One or More]</p>
+<blockquote>
+<p>Input and output data associated with a sign task. A request MAY
+contain several instances of this element. When multiple instances of
+this element are present in the request, this means that the Signing
+Service is requested to generate multiple signatures (one for each
+<code>&lt;SignTaskData&gt;</code> element) using the same signing key and signature
+certificate. This allows batch signing of several different documents
+in the same signing instance or creation of multiple signatures on the
+same document such as signing XML content of a PDF document with an
+XML signature, while signing the rest of the document with a PDF
+signature.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;SignTasks&gt;</code> element and
+its <strong>SignTasksType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignTasks&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignTasksType&quot;</span> /&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignTasksType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignTaskData&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignTaskData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignTaskDataType&quot;</span> /&gt;</code></pre><p><a name="element-signtaskdata"></a></p>
+<h4 id="411-element-signtaskdata">4.1.1. Element &lt;SignTaskData&gt;</h4>
+<p>When present in a sign request, this element provides input data to a
+signature generation process. When present in a sign response, this
+element provides the corresponding signature result data. When a request
+provides input data using this type of element, then an element of this
+type MUST also be used to return the corresponding signature result
+data.</p>
+<p>This element&#39;s <strong>SignTaskDataType</strong> complex type includes the following
+attributes and elements:</p>
+<p><code>SignTaskId</code> [Optional]</p>
+<blockquote>
+<p>An identifier of the signature task that is represented by this
+element. If the request contains multiple instances of
+<code>&lt;SignTaskData&gt;</code> representing separate sign tasks, then each
+instance of the element MUST have a SignatureId attribute value that
+is unique among all sign tasks in the sign request. When this
+attribute is present, the same attribute value MUST be returned in the
+corresponding <code>&lt;SignTaskData&gt;</code> element in the response that holds
+corresponding signature result data.</p>
+</blockquote>
+<p><code>SigType</code> [Required]</p>
+<blockquote>
+<p>Enumerated identifier of the type of signature format the
+canonicalized signed information octets in the <code>&lt;ToBeSignedBytes&gt;</code>
+element are associated with. This MUST be one of the enumerated values
+&quot;XML&quot;, &quot;PDF&quot;, &quot;CMS&quot; of &quot;ASiC&quot;.</p>
+</blockquote>
+<p><code>AdESType</code> [Optional]</p>
+<blockquote>
+<p>Specifies the type of AdES signature. BES means that the signing
+certificate hash must be covered by the signature. EPES means that the
+signing certificate hash and a signature policy identifier must be
+covered by the signature.</p>
+</blockquote>
+<p><code>ProcessingRules</code> [Optional]</p>
+<blockquote>
+<p>A URI identifying one or more processing rules that the Signing
+Service MUST apply when processing and using the provided signed
+information octets. The Signing Service MUST NOT process and complete
+the signature request if this attribute contains a URI that is not
+recognized by the Signing Service. When this attribute is present in
+the sign response, it represents a statement by the Signing Service
+that the identified processing rule was successfully executed.</p>
+</blockquote>
+<p><code>&lt;ToBeSignedBytes&gt;</code> [Required]</p>
+<blockquote>
+<p>The bytes to be hashed and signed when generating the requested
+signature. For an XML signature this MUST be the canonicalized octets
+of a <code>&lt;dss:SignedInfo&gt;</code> element. For a PDF signature this MUST be
+the octets of the DER encoded SignedAttrs value (signed attributes).
+If this data was altered by the signature process, for example as a
+result of changing a signing time attribute in PDF SignedAttrs, or as
+a result of adding a reference to a hash of the signature certificate
+in an XAdES signature, the altered data MUST be returned in the sign
+response using this element.</p>
+</blockquote>
+<p><code>&lt;AdESObject&gt;</code> [Optional]</p>
+<blockquote>
+<p>An element of type <strong>AdESObjectType</strong> complex type holding data to
+support generation of a signature according to any of the ETSI
+Advanced Electronic Signature (AdES) standard formats.</p>
+</blockquote>
+<p><code>&lt;Base64Signature&gt;</code> [Optional]</p>
+<blockquote>
+<p>The output signature value of the signature creation process
+associated with this sign task. This element&#39;s optional <code>Type</code>
+attribute, if present, SHALL contain a URI indicating the signature
+algorithm that was used to generate the signature value.</p>
+</blockquote>
+<p><code>&lt;OtherSignTaskData&gt;</code> [Optional]</p>
+<blockquote>
+<p>Other input or output data elements associated with the sign task.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;SignTaskData&gt;</code> element
+and its <strong>SignTaskDataType</strong> complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignTaskData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignTaskDataType&quot;</span> /&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignTaskDataType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:ToBeSignedBytes&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:AdESObject&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Base64Signature&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherSignTaskData&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;SignTaskId&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;SigType&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;XML&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;PDF&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;CMS&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;ASiC&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;AdESType&quot;</span> default=<span class="hljs-string">&quot;None&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;None&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;BES&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;EPES&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;ProcessingRules&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span> /&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ToBeSignedBytes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AdESObject&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AdESObjectType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Base64Signature&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:Base64SignatureType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherSignTaskData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> /&gt;</code></pre><p><a name="type-adesobjecttype"></a></p>
+<h5 id="4111-type-adesobjecttype">4.1.1.1. Type AdESObjectType</h5>
+<p>The <strong>AdESObjectType</strong> complex type holds a base64 encoded object that
+is referenced from the signature and which content has to be modified as
+part of the certificate and signature generation process. Handling of
+this data as in the signature generation process MAY be affected by
+rules identifyed by the <code>ProcessingRules</code>, <code>SigType</code> and <code>AdESType</code> attributes
+of the parent <code>&lt;SignatureInputObjects&gt;</code> elements.</p>
+<p>This complex type has the following elements:</p>
+<p><code>&lt;SignatureId&gt;</code> [Optional]</p>
+<blockquote>
+<p>An optional identifier of the signature. When the requested signature
+is a XAdES signature, this is the value of the Id attribute of the
+<code>&lt;ds:Signature&gt;</code> element of the resulting signature, which is used
+to construct the <code>Target</code> attribute of the
+<code>&lt;xades:QualifyingProperties&gt;</code> element.</p>
+</blockquote>
+<p><code>&lt;AdESObjectBytes&gt;</code> [Optional]</p>
+<blockquote>
+<p>A base64 encoded object that is referenced from the signature and
+which content has to be modified as part of the certificate and
+signature generation process. The type of data in the base64 encoded
+bytes and the rules of handling of this data as in the signature
+generation process is determined through the <code>ProcessingRules</code>, <code>SigType</code>
+and <code>AdESType</code> attributes of the parent <code>&lt;SignatureInputObjects&gt;</code>
+elements. When the signature type is XAdES, then this is the bytes of
+the <code>&lt;ds:Object&gt;</code> element that holds the
+<code>&lt;xades:QualifyingProperties&gt;</code> element of the signature where the
+hash of the signature certificate will be placed.</p>
+<p>When this element is present in the request, it forms a base for
+construction of this object in the signature process.</p>
+</blockquote>
+<p><code>&lt;OtherAdESData&gt;</code> [Optional]</p>
+<blockquote>
+<p>Other input data related to the AdES signature generation process.</p>
+</blockquote>
+<p>The following schema fragment defines the <strong>AdESObjectType</strong> complex
+type</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;AdESObjectType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignatureId&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AdESObjectBytes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherAdESData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="signing-sign-requests-and-responses"></a></p>
+<h2 id="5-signing-sign-requests-and-responses">5. Signing Sign Requests and Responses</h2>
+<p>This specification supports a scenario where a requesting service
+requests the signer to sign some data and where the same requesting
+service receives the signature from the Signing Service. In this
+scenario the requesting service acts as the presenter of information to
+be signed to the signer. Implementers of this specification MUST sign
+requests and responses for signature creation to protect against
+spoofing and substitution attacks. If a hash of the document to be
+signed is replaced in a sign request, the signer may end up signing
+something completely different from what the requesting service
+presented to the signer.</p>
+<p>When a <code>&lt;dss:SignRequest&gt;</code> is signed, the signature of that request
+MUST be placed as the last child element in the
+<code>&lt;dss:OptionalInputs&gt;</code> element. The Signing Service MUST check this
+signature and MUST check that the signature covers all data in the
+<code>&lt;dss:SignRequest&gt;</code> element (except for the signature itself).</p>
+<p>When a <code>&lt;dss:SignResponse&gt;</code> is signed, the signature of that
+response MUST be placed as the last child element in the
+<code>&lt;dss:OptionalOutputs&gt;</code> element. The Signing Service MUST check this
+signature and MUST check that the signature covers all data in the
+<code>&lt;dss:SignResponse&gt;</code> element (except for the signature itself)</p>
+<p><a name="normative-references"></a></p>
+<h2 id="6-normative-references">6. Normative References</h2>
+<p><a name="csig-xsd"></a>
+<strong>[Csig-XSD]</strong></p>
+<blockquote>
+<p>This specification&#39;s DSS Extensions schema Version 1.1.3, <a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd</a>, November 2024.</p>
+</blockquote>
+<p><a name="dss"></a>
+<strong>[OASIS-DSS]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html">Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0, OASIS, 11 April 2007</a>.</p>
+</blockquote>
+<p><a name="rfc2119"></a>
+<strong>[RFC 2119]</strong></p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a>.</p>
+</blockquote>
+<p><a name="rfc3986"></a>
+<strong>[RFC 3986]</strong> </p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc3986.txt">RFC 3986: Uniform Resource Identifier (URI): Generic Syntax</a>.</p>
+</blockquote>
+<p><a name="rfc5652"></a>
+<strong>[RFC 5652]</strong> </p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc5652.txt">RFC 5652: Cryptographic Message Syntax (CMS)</a>.</p>
+</blockquote>
+<p><a name="rfc5280"></a>
+<strong>[RFC 5280]</strong> </p>
+<blockquote>
+<p><a href="https://www.ietf.org/rfc/rfc5280.txt">RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</a>.</p>
+</blockquote>
+<p><a name="saml"></a>
+<strong>[SAML2.0]</strong></p>
+<blockquote>
+<p><a href="https://docs.oasis-open.org/security/saml/v2.0/">Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0</a>.</p>
+</blockquote>
+<p><a name="schema1"></a>
+<strong>[Schema1]</strong> </p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/xmlschema-1/">XML Schema Part 1: Structures. W3C Recommendation 28 October 2004</a>.</p>
+</blockquote>
+<p><a name="schema2"></a>
+<strong>[Schema2]</strong> </p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/xmlschema-2/">XML Schema Part 2: Datatypes. W3C Recommendation 28 October 2004</a>.</p>
+</blockquote>
+<p><a name="xades"></a>
+<strong>[XAdES]</strong> </p>
+<blockquote>
+<p><a href="https://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf">XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures</a>.</p>
+</blockquote>
+<p><a name="xml"></a>
+<strong>[XML]</strong></p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/REC-xml/">Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C
+Recommendation 26 November 2008</a>.</p>
+</blockquote>
+<p><a name="xml-ns"></a>
+<strong>[XML-ns]</strong> </p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML. W3C Recommendation, January 1999</a>.</p>
+</blockquote>
+<p><a name="xmldsig"></a>
+<strong>[XMLDSIG]</strong></p>
+<blockquote>
+<p><a href="https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/">XML-Signature Syntax and Processing. W3C Recommendation, February 2002</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="7-changes-between-versions">7. Changes between versions</h2>
+<p><strong>Changes between version 1.4 and 1.5:</strong></p>
+<ul class="list">
+<li><p>The [<a href="#csig-xsd">Csig-XSD</a>] schema was updated to version 1.1.3.</p>
+</li>
+<li><p>In section 3.1, &quot;Element SignRequestExtension&quot;, the requirements for <code>NotBefore</code> and <code>NotOnOrAfter</code> to be present under the <code>&lt;saml:Conditions&gt;</code> element was removed. The reason for this is that it will always be the SignService itself that determines whether a message has expired or not.</p>
+</li>
+<li><p>Links in the appendix pointed to a draft version of the schema. This was fixed.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.3 and 1.4:</strong></p>
+<ul class="list">
+<li><p>In section 3.2, &quot;Element SignResponseExtension&quot;, the requirement for the <code>Request</code> element was changed so that it is optional to include even if the signature was successful.</p>
+</li>
+<li><p>Section 3.1, &quot;Element SignRequestExtension&quot;, was updated with the element <code>AuthnProfile</code>.</p>
+</li>
+<li><p>Section 3.1 and 3.2 was updated to clarify the use of the <code>Version</code> attribute in the <code>SignRequestExtension</code> and <code>SignResponseExtension</code> elements.</p>
+</li>
+<li><p>Section 3.1.1, &quot;Type CertRequestPropertiesType&quot;, was updated so that more than one <code>&lt;saml:AuthnContextClassRef&gt;</code> element can be included. The schema was also updated (to version 1.1.2 but keeping the same namespace identifier). </p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and 1.3:</strong></p>
+<ul class="list">
+<li>No functional changes. The document has been re-branded with the Sweden Connect- and DIGG logotypes and the document format has been changed from OASIS-style to the style used by all other specifications within the Swedish eID Framework. Some typos were also fixed.</li>
+</ul>
+<p><strong>Changes between version 1.1 and 1.2:</strong></p>
+<ul class="list">
+<li>Incorrect versions and references were corrected.</li>
+</ul>
+<p><strong>Changes between version 1.0 and 1.1:</strong></p>
+<ul class="list">
+<li>Version 1.1 of the XML Schema for DSS extensions was introduced.</li>
+</ul>
+<p><a name="appendix-a.xml-schema"></a></p>
+<h2 id="appendix-a-xml-schema">Appendix A: XML Schema</h2>
+<p>This appendix provides the full XML Schema declaration for the DSS
+protocol extension defined in this document. In case of differences
+between the XML Schema in this appendix and XML Schema fragments in the
+sections above, the XML Schema in this appendix is the normative one.</p>
+<p>The schema can also be downloaded from <a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.2.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.2.xsd</a>.</p>
+<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
+    <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.1.3&quot;</span>
+    xmln<span class="hljs-variable">s:ds</span>=<span class="hljs-string">&quot;http://www.w3.org/2000/09/xmldsig#&quot;</span>
+    targetNamespace=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/dss-ext/ns&quot;</span>
+    xmln<span class="hljs-variable">s:saml</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>
+    xmln<span class="hljs-variable">s:xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
+    xmln<span class="hljs-variable">s:dss</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:dss:1.0:core:schema&quot;</span>
+    xmln<span class="hljs-variable">s:csig</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/dss-ext/ns&quot;</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      Version: <span class="hljs-number">1.1</span>.<span class="hljs-number">3</span>
+      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/csig/<span class="hljs-number">1.1</span>/EidCentralSigDssExt-<span class="hljs-number">1.1</span>.<span class="hljs-number">3</span>.xsd
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:import</span> namespace=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:assertion&quot;</span>
+      schemaLocation=<span class="hljs-string">&quot;https://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd&quot;</span>/&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignRequestExtension&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignRequestExtensionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Extension <span class="hljs-keyword">to</span> <span class="hljs-keyword">an</span> OASIS DSS SignRequest, providing additional 
+        information about <span class="hljs-keyword">a</span> <span class="hljs-keyword">sign</span> request. This element extends the 
+        <span class="hljs-keyword">ds</span><span class="hljs-variable">s:OptionalInputs</span> element of <span class="hljs-keyword">a</span> <span class="hljs-keyword">ds</span><span class="hljs-variable">s:SignRequest</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignResponseExtension&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignResponseExtensionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Extension <span class="hljs-keyword">to</span> <span class="hljs-keyword">an</span> OASIS DSS SignResponse, providing additional information 
+        about <span class="hljs-keyword">a</span> <span class="hljs-keyword">sign</span> response. This element extends the <span class="hljs-keyword">ds</span><span class="hljs-variable">s:OptionalOutput</span> element 
+        of <span class="hljs-keyword">a</span> <span class="hljs-keyword">ds</span><span class="hljs-variable">s:SignResponse</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignTasks&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignTasksType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignTaskData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignTaskDataType&quot;</span> /&gt;
+    
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestTime&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:dateTime&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Time when the request was created.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Signer&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:AttributeStatementType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The identity of the signer expressed <span class="hljs-keyword">as</span> <span class="hljs-keyword">a</span> sequence of SAML attributes 
+        using the AttributesType complex <span class="hljs-built_in">type</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;IdentityProvider&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The SAML entityID of the Identity Provider that MUST <span class="hljs-keyword">be</span> used <span class="hljs-keyword">to</span> 
+        authenticate the signer before signing. The EntitID value <span class="hljs-keyword">is</span> specified 
+        using the sam<span class="hljs-variable">l:NameIDType</span> complex <span class="hljs-built_in">type</span> <span class="hljs-built_in">and</span> MUST include <span class="hljs-keyword">a</span> Format 
+        attribute with the value urn:oasi<span class="hljs-variable">s:names</span>:<span class="hljs-keyword">tc</span>:SAML:<span class="hljs-number">2.0</span>:nameid-forma<span class="hljs-variable">t:entity</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AuthnProfile&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An opaque <span class="hljs-built_in">string</span> that can <span class="hljs-keyword">be</span> used <span class="hljs-keyword">to</span> inform the Signing Service about 
+        specific requirements regarding the user authentication at the given 
+        Identity Provider.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignRequester&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The SAML entityID of the service that sends this request <span class="hljs-keyword">to</span> the signing service. 
+        The entityID value <span class="hljs-keyword">is</span> specified using the sam<span class="hljs-variable">l:NameIDType</span> complex <span class="hljs-built_in">type</span> <span class="hljs-built_in">and</span> MUST 
+        include <span class="hljs-keyword">a</span> Format attribute with the value 
+        urn:oasi<span class="hljs-variable">s:names</span>:<span class="hljs-keyword">tc</span>:SAML:<span class="hljs-number">2.0</span>:nameid-forma<span class="hljs-variable">t:entity</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignService&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The SAML entityID of the service <span class="hljs-keyword">to</span> which this Sign Request <span class="hljs-keyword">is</span> sent. 
+        The entityID value <span class="hljs-keyword">is</span> specified using the sam<span class="hljs-variable">l:NameIDType</span> complex <span class="hljs-built_in">type</span> 
+        <span class="hljs-built_in">and</span> MUST include <span class="hljs-keyword">a</span> Format attribute with the value 
+        urn:oasi<span class="hljs-variable">s:names</span>:<span class="hljs-keyword">tc</span>:SAML:<span class="hljs-number">2.0</span>:nameid-forma<span class="hljs-variable">t:entity</span>.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedSignatureAlgorithm&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An identifier of the signature algorithm the requesting service prefers 
+        when generating the requested signature.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;CertRequestProperties&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:CertRequestPropertiesType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The requested properties of the signature certificate being issued by the 
+        signature service.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedCertAttributes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:RequestedAttributesType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An optional <span class="hljs-keyword">set</span> of requested attributes that the requesting service prefers 
+        <span class="hljs-built_in">or</span> requires in the subject name of the generated signing certificate.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherProperties&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignMessageType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Sign message included <span class="hljs-keyword">as</span> <span class="hljs-keyword">a</span> choice of <span class="hljs-keyword">a</span> Base64 encoded <span class="hljs-built_in">string</span> <span class="hljs-built_in">or</span> 
+        <span class="hljs-keyword">an</span> encrypted <span class="hljs-keyword">sign</span> message.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> /&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;EncryptedMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:EncryptedElementType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherRequestInfo&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Any additional inputs <span class="hljs-keyword">to</span> the request extension.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ResponseTime&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:dateTime&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The time when the <span class="hljs-keyword">sign</span> response was created.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Request&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An element of <span class="hljs-built_in">type</span> EncodedRequestType with base64Binary base <span class="hljs-built_in">type</span>, holding 
+        <span class="hljs-keyword">a</span> representation of <span class="hljs-keyword">a</span> <span class="hljs-built_in">complete</span> <span class="hljs-built_in">and</span> signed <span class="hljs-keyword">ds</span><span class="hljs-variable">s:SignRequest</span> element that <span class="hljs-keyword">is</span> 
+        related <span class="hljs-keyword">to</span> this <span class="hljs-keyword">sign</span> response. This element MUST <span class="hljs-keyword">be</span> present <span class="hljs-keyword">if</span> signing was 
+        successful.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignerAssertionInfo&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SignerAssertionInfoType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An element of <span class="hljs-built_in">type</span> SignerAssertionInfoType holding information about how 
+        the signer was authenticated by the <span class="hljs-keyword">sign</span> service <span class="hljs-keyword">as</span> well <span class="hljs-keyword">as</span> information 
+        about subject attribute <span class="hljs-built_in">values</span> present in the SAML assertion authenticating 
+        the signer, which was incorporated into the signer certificate. This element 
+        MUST <span class="hljs-keyword">be</span> present <span class="hljs-keyword">if</span> signing was successful.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ContextInfo&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:ContextInfoType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SamlAssertions&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:SAMLAssertionsType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignatureCertificateChain&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:CertificateChainType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        An element of <span class="hljs-built_in">type</span> CertificateChainType holding the signer certificate <span class="hljs-keyword">as</span> 
+        well <span class="hljs-keyword">as</span> other certificates that may <span class="hljs-keyword">be</span> used <span class="hljs-keyword">to</span> validate the signature. This 
+        element MUST <span class="hljs-keyword">be</span> present <span class="hljs-keyword">if</span> signing was successful <span class="hljs-built_in">and</span> MUST contain <span class="hljs-keyword">all</span> 
+        certificate that are necessary <span class="hljs-keyword">to</span> compile <span class="hljs-keyword">a</span> <span class="hljs-built_in">complete</span> <span class="hljs-built_in">and</span> functional signed 
+        document.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherResponseInfo&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Optional <span class="hljs-keyword">sign</span> response elements of <span class="hljs-built_in">type</span> AnyType.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ToBeSignedBytes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The octets that are hashed <span class="hljs-built_in">and</span> signed when generating the signture. For 
+        PDF <span class="hljs-built_in">and</span> common modes of CMS this <span class="hljs-keyword">is</span> the DER encoded SignedAttributess field. 
+        For XML this <span class="hljs-keyword">is</span> the canonicalized SignedInfo octets.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AdESObject&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AdESObjectType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        Information in support of AdES signature creation.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Base64Signature&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:Base64SignatureType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;Result signature bytes&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherSignTaskData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignRequestExtensionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:RequestTime&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:Conditions&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+            This element MUST include the element sam<span class="hljs-variable">l:AudienceRestriction</span> which in
+            turn MUST contain one sam<span class="hljs-variable">l:Audience</span> element, specifying the <span class="hljs-keyword">return</span> URL <span class="hljs-keyword">for</span>
+            any resulting Sign Response message.
+          &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Signer&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:IdentityProvider&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:AuthnProfile&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+            If <span class="hljs-keyword">set</span>, the Version attribute MUST <span class="hljs-keyword">be</span> <span class="hljs-number">1.4</span> <span class="hljs-built_in">or</span> higher.
+          &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignRequester&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignService&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:RequestedSignatureAlgorithm&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:CertRequestProperties&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignMessage&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherRequestInfo&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Version&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span> default=<span class="hljs-string">&quot;1.1&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          The <span class="hljs-keyword">version</span> of the DSS specification. If absent, the <span class="hljs-keyword">version</span> value defaults <span class="hljs-keyword">to</span> <span class="hljs-string">&quot;1.1&quot;</span>.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignResponseExtensionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:ResponseTime&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Request&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignerAssertionInfo&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SignatureCertificateChain&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherResponseInfo&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Version&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> default=<span class="hljs-string">&quot;1.1&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          The <span class="hljs-keyword">version</span> of the DSS specification. If absent, the <span class="hljs-keyword">version</span> value defaults <span class="hljs-keyword">to</span> <span class="hljs-string">&quot;1.1&quot;</span>.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;CertificateChainType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;X509Certificate&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MappedAttributeType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AttributeAuthority&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span> 
+                  minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SamlAttributeName&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:PreferredSAMLAttributeNameType&quot;</span>
+                  minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;CertAttributeRef&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;CertNameType&quot;</span> default=<span class="hljs-string">&quot;rdn&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;rdn&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;san&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;sda&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;FriendlyName&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;DefaultValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Required&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:boolean&quot;</span> default=<span class="hljs-string">&quot;false&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedAttributesType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedCertAttribute&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:MappedAttributeType&quot;</span>
+                  minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;AnyType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:any</span> processContents=<span class="hljs-string">&quot;lax&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SAMLAssertionsType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Assertion&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;    
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PreferredSAMLAttributeNameType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Order&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:int&quot;</span> default=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignTasksType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> ref=<span class="hljs-string">&quot;csig:SignTaskData&quot;</span>/&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignTaskDataType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:ToBeSignedBytes&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:AdESObject&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Base64Signature&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherSignTaskData&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;SignTaskId&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          A distinguishing id of this <span class="hljs-keyword">sign</span> task which <span class="hljs-keyword">is</span> used <span class="hljs-keyword">to</span> distinguish between 
+          multiple <span class="hljs-keyword">sign</span> tasks in the same request.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;SigType&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          Enumeration of the <span class="hljs-built_in">type</span> of signature the canonical signed information <span class="hljs-keyword">is</span>
+          associated with.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;XML&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;PDF&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;CMS&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;ASiC&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;AdESType&quot;</span> default=<span class="hljs-string">&quot;None&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          Specifies the <span class="hljs-built_in">type</span> of AdES signature. BES means that the signing certificate
+          hash must <span class="hljs-keyword">be</span> covered by the signature. EPES means that the signing 
+          certificate hash <span class="hljs-built_in">and</span> <span class="hljs-keyword">a</span> signature policy identifier must <span class="hljs-keyword">be</span> covered by 
+          the signature.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;None&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;BES&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;EPES&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;ProcessingRules&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> use=<span class="hljs-string">&quot;optional&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+          An identifier <span class="hljs-keyword">for</span> processing rules that must <span class="hljs-keyword">be</span> executed by the signature 
+          service when processing data in this element.
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;AdESObjectType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignatureId&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AdESObjectBytes&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;OtherAdESData&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;csig:AnyType&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;CertRequestPropertiesType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AuthnContextClassRef&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+            The URI reference(s) <span class="hljs-keyword">to</span> the requested level of assurance with which the 
+            certificate subject should <span class="hljs-keyword">be</span> authenticated.
+          &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:RequestedCertAttributes&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:OtherProperties&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> default=<span class="hljs-string">&quot;PKC&quot;</span> name=<span class="hljs-string">&quot;CertType&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;PKC&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;QC&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;QC/SSCD&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignerAssertionInfoType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:ContextInfo&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AttributeStatement&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:SamlAssertions&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;ContextInfoType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;1&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;IdentityProvider&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;saml:NameIDType&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AuthenticationInstant&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:dateTime&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;saml:AuthnContextClassRef&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;ServiceID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AuthType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;AssertionRef&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;Base64SignatureType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Type&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SignMessageType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:choice</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:Message&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> ref=<span class="hljs-string">&quot;csig:EncryptedMessage&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:choice</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;MustShow&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:boolean&quot;</span> default=<span class="hljs-string">&quot;false&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;DisplayEntity&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;MimeType&quot;</span> default=<span class="hljs-string">&quot;text&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text/html&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text&quot;</span> /&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:enumeration</span> value=<span class="hljs-string">&quot;text/markdown&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:restriction</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##other&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre>    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html b/docs/december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
new file mode 100644
index 0000000..0f81095
--- /dev/null
+++ b/docs/december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
@@ -0,0 +1,648 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>eIDAS Constructed Attributes Specification for the Swedish eID Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</h1>
+<h3 id="version-12---2021-11-11">Version 1.2 - 2021-11-11</h3>
+<p>Registration number: <strong>2019-315</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2021. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirement-key-words">Requirement key words</a></p>
+</li>
+<li><p><a href="#provisional-identifier"><strong>Provisional Identifier</strong></a></p>
+<p> 2.1. <a href="#provisional-identifier-prid-attribute">Provisional Identifier (prid) Attribute</a></p>
+<p> 2.2. <a href="#provisional-identifier-persistence-indicator-pridpersistence-attribute">Provisional Identifier Persistence Indicator (pridPersistence) Attribute</a></p>
+<p> 2.3. <a href="#algorithms">Algorithms</a></p>
+<p> 2.3.1. <a href="#algorithm-default-eidas">Algorithm: default-eIDAS</a></p>
+<p> 2.3.2. <a href="#algorithm-colresist-eidas">Algorithm: colresist-eIDAS</a></p>
+<p> 2.3.3. <a href="#special-characters-eidas">Algorithm: special-characters-eIDAS</a></p>
+<p> 2.4. <a href="#algorithm-selection-and-resulting-pridpersistence-value">Algorithm Selection and Resulting pridPersistence Value</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p>Appendix A. <a href="#prid-algorithm-implementations-java"><strong>PRID Algorithm implementations (Java)</strong></a></p>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This document extends “Attribute Specification for the Swedish eID
+Framework”, [<a href="#eidattributes">EidAttributes</a>], providing specifications for constructed
+attributes.</p>
+<p>The concept of constructed attributes is introduced in Swedish national
+authentication nodes (proxy nodes) delivering identity assertions to
+Swedish Service Providers based on user authentication with a foreign
+eID.</p>
+<p>A constructed attribute is an attribute that was not delivered by the
+foreign Identity Provider service, but was constructed in the Swedish
+authentication node by applying defined rules and algorithms to the
+authenticated user (subject) received from the foreign Identity Provider
+service (typically an eIDAS node).</p>
+<p><a name="requirement-key-words"></a></p>
+<h3 id="11-requirement-key-words">1.1. Requirement key words</h3>
+<p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
+“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
+interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations. When these words are
+not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="provisional-identifier"></a></p>
+<h2 id="2-provisional-identifier">2. Provisional Identifier</h2>
+<p>The Attribute Specification for the Swedish eID Framework, [<a href="#eidattributes">EidAttributes</a>], defines the attributes <code>prid</code> and <code>pridPersistence</code>.</p>
+<p>The <code>prid</code> attribute holds a unique identifier for a person derived from
+attributes provided from another country. The purpose of this attribute
+is to provide a common unique attribute for an authenticated user
+independently of the attribute set or the characteristics of these
+attributes provided by the authentication service in the other country.</p>
+<p>The <code>pridPersistence</code> attribute provides an indicator of the expected
+persistence of the <code>prid</code> identifier over time. The value in this
+attribute is determined by assessing the persistence of underlying
+foreign attributes from a particular source used in a particular <code>prid</code>
+generation algorithm.</p>
+<p>This document defines a set of <code>prid</code> algorithms, when to use each
+algorithm and the resulting <code>pridPersistence</code> value.</p>
+<p><a name="provisional-identifier-prid-attribute"></a></p>
+<h3 id="21-provisional-identifier-prid-attribute">2.1. Provisional Identifier (prid) Attribute</h3>
+<p>The provisional identifier (<code>prid</code>) attribute is a SAML attribute
+identified by the SAML attribute name <code>urn:oid:1.2.752.201.3.4</code>.</p>
+<p>The <code>prid</code> attribute holds a string value containing the following data:</p>
+<blockquote>
+<p><strong>{2 letter ISO 3166 country code of eID country}</strong> + <strong>”:“</strong> +
+<strong>{10..30 character identifier}</strong></p>
+</blockquote>
+<p>Syntactically, provisional ID is defined by the following regular
+expression:</p>
+<blockquote>
+<p><code>^[A-Z]{2}:[0-9a-z][0-9a-z-]{8,28}[0-9a-z]$</code></p>
+</blockquote>
+<p>Examples:</p>
+<blockquote>
+<p>NO:29078534891</p>
+<p>DK:09208-2002-2-194967071622</p>
+</blockquote>
+<p>The country code is the 2 letter ISO 3166 country code
+expressed in upper case letters, for example, “SE” for Sweden and “NO”
+for Norway. This identifies the country that issued the eID used to
+authenticate the user (i.e., provided the infrastructure to identify the
+person). This is not necessarily the person’s actual citizenship or
+country of residence.</p>
+<p>The identifier component holds a minimum of 10 and a maximum of 30
+characters. The primary reason for this is to provide an identifier that
+can be displayed to a user and still relatively convenient to write down
+or communicate by humans in case of problems. The characters in the
+identifier component are restricted to the numeric characters 0-9, the
+letters a-z and the hyphen character “-“ (0x2D) serving as delimiter.
+Letters “a-z” MUST be lower case. Should a provisional ID ever be
+presented with upper case letters then such letter should be matched
+using case insensitive matching (e.g. “a” is equivalent to “A”). The
+identifier component MUST NOT start or end with a hyphen character. The
+resulting ID MUST have at least 8 characters that are not a hyphen
+character, for example, the character sequence “1-2-3-4-56” is not
+allowed as it only holds 6 distinguishing ID characters.</p>
+<p><a name="provisional-identifier-persistence-indicator-pridpersistence-attribute"></a></p>
+<h3 id="22-provisional-identifier-persistence-indicator-pridpersistence-attribute">2.2. Provisional Identifier Persistence Indicator (pridPersistence) Attribute</h3>
+<p>The provisional identifier (<code>pridPersistence</code>) attribute is a SAML
+attribute identified by the SAML attribute name <code>urn:oid:1.2.752.201.3.5</code>.</p>
+<p>The pridPersistence attribute holds a string value containing the
+following data:</p>
+<blockquote>
+<p><strong>{1 letter Identifier (A, B or C)}</strong></p>
+</blockquote>
+<p><strong>Examples:</strong></p>
+<blockquote>
+<p>A</p>
+<p>B</p>
+<p>C</p>
+</blockquote>
+<p><strong>Value definitions:</strong></p>
+<table>
+<thead>
+<tr>
+<th align="left">Value</th>
+<th align="left">Defined meaning</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">A</td>
+<td align="left">Persistence over time is expected to be comparable or better than a Swedish personal identity number (personnummer). This means that the identifier typically is stable throughout the lifetime of the subject and is typically preserved even if the subject changes address, name or civil status.</td>
+</tr>
+<tr>
+<td align="left">B</td>
+<td align="left">Persistence over time is expected to be relatively stable, but lower than a Swedish personal identity number (personnummer). This means that the identifier typically remains unchanged as long as the person does not change address, name or civil status. Such or similar event may cause the identifier to change but the identifier will not change just because the subject gets a new eID (electronic identification means) or changes eID provider.</td>
+</tr>
+<tr>
+<td align="left">C</td>
+<td align="left">No expectations regarding persistence over time. The identifier may change if the subject changes eID or eID provider.</td>
+</tr>
+</tbody></table>
+<p><a name="algorithms"></a></p>
+<h3 id="23-algorithms">2.3. Algorithms</h3>
+<p>This section defines algorithms for generating the identifier component
+of <code>prid</code> attribute values. The identifier component makes up the
+characters following the “:” (colon) character in the <code>prid</code>.</p>
+<p><a name="algorithm-default-eidas"></a></p>
+<h4 id="231-algorithm-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
+<p><strong>Name:</strong> <code>default-eIDAS</code></p>
+<p><strong>Input values</strong>:</p>
+<ul class="list">
+<li><code>eidasID</code> - The identifier string value from the eIDAS PersonIdentifier attribute from the attribute source (identified by the attribute name <code>http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier</code>.</li>
+</ul>
+<p><strong>Calculated values</strong>:</p>
+<ul class="list">
+<li><p><code>strippedID</code> = <code>eidasID</code> after:</p>
+<ol class="list">
+<li>removing the 6 leading characters matching the regular expression <code>^[A-Za-z]{2}[\/](SE\|se)[\/]</code>  (e.g., ”NO/SE/”), and; </li>
+<li>removing any white space and non-printable characters.</li>
+</ol>
+</li>
+<li><p><code>normalizedID</code> = <code>strippedID</code> converted according to the following steps: </p>
+<ol class="list">
+<li>converting all upper case letters [A-Z] to lower case, and, </li>
+<li>replacing with a single “-“ character, all sequences of characters of length (1…n) that does not contain [0-9] or [a-z], and,</li>
+<li>remove any leading or trailing “-“ characters.</li>
+</ol>
+</li>
+</ul>
+<p><strong>Result</strong>:</p>
+<p>If length of <code>normalizedID</code> &lt; 10 characters:</p>
+<blockquote>
+<p>Return <code>normalizedID</code> padded with leading “0” (zero) characters until
+length = 10 characters.</p>
+</blockquote>
+<p>If length of <code>normalizedID</code> 10 - 30 characters:</p>
+<blockquote>
+<p>Return <code>normalizedID</code></p>
+</blockquote>
+<p>If length of <code>normalizedID</code> &gt; 30 characters**:**</p>
+<blockquote>
+<p>Return the string representation of the first 30 hexadecimal digits of
+the SHA256 hash of the UTF-8 encoded bytes of <code>strippedID</code>.</p>
+</blockquote>
+<p><strong>Exceptions</strong>:</p>
+<blockquote>
+<p>If the following conditions occur in the process, prid generation
+fails:</p>
+</blockquote>
+<ol class="list">
+<li> Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
+<li> <code>normalizedID</code> &lt; 6 characters (not counting “-“ (hyphen) characters).</li>
+</ol>
+<p><strong>Collision resistance:</strong></p>
+<p>All eIDAS PersonIdentifier attributes are required to be unique. That
+uniqueness is preserved in this algorithm based on the assumption that
+distinguishing symbols in the PersonIdentifier are represented
+exclusively by case insensitive letters a-z and numbers 0-9. If this is
+not a case for the PersonIdentifier provided by a particular country,
+then this algorithm should not be selected due to the risk of ID
+collisions.</p>
+<p>In case the normalized identifier string exceeds 30 characters this
+algorithm falls back on providing a 30 hex digit representation of a
+concatenated SHA-2 hash value. The collision probability for such
+identifier among 2 users is 1 in 1,25 * 10^36 (Calculated as 16^30 –
+16^29 since first digit can not be 0). For a population of 100 million
+people the probability of a collision is approximately 1 in 2.5 *
+10^20 or 1 in 250 trillion countries of that population size<sup><a href="#footnote-2-3-1">1</a></sup>.</p>
+<p>Countries typically do not use ID attributes that exceed 30 characters
+in size, but it cannot be ruled out that some countries will generate an
+ID for cross-border use that is different from a national ID and that
+that ID may exceed 30 characters. This algorithm assumes that the
+collision resistance provided is sufficient given both the low
+probability combined with the fact that only a very small fraction of
+users from any country outside of Sweden is likely to authenticate to a
+Swedish e-service. A collision among all citizens would in most cases
+not be security critical since the unique eIDAS ID in its original form
+also is present in the assertion to the service provider, which
+guarantees that a transaction is traceable back to the right individual.</p>
+<p>In case these properties are not enough to guarantee sufficient
+collision resistance, the algorithm colresist-eIDAS should be used.</p>
+<p><strong>Examples:</strong></p>
+<table>
+<thead>
+<tr>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">NO/SE/05068907693</td>
+<td align="left">NO:05068907693</td>
+</tr>
+<tr>
+<td align="left">DK/SE/09208-2002-2-194967071622</td>
+<td align="left">DK:09208-2002-2-194967071622</td>
+</tr>
+<tr>
+<td align="left">UK/DK/1234567890</td>
+<td align="left">UK:NULL (Failed: target country is not SE)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/#12345-3456//ABC</td>
+<td align="left">DE:12345-3456-abc</td>
+</tr>
+<tr>
+<td align="left">DE/SE/aErf#(EAd9)</td>
+<td align="left">DE:0aerf-ead9</td>
+</tr>
+<tr>
+<td align="left">de/se/aErf#(E)</td>
+<td align="left">NULL (Failed: Less than 6 ID characters)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/(1952 12 14-1122)</td>
+<td align="left">DE:19521214-1122</td>
+</tr>
+<tr>
+<td align="left">19521214-1122</td>
+<td align="left">NULL (Failed: Leading 6 character format error)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/1234567890123456789012345678901</td>
+<td align="left">DE:3b7184c0ceaf76a9607a31e4e1f87f</td>
+</tr>
+</tbody></table>
+<p><a name="footnote-2-3-1"></a></p>
+<blockquote>
+<p>[1]: Birthday paradox approximation p(<em>n</em>) ≈ <em>n</em>^2 / 2<em>m</em>, where p(<em>n</em>) is the collision probability, <em>n</em> is the number of people and <em>m</em> is the number of possible ID combinations.</p>
+</blockquote>
+<p><a name="algorithm-colresist-eidas"></a></p>
+<h4 id="232-algorithm-colresist-eidas">2.3.2. Algorithm: colresist-eIDAS</h4>
+<p>This algorithm is identical to default-eIDAS except that the hashed
+expression of the ID in case the normalized ID exceeds 30 characters,
+has higher collision resistance by expressing the ID in radix 36 instead
+of radix 16 (Hexadecimal)<sup><a href="#footnote2-3-2">1</a></sup>.</p>
+<p><strong>Name:</strong> <code>colresist-eIDAS</code></p>
+<p><strong>Input values</strong>: Identical to <code>default-eIDAS</code></p>
+<p><strong>Calculated values</strong>: Identical to <code>default-eIDAS</code></p>
+<p><strong>Result</strong>:</p>
+<p>If length of normalizedID &lt; 10 characters:</p>
+<blockquote>
+<p>Identical to <code>default-eIDAS</code> result</p>
+</blockquote>
+<p>If length of normalizedID 10 - 30 characters:</p>
+<blockquote>
+<p>Identical to <code>default-eIDAS</code> result</p>
+</blockquote>
+<p>If length of normalizedID &gt; 30 characters**:**</p>
+<blockquote>
+<p>Return the string representation of the first 30 radix 36 digits of the SHA256 hash of the UTF-8 encoded bytes of <code>strippedID</code>.</p>
+</blockquote>
+<p><strong>Exceptions</strong>: Identical to <code>default-eIDAS</code></p>
+<p><strong>Collision resistance:</strong></p>
+<p>Expression of this ID in hashed form use 30 radix 36 symbols. This
+reduces the collision resistance among 2 users to 1 in 4.75 * 10^46.
+The collision probability among 100 million users is reduced to
+approximately 1 in 10^31.</p>
+<p><strong>Examples:</strong></p>
+<table>
+<thead>
+<tr>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">NO/SE/05068907693</td>
+<td align="left">NO:05068907693</td>
+</tr>
+<tr>
+<td align="left">DK/SE/09208-2002-2-194967071622</td>
+<td align="left">DK:09208-2002-2-194967071622</td>
+</tr>
+<tr>
+<td align="left">UK/DK/1234567890</td>
+<td align="left">UK:NULL (Failed: target country is not SE)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/#12345-3456//ABC</td>
+<td align="left">DE:12345-3456-abc</td>
+</tr>
+<tr>
+<td align="left">DE/SE/aErf#(EAd9)</td>
+<td align="left">DE:0aerf-ead9</td>
+</tr>
+<tr>
+<td align="left">de/se/aErf#(E)</td>
+<td align="left">NULL (Failed: Less than 6 ID characters)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/(1952 12 14-1122)</td>
+<td align="left">DE:19521214-1122</td>
+</tr>
+<tr>
+<td align="left">19521214-1122</td>
+<td align="left">NULL (Failed: Leading 6 character format error)</td>
+</tr>
+<tr>
+<td align="left">DE/SE/1234567890123456789012345678901</td>
+<td align="left">DE:1hc3tpoleczqu3t8jz2995k2rq7nt8</td>
+</tr>
+</tbody></table>
+<p><a name="footnote2-3-2"></a></p>
+<blockquote>
+<p>[1]: Radix 36 express values ranging from 0 to 36 through a single character using the symbols ”0123456789abcdefghijklmnopqrstuvwxyz” in the presented order.</p>
+</blockquote>
+<p><a name="special-characters-eidas"></a></p>
+<h4 id="233-algorithm-special-characters-eidas">2.3.3. Algorithm: special-characters-eIDAS</h4>
+<p>The default-eIDAS and the colresist-eIDAS algoritms are suitable when the base identifier from the authenticating country is constructed from digits and basic case-insensitive characters. These algoritms do not work on identifiers constructed as a Base64 string of binary data, such as a hash of another identifier.</p>
+<p>The present algoritm is intended to be used where the base identifier contains case-sensitive characters and where characters other than a-z and 0-9 are used to add entropy to the identifier.</p>
+<p><strong>Name:</strong> <code>special-characters-eIDAS</code></p>
+<p><strong>Input values</strong>:  Identical to <code>default-eIDAS</code>.</p>
+<p><strong>Calculated values</strong>: Identical to <code>default-eIDAS</code> with the exception that <code>normalizedID</code> is not calculated and used.</p>
+<p><strong>Result</strong>:</p>
+<blockquote>
+<p>Return the string representation of the first 30 radix 36 digits of the SHA256 hash of the UTF-8 encoded bytes of <code>strippedID</code>.</p>
+</blockquote>
+<p><strong>Exceptions</strong>: </p>
+<blockquote>
+<p>If the following conditions occur in the process, prid generation fails:</p>
+</blockquote>
+<ol class="list">
+<li> Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
+<li> <code>strippedID</code> &lt; 16 characters.</li>
+</ol>
+<p><strong>Collision resistance:</strong> Identical to <code>colresist-eIDAS</code>.</p>
+<p><strong>Examples:</strong></p>
+<table>
+<thead>
+<tr>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">AT/SE/Zk2ME2pjxwzQOjVeFGeqSIage34=</td>
+<td align="left">AT:50bwytdle2mzexopcolmdhmhznihms</td>
+</tr>
+</tbody></table>
+<p><a name="algorithm-selection-and-resulting-pridpersistence-value"></a></p>
+<h3 id="24-algorithm-selection-and-resulting-pridpersistence-value">2.4. Algorithm Selection and Resulting pridPersistence Value</h3>
+<p>This section defines the current algorithm selection rules and the
+resulting pridPersistence value. These rules are processed in the
+presented order. The first rule where the present conditions matches all
+the matching rules is selected.</p>
+<p>If the present conditions do not match any of the listed rules, then
+prid generation fails.</p>
+<table>
+<thead>
+<tr>
+<th align="left">Rule 1</th>
+<th align="left">Description</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+</tr>
+<tr>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+</tr>
+<tr>
+<td align="left">Matching rule 3</td>
+<td align="left">Attributes provided by any of the countries that issue identities according to persistance class A.</td>
+</tr>
+<tr>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
+</tr>
+<tr>
+<td align="left">pridPersistence value</td>
+<td align="left">A</td>
+</tr>
+</tbody></table>
+<table>
+<thead>
+<tr>
+<th align="left">Rule 2</th>
+<th align="left">Description</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+</tr>
+<tr>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+</tr>
+<tr>
+<td align="left">Matching rule 3</td>
+<td align="left">Attributes provided by any of the countries that issue identities according to persistance class B.</td>
+</tr>
+<tr>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
+</tr>
+<tr>
+<td align="left">pridPersistence value</td>
+<td align="left">B</td>
+</tr>
+</tbody></table>
+<table>
+<thead>
+<tr>
+<th align="left">Rule 3</th>
+<th align="left">Description</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+</tr>
+<tr>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+</tr>
+<tr>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
+</tr>
+<tr>
+<td align="left">pridPersistence value</td>
+<td align="left">C</td>
+</tr>
+</tbody></table>
+<p><a name="references"></a></p>
+<h2 id="3-references">3. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="saml-xsd"></a>
+<strong>[SAML-XSD]</strong></p>
+<blockquote>
+<p>S. Cantor et al., SAML assertions schema. OASIS SSTC, March 2005.
+Document ID saml-schema-assertion-2.0. See
+<a href="http://www.oasisopen.org/committees/security/">http://www.oasisopen.org/committees/security/</a>.</p>
+</blockquote>
+<p><a name="xml-schema"></a>
+<strong>[XML-Schema]</strong></p>
+<blockquote>
+<p>XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28
+October 2004. See <a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>.</p>
+</blockquote>
+<p><a name="eidattributes"></a>
+<strong>[EidAttributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="eidas-attr"></a>
+<strong>[eIDAS-Attr]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.2-FINAL.pdf">eIDAS SAML Attribute Profile, version 1.2, 21 May 2019</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="4-changes-between-versions">4. Changes between versions</h2>
+<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
+<ul class="list">
+<li>The length requirement for identifier characters has been changed from 8 to 6. This applies to the default-eIDAS and colresist-eIDAS algorithms.</li>
+</ul>
+<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
+<ul class="list">
+<li><p>Update of logotype and fixes of minor typos.</p>
+</li>
+<li><p>Update of reference of eIDAS attribute profile to version 1.2.</p>
+</li>
+<li><p>Removed Appendix A, &quot;Countries with pridPersistence of class A&quot; and Appendix B, &quot;Countries with pridPersistence of class B&quot;. This information is continuously updated and maintained on <a href="https://swedenconnect.se">https://swedenconnect.se</a>.</p>
+</li>
+</ul>
+<p><a name="prid-algorithm-implementations-java"></a></p>
+<h2 id="appendix-a-prid-algorithm-implementations-java">Appendix A. PRID Algorithm implementations (Java)</h2>
+<p><strong>default-eIDAS</strong></p>
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> static final String personIdentifierPrefixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
+
+  public String get<span class="hljs-constructor">PridIdentifierComponent(String <span class="hljs-params">personIdentifier</span>)</span> throws PridGenerationException {
+    
+    <span class="hljs-keyword">if</span> (personIdentifier<span class="hljs-operator"> == </span>null) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>)</span>;
+    }
+    <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrefixRegexp)) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
+    }
+    <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
+    String strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+        
+    <span class="hljs-comment">// Convert to lower case</span>
+    String normalizedID = strippedID.<span class="hljs-keyword">to</span><span class="hljs-constructor">LowerCase()</span>;
+            
+    <span class="hljs-comment">// Replace sequences of non ID characters to &quot;-&quot;</span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;[^a-z0-9]+&quot;</span>, <span class="hljs-string">&quot;-&quot;</span>)</span>;
+    
+    <span class="hljs-comment">// Remove leading and trailing &quot;-&quot; </span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;^-+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-+$&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    <span class="hljs-keyword">if</span> (normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">6</span>) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
+    }
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">10</span>) {
+      normalizedID = <span class="hljs-string">&quot;0000000000&quot;</span>.substring(normalizedID.length<span class="hljs-literal">()</span>) + normalizedID;
+    }
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &gt; <span class="hljs-number">30</span>) {
+      <span class="hljs-keyword">try</span> {
+        MessageDigest md = <span class="hljs-module-access"><span class="hljs-module"><span class="hljs-identifier">MessageDigest</span>.</span></span>get<span class="hljs-constructor">Instance(<span class="hljs-string">&quot;SHA-256&quot;</span>)</span>;
+        byte<span class="hljs-literal">[]</span> digest = md.digest(strippedID.get<span class="hljs-constructor">Bytes(Charset.<span class="hljs-params">forName</span>(<span class="hljs-string">&quot;UTF-8&quot;</span>)</span>));
+        return <span class="hljs-keyword">new</span> <span class="hljs-constructor">BigInteger(1, <span class="hljs-params">digest</span>)</span>.<span class="hljs-keyword">to</span><span class="hljs-constructor">String(16)</span>.substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
+      }
+      catch (NoSuchAlgorithmException ex) {
+        throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-params">e</span>)</span>;
+      }
+    }
+    return normalizedID;
+  }
+</code></pre><p><strong>colresist-eIDAS</strong></p>
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> static final String personIdentifierPrefixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
+  
+  public static String get<span class="hljs-constructor">PridIdentifierComponent(String <span class="hljs-params">personIdentifier</span>)</span> throws PridGenerationException {
+    <span class="hljs-keyword">if</span> (personIdentifier<span class="hljs-operator"> == </span>null) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>)</span>;
+    }
+    <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrefixRegexp)) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
+    }
+    
+    <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
+    String strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    
+    <span class="hljs-comment">// Convert to lower case</span>
+    String normalizedID = strippedID.<span class="hljs-keyword">to</span><span class="hljs-constructor">LowerCase()</span>;
+    
+    <span class="hljs-comment">// Replace sequences of non ID characters to &quot;-&quot;</span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;[^a-z0-9]+&quot;</span>, <span class="hljs-string">&quot;-&quot;</span>)</span>;
+    
+    <span class="hljs-comment">// Remove leading and trailing &quot;-&quot; </span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;^-+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-+$&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    <span class="hljs-keyword">if</span> (normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">6</span>) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
+    }
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">10</span>) {
+      normalizedID = <span class="hljs-string">&quot;0000000000&quot;</span>.substring(normalizedID.length<span class="hljs-literal">()</span>) + normalizedID;
+    }
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &gt; <span class="hljs-number">30</span>) {
+      <span class="hljs-keyword">try</span> {
+        MessageDigest md = <span class="hljs-module-access"><span class="hljs-module"><span class="hljs-identifier">MessageDigest</span>.</span></span>get<span class="hljs-constructor">Instance(<span class="hljs-string">&quot;SHA-256&quot;</span>)</span>;
+        byte<span class="hljs-literal">[]</span> digest = md.digest(strippedID.get<span class="hljs-constructor">Bytes(Charset.<span class="hljs-params">forName</span>(<span class="hljs-string">&quot;UTF-8&quot;</span>)</span>));
+        return <span class="hljs-keyword">new</span> <span class="hljs-constructor">BigInteger(1, <span class="hljs-params">digest</span>)</span>.<span class="hljs-keyword">to</span><span class="hljs-constructor">String(36)</span>.substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
+      } 
+      catch (NoSuchAlgorithmException ex) {
+        throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-params">e</span>)</span>;
+      }
+    }
+    return normalizedID;
+  }</code></pre><p><strong>special-characters-eIDAS</strong></p>
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> <span class="hljs-keyword">static</span> final <span class="hljs-keyword">String</span> personIdentifierPrifixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
+
+  <span class="hljs-keyword">public</span> <span class="hljs-keyword">String</span> getPridIdentifierComponent(<span class="hljs-keyword">String</span> personIdentifier) throws PridGenerationException {
+    <span class="hljs-keyword">if</span> (personIdentifier == <span class="hljs-literal">null</span>) {
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>);
+    }
+    <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrifixRegexp)) {
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Invalid ID format&quot;</span>);
+    }
+    
+    <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
+    <span class="hljs-keyword">String</span> strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replaceAll(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>);
+    <span class="hljs-keyword">if</span> (strippedID.length() &lt; <span class="hljs-number">16</span>) {
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Invalid ID format&quot;</span>);
+    }
+    <span class="hljs-keyword">try</span> {
+      MessageDigest md = MessageDigest.getInstance(<span class="hljs-string">&quot;SHA-256&quot;</span>);
+      byte[] digest = md.digest(strippedID.getBytes(Charset.forName(<span class="hljs-string">&quot;UTF-8&quot;</span>)));
+      <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-type">BigInteger</span>(<span class="hljs-number">1</span>, digest).toString(<span class="hljs-number">36</span>).substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
+    }
+    <span class="hljs-keyword">catch</span> (NoSuchAlgorithmException ex) {
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(e);
+    }
+  }</code></pre>    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html b/docs/december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
new file mode 100644
index 0000000..6ea242c
--- /dev/null
+++ b/docs/december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
@@ -0,0 +1,487 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Implementation Profile for BankID Identity Providers within the Swedish eID Framework</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h1>
+<h3 id="version-14---2024-12-04">Version 1.4 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-316</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.2. <a href="#references-to-saml-20-standards-and-profiles">References to SAML 2.0 Standards and Profiles</a></p>
+<p> 1.3. <a href="#bankid-methods-and-applications">BankID Methods and Applications</a></p>
+<p> 1.3.1. <a href="#representation-as-identity-providers">Representation as Identity Providers</a></p>
+<p> 1.3.2. <a href="#recommended-limitations">Recommended Limitations</a></p>
+<p> 1.4. <a href="#relying-party-configuration">Relying Party Configuration</a></p>
+</li>
+<li><p><a href="#attributes"><strong>Attributes</strong></a></p>
+<p> 2.1. <a href="#attribute-transformation">Attribute Transformation</a></p>
+<p> 2.1.1. <a href="#the-authcontextparams-attribute">The authContextParams Attribute</a></p>
+</li>
+<li><p><a href="#identity-provider-user-interface"><strong>Identity Provider User Interface</strong></a></p>
+<p> 3.1. <a href="#general-requirements">General Requirements</a></p>
+<p> 3.2. <a href="#automatic-start-of-bankid-client">Automatic Start of the BankID Client</a></p>
+<p> 3.3. <a href="#cancelling-an-operation">Cancelling an Operation</a></p>
+</li>
+<li><p><a href="#authentication-requests"><strong>Authentication Requests</strong></a></p>
+<p> 4.1. <a href="#binding-and-security-requirements">Binding and Security Requirements</a></p>
+<p> 4.2. <a href="#handling-of-principal-selection">Handling of Principal Selection</a></p>
+<p> 4.3. <a href="#authentication-for-signature">Authentication for Signature</a></p>
+<p> 4.3.1. <a href="#input-to-bankid-signing">Input to BankID Signing</a></p>
+<p> 4.3.1.1. <a href="#uservisibledata">userVisibleData - Signature Message</a></p>
+<p> 4.3.1.2. <a href="#usernonvisibledata">userNonVisibleData</a></p>
+</li>
+<li><p><a href="#authentication-responses"><strong>Authentication Responses</strong></a></p>
+<p> 5.1. <a href="#attribute-release-rules">Attribute Release Rules</a></p>
+<p> 5.2. <a href="#error-responses">Error Responses</a></p>
+</li>
+<li><p><a href="#metadata"><strong>Metadata</strong></a></p>
+<p> 6.1. <a href="#service-providers">Service Providers</a></p>
+<p> 6.2. <a href="#identity-providers">Identity Providers</a></p>
+<p> 6.3. <a href="#signature-services">Signature Services</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This profile defines how a SAML Identity Provider that offers authentication using the Swedish BankID technology should implement its services to be compliant with the Swedish eID Framework. It extends the &quot;Deployment Profile for the Swedish eID Framework&quot;,  [<a href="#sc-saml-profile">SC.SAML.Profile</a>], with requirements and recommendations for Identity Providers offering BankID authentication and signature services.</p>
+<p>The BankID interface for authentication and signature, the Relying Party Interface, is described at <a href="https://developers.bankid.com">https://developers.bankid.com</a>. This specification MUST be fully implemented and supported by BankID Identity Providers compliant with the Swedish eID Framework specifications.</p>
+<p><a name="requirements-notation"></a></p>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The keywords &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
+&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
+document are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
+on deployment practices intended to foster both interoperability and
+guarantees of security and confidentiality needed to satisfy the
+requirements of many organizations that engage in the use of federated
+identity. Deviating may limit a deployment&#39;s ability to technically
+interoperate without additional negotiation, and should be undertaken
+with caution.</p>
+<p><a name="references-to-saml-20-standards-and-profiles"></a></p>
+<h3 id="12-references-to-saml-20-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
+<p>When referring to elements from the SAML 2.0 core specification [<a href="#saml2core">SAML2Core</a>],
+the following syntax is used:</p>
+<ul class="list">
+<li><p><code>&lt;saml2p:Element&gt;</code> – for elements from the SAML 2.0 Protocol
+  namespace.</p>
+</li>
+<li><p><code>&lt;saml2:Element&gt;</code> – for elements from the SAML 2.0 Assertion
+  namespace.</p>
+</li>
+</ul>
+<p>When referring to elements from the SAML 2.0 metadata specifications,
+the following syntax is used:</p>
+<ul class="list">
+<li><p>  <code>&lt;md:Element&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
+</li>
+<li><p>  <code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
+</li>
+</ul>
+<p><a name="bankid-methods-and-applications"></a></p>
+<h3 id="13-bankid-methods-and-applications">1.3. BankID Methods and Applications</h3>
+<p>There are three types of BankID:</p>
+<ul class="list">
+<li>Mobile BankID - End users use the &quot;BankID app&quot; on their mobile devices to authenticate or perform a signature. In these cases the user certificate is stored in the app and protected by a personal code.</li>
+<li>BankID on file - End users use the desktop program &quot;BankID Security Application&quot; to authenticate or perform a signature. The user certificate is stored in a file on the computer and is protected by a user password.</li>
+<li>BankID on card - End users make use of the same desktop program as described above, but the certificate is placed on a smart card. The user private key is unlocked using the PIN-pad on the smart card reader.</li>
+</ul>
+<p>The three above methods are all &quot;BankID&quot;, but historically, relying parties have made a difference between &quot;Mobile BankID&quot; and &quot;BankID&quot; (the original desktop version).</p>
+<p><a name="representation-as-identity-providers"></a></p>
+<h4 id="131-representation-as-identity-providers">1.3.1. Representation as Identity Providers</h4>
+<p>An actor offering BankID services can choose to use <strong>one</strong> BankID Identity Provider supporting all different BankID methods, or use <strong>several</strong> Identity Provider instances, one for each BankID method. </p>
+<p>Services that support all methods within one Identity Provider instance usually displays a question to the user before authentication starts, where the user chooses between &quot;Using BankID on this device or another device&quot;. In an environment where a discovery service (or similar) is being used, this means that the user has to make two choices before the actual authentication process starts; first at the discovery service where the user selects &quot;BankID&quot; and then at the BankID Identity Provider where the user selects the type of BankID authentication to use.</p>
+<p>It is RECOMMENDED that BankID services are split into separate Identity Providers for each supported BankID method. The reasons for this are the above argument about discovery, but also the fact that a Service Provider should be able to select which type of authentication that is required (for example, Mobile BankID may be accepted but not BankID on file). </p>
+<p><a name="recommended-limitations"></a></p>
+<h4 id="132-recommended-limitations">1.3.2. Recommended Limitations</h4>
+<p>The table below states the RECOMMENDED support and behaviour when support for BankID is implemented using separate Identity Providers (as recommended in section <a href="#representation-as-identity-providers">1.3.1</a> above). </p>
+<table>
+<thead>
+<tr>
+<th align="left">Identity Provider</th>
+<th align="left">Desktop</th>
+<th align="left">Mobile Phone</th>
+<th align="left">Tablet</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left">Mobile BankID</td>
+<td align="left">Start BankID on other device<sup>1</sup> (mobile phone or tablet).</td>
+<td align="left">Start BankID on the same device<sup>2</sup>.</td>
+<td align="left">Prompt the user to ask whether to start BankID on the tablet or on another device<sup>3</sup> (mobile phone).</td>
+</tr>
+<tr>
+<td align="left">BankID on file (<em>or on card</em>)</td>
+<td align="left">Start BankID on the same device<sup>4</sup>.</td>
+<td align="left">Not supported<sup>5</sup>.</td>
+<td align="left">Not supported<sup>5</sup>.</td>
+</tr>
+</tbody></table>
+<ol class="list">
+<li>The user initiates a BankID operation from his or hers desktop computer and selects to use Mobile BankID. In this case the Mobile BankID app is started on another device (since Mobile BankID does not exist on desktop computers).</li>
+<li>The user initiates a BankID operation from his or hers mobile phone and selects to use Mobile BankID. In this case the BankID app is started on the same device. It is highly unlikely that a user uses one mobile phone to visit a service and wants to use his or hers BankID on another device.</li>
+<li>The user initiates a BankID operation from his or hers tablet and selects to use Mobile BankID. In this case the recommendation is to prompt the user to ask whether the Mobile BankID app should be automatically started on the tablet, or if the user wishes to use BankID on another device (probably a mobile phone). The reason for this recommendation is that most users have a BankID on their mobile phones, but not necessarily on their tablets.</li>
+<li>The user initiates a BankID operation from his or hers desktop computer and selects to use BankID on file. The BankID Security Application is started on the same computer. It is not a likely use case to use one computer to connect to the service and another one for BankID.</li>
+<li>This case should not be supported. If the user selects &quot;BankID on file&quot; from a mobile phone or tablet,  the Identity Provider should display an error message stating that Mobile BankID should be used instead and post an error response back to the Service Provider.</li>
+</ol>
+<p>Note: Items 4 and 5 above also apply to BankID on card. A service MAY choose to implement BankID on file and BankID on card as separate Identity Providers or as one Identity Provider instance.</p>
+<p>For Identity Providers implementing BankID support in <strong>one</strong> Identity Provider instance it is RECOMMENDED to make the assumption that the BankID app should be started on the same device if the user connects via a mobile phone. </p>
+<p><a name="relying-party-configuration"></a></p>
+<h3 id="14-relying-party-configuration">1.4. Relying Party Configuration</h3>
+<p>When a Relying Party uses the BankID Relying Party API directly in order to implement BankID services, it has a set of configuration settings to choose from (see <code>requirements</code> object under the <a href="https://developers.bankid.com/api-references/auth--sign/auth">Auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">Sign API</a>). Examples are:</p>
+<ul class="list">
+<li><p>Should fingerprints be allowed instead of the user entering his or hers security code?</p>
+</li>
+<li><p>Active certificate policies.</p>
+</li>
+<li><p>Smart card reader preferences.</p>
+</li>
+</ul>
+<p>However, the services of a BankID Identity Provider are used by several parties within the federation, and it is thus harder to maintain a per-Service Provider configuration. Therefore, a BankID Identity Provider compliant with this profile SHOULD use the same configuration defaults as stated in <a href="https://developers.bankid.com/api-references/auth--sign/auth">Auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">Sign API</a>.</p>
+<blockquote>
+<p><strong>Note:</strong> It is of course allowed for a BankID Identity Provider to maintain specific Service Provider configurations, but this is outside the scope for this profile, and there will be no specification support to accomplish this.</p>
+</blockquote>
+<p><a name="attributes"></a></p>
+<h2 id="2-attributes">2. Attributes</h2>
+<p>An BankID Identity Provider use the BankID Relying Party API, as described in <a href="https://developers.bankid.com/api-references/auth--sign/overview">BankID API</a>, to communicate with the BankID-server when providing its services to end users. When a BankID-operation has completed successfully, the Identity Provider (the BankID Relying Party) invokes the Collect-method (<code>/collect</code>) to obtain the result from the operation.</p>
+<p>The table <a href="#attribute-transformation">below</a> contains attribute transformation mappings between attributes from a Collect-method response as described in <a href="https://developers.bankid.com/api-references/auth--sign/collect">/collect</a> and attributes defined within the Sweden Connect Framework as defined in [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].</p>
+<p>An Identity Provider should not necessarily release all transformed attributes received from the BankID-server to the Service Provider. See further section <a href="#attribute-release-rules">5.1</a>, &quot;<a href="#attribute-release-rules">Attribute Release Rules</a>&quot;.</p>
+<p><a name="attribute-transformation"></a></p>
+<h3 id="21-attribute-transformation">2.1. Attribute Transformation</h3>
+<table>
+<thead>
+<tr>
+<th align="left">BankID attribute</th>
+<th align="left">SAML Attribute</th>
+<th align="left">Description</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>orderRef</code></td>
+<td align="left">transactionIdentifier<br /><code>urn:oid:1.2.752.201.3.2</code></td>
+<td align="left">The BankID order reference received from a BankID Auth (<code>/rp/v5/auth</code>) or Sign (<code>rp/v5/sign</code>) method invocation. This parameter is supplied as an input parameter to the Collect-call and is the unique transaction identifier for the BankID-operation.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>user.personalNumber</code></td>
+<td align="left">personalIdentityNumber<br /><code>urn:oid:1.2.752.29.4.13</code></td>
+<td align="left">Swedish ”personnummer”. 12 digits without hyphen.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>user.givenName</code></td>
+<td align="left">givenName<br /><code>urn:oid:2.5.4.42</code></td>
+<td align="left">User&#39;s given name.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>user.surname</code></td>
+<td align="left">sn<br /><code>urn:oid:2.5.4.4</code></td>
+<td align="left">User&#39;s surname.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>user.name</code></td>
+<td align="left">displayName<br /><code>urn:oid:2.16.840.1.113730.3.1.241</code></td>
+<td align="left">User&#39;s given name and surname.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>device.ipAddress</code></td>
+<td align="left"><em>bankidUserAgentAddress</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">The IP-address of the user agent presented to the BankID server. In cases where a user uses BankID &quot;on another device&quot; this address may not be the same as the web user agent. No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidUserAgentAddress</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>device.uhi</code></td>
+<td align="left"><em>bankidUhi</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">Unique hardware identifier for the user&#39;s device. No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidUhi</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>bankIdIssueDate</code></td>
+<td align="left"><em>bankidIssueDate</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">The date the BankID was issued to the user.<br />No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidIssueDate</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>signature</code></td>
+<td align="left">userSignature<br /><code>urn:oid:1.2.752.201.3.11</code></td>
+<td align="left">The signature applied by the user as part of the authentication/signature process.</td>
+</tr>
+<tr>
+<td align="left"><code>completionData.</code><br /><code>ocspResponse</code></td>
+<td align="left">authServerSignature<br /><code>urn:oid:1.2.752.201.3.13</code></td>
+<td align="left">The OCSP response signed by the BankID issuer that proves that the user BankID was checked for revocation.</td>
+</tr>
+</tbody></table>
+<p><a name="the-authcontextparams-attribute"></a></p>
+<h4 id="211-the-authcontextparams-attribute">2.1.1. The authContextParams Attribute</h4>
+<p>The <code>authContextParams</code> attribute, see section 3.2.1 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>], is a general purpose attribute to be used when non-standardized authentication data is to be transfered in a SAML assertion. </p>
+<p>The attribute is used by attribute providers to release data from an authentication process that has no attribute definition of its own. Thus, should the BankID attributes <code>completionData.bankIdIssueDate</code>, <code>completionData.device.ipAddress</code> and <code>completionData.device.uhi</code> be transformed and included into an assertion, they would have to be placed as key-value pairs of the <code>authContextParams</code> attribute as the example below.</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute xmlns:xsi=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>    
+                           FriendlyName=<span class="hljs-string">&quot;authContextParams&quot;</span>
+                           Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.3&quot;</span>
+                           NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+    <span class="hljs-attribute">bankidIssueDate</span>=<span class="hljs-number">2024</span>-<span class="hljs-number">05</span>-<span class="hljs-number">30</span>T<span class="hljs-number">09</span>%<span class="hljs-number">3</span>A<span class="hljs-number">30</span>%<span class="hljs-number">3</span>A<span class="hljs-number">10</span>Z;bankidUserAgentAddress=<span class="hljs-number">85.229.202.232</span>;bankidUhi=RTREUI<span class="hljs-number">8</span>
+  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
+<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p><a name="identity-provider-user-interface"></a></p>
+<h2 id="3-identity-provider-user-interface">3. Identity Provider User Interface</h2>
+<p>This profile does not state any requirements on how the user interface for an Identity Provider implementing BankID services should be implemented other than the statements listed in the subsections below.</p>
+<p><a name="general-requirements"></a></p>
+<h3 id="31-general-requirements">3.1. General Requirements</h3>
+<p>The user interface for a BankID Identity Provider SHOULD use the recommended user and error messages as defined in sections 5, &quot;Recommended User Messages&quot;, and BankID&#39;s <a href="https://developers.bankid.com/resources/user-messages">Recommended user messages</a> resource.</p>
+<p>The user interface for a BankID Identity Provider MUST display information about the Service Provider that sent the request. It is RECOMMENDED that this information is obtained from the <code>&lt;mdui:UIInfo&gt;</code> element from the Service Provider&#39;s metadata entry.</p>
+<p>It MUST be clear to the user whether an authentication or a signature process is ongoing. </p>
+<p>It is RECOMMENDED that an Identity Provider compliant with this profile supports the User Message authentication request extension, as defined in [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>]. </p>
+<p>If the Identity Provider supports this extension, the <code>userVisibleData</code> field of the BankID <a href="https://developers.bankid.com/api-references/auth--sign/auth">/auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">/sign</a> endpoints, MUST be assigned the value received in the <code>UserMessage</code> extension. </p>
+<p>When an error occurs during an authentication or signature operation, the Identity Provider MUST display an error message that can be easily understood by the end user, and offer the possibility to acknowledge the error so that an error response may be posted back to the requesting Service Provider (as specified in section 6.4, &quot;Error Responses&quot;, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]).</p>
+<p><a name="automatic-start-of-bankid-client"></a></p>
+<h3 id="32-automatic-start-of-the-bankid-client">3.2. Automatic Start of the BankID Client</h3>
+<p>When an operation is initiated where the BankID client (app or desktop program) is on the same device as the user agent (web browser) the Identity Provider SHOULD attempt to &quot;auto start&quot; the BankID client as described in the <a href="https://developers.bankid.com/getting-started/use-cases">BankID guide</a>.  </p>
+<p>Auto starting the BankID app from a mobile device requires the built-in web browser to be used to guarantee support. If the Identity Provider detects that the user is not using the platform&#39;s default browser it MAY ask the user to manually start the BankID app (and switch back to the browser after the BankID operation).</p>
+<p><a name="cancelling-an-operation"></a></p>
+<h3 id="33-cancelling-an-operation">3.3. Cancelling an Operation</h3>
+<p>A BankID Identity Provider MUST include a Cancel-button in the user interface enabling the possibility for the user to cancel the BankID operation. </p>
+<p>If the use clicks the Cancel-button after a BankID-operation has been started<sup>1</sup> the Identity Provider MUST invoke the BankID-operation <code>/cancel</code>. Failure to do so may lead to a dangling BankID session that needs to time out before the user can use BankID again.</p>
+<blockquote>
+<p>[1]: Meaning that <code>/auth</code> or <code>/sign</code> has been called for the transaction.</p>
+</blockquote>
+<p><a name="authentication-requests"></a></p>
+<h2 id="4-authentication-requests">4. Authentication Requests</h2>
+<p><a name="binding-and-security-requirements"></a></p>
+<h3 id="41-binding-and-security-requirements">4.1. Binding and Security Requirements</h3>
+<p>An Identity Provider conformant with this profile MUST require <code>&lt;saml2p:AuthnRequest&gt;</code> messages to be signed (by indicating this in its metadata, see section <a href="#metadata">6</a>, &quot;<a href="#metadata">Metadata</a>&quot;). Thus, the Identity Provider MUST not accept messages that are not signed, or where the verification of the signature fails. In these cases the Identity Provider MUST respond with an error.</p>
+<p><a name="handling-of-principal-selection"></a></p>
+<h3 id="42-handling-of-principal-selection">4.2. Handling of Principal Selection</h3>
+<p>An Identity Provider that has declared support for the <code>&lt;psc:PrincipalSelection&gt;</code> extension (see section <a href="#metadata">6</a>) MUST assign the <code>requirement.personalNumber</code> field of <a href="https://developers.bankid.com/api-references/auth--sign/auth">/auth</a> or <a href="https://developers.bankid.com/api-references/auth--sign/sign">/sign</a> if a Swedish personal identity number is received in the <code>&lt;psc:PrincipalSelection&gt;</code> extension.</p>
+<p>See [<a href="#sc-saml-principal">SC.SAML.Principal</a>] for further requirements concerning the principal selection extension.</p>
+<p><a name="authentication-for-signature"></a></p>
+<h3 id="43-authentication-for-signature">4.3. Authentication for Signature</h3>
+<p>An Identity Provider conforming to the Sweden Connect Framework is obliged to handle requests received from Signature Services as described in section 7, “Authentication for Signature”, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. This section further specifies how a BankID Identity Provider should support “authentication for signature”.</p>
+<p>A BankID Identity Provider that receives an <code>&lt;saml2p:AuthnRequest&gt;</code> message from a Signature Service MUST initiate a BankID <strong>signature</strong> operation. It MUST NOT initiate a BankID authentication operation for several reasons: </p>
+<ul class="list">
+<li>the user interface in the BankID client (app or Desktop program) during authentication indicates that the user is logging on (and not signing which is the case when a request from a Signature Service is being processed), </li>
+<li>the user expects to be displayed a text describing what he or she is signing,</li>
+<li>and most importantly, BankID is PKI-based and has support for signing using a non-repudiation key, so there is no reason not to use this function.</li>
+</ul>
+<p>The BankID client (app or desktop program) comprises a text box in which the signature message is displayed for the user. A BankID Identity Provider MUST NOT display the signature message in any other way than in this text box. How the signature message is assigned is specified below.</p>
+<p><a name="input-to-bankid-signing"></a></p>
+<h4 id="431-input-to-bankid-signing">4.3.1. Input to BankID Signing</h4>
+<p>An Identity Provider that processes an <code>&lt;saml2p:AuthnRequest&gt;</code> from a Signature Service is not given the actual data that is being signed by the user via the Signature Service. However, in order to invoke the BankID signature function, the Identity Provider must supply the BankID-server with data to be signed. This section specifies the input to the BankID signature operation.</p>
+<p>The &quot;To-be-signed&quot; data that is passed as input the BankID Sign-method (<code>/sign</code>) is a combination of the data from the <code>userVisibleData</code> and <code>userNonVisibleData</code> parameters (<a href="https://developers.bankid.com/api-references/auth--sign/sign">https://developers.bankid.com/api-references/auth--sign/sign</a>).</p>
+<p><a name="uservisibledata"></a></p>
+<h5 id="4311-uservisibledata---signature-message">4.3.1.1. userVisibleData - Signature Message</h5>
+<p>The Sign-method parameter <code>userVisibleData</code> holds data that will be signed by the user, but it is also displayed in the BankID application text box.</p>
+<p>If the <code>&lt;saml2p:AuthnRequest&gt;</code> message contains a <code>SignMessage</code> extension, the contents of this message MUST be assigned to the <code>userVisibleData</code> parameter (after necessary encoding).</p>
+<p>A BankID Identity Provider MUST support <code>SignMessage</code> elements having their <code>MimeType</code> attribute set to <code>text</code>, and SHOULD support Markdown (<code>text/markdown</code>) according to <a href="#bankid-md">BankID - Guidelines for Formatted Text</a>, [<a href="#bankid-md">BankID.MD</a>]. For other values (<code>text/html</code>), the Identity Provider MUST respond with an error.</p>
+<p>If the <code>&lt;saml2p:AuthnRequest&gt;</code> message does not contain a <code>SignMessage</code> extension, the Identity Provider MUST assign a sensible default signature message to the <code>userVisibleData</code> parameter. How this message is constructed is the responsibility of the Identity Provider, but it must be obvious for the user who is the requesting party, i.e., the Service Provider that has ordered the signature operation<sup>2</sup>.</p>
+<blockquote>
+<p>[1]: If the <code>MimeType</code> attribute is not set, <code>text</code> is the default value.</p>
+<p>[2]: For this purpose, the <code>&lt;mdui:DisplayName&gt;</code> element of the Signature Service’s metadata entry, is a good and generic choice.</p>
+</blockquote>
+<p><a name="usernonvisibledata"></a></p>
+<h5 id="4312-usernonvisibledata">4.3.1.2. userNonVisibleData</h5>
+<p>In order to produce a BankID signature that contains a binding to the <code>&lt;saml2p:AuthnRequest&gt;</code> message that initiated this signature, a BankID Identity Provider compliant to this profile MUST assign the  <code>userNonVisibleData</code> parameter with data that uniquely binds the signature to the <code>&lt;saml2p:AuthnRequest&gt;</code> message.</p>
+<p>It is RECOMMENDED that the following function is used to produce this unique binding:</p>
+<pre class="hljs"><code><span class="hljs-constructor">Base64Encode(<span class="hljs-string">&quot;entityID=&quot;</span> + URLEncode(&lt;<span class="hljs-params">entityID</span> <span class="hljs-params">of</span> SP&gt;)</span> + <span class="hljs-string">&quot;;&quot;</span> + <span class="hljs-string">&quot;authnRequestID=&quot;</span> + <span class="hljs-constructor">URLEncode(&lt;ID <span class="hljs-params">of</span> AuthnRequest&gt;)</span>)</code></pre><p><a name="authentication-responses"></a></p>
+<h2 id="5-authentication-responses">5. Authentication Responses</h2>
+<p><a name="attribute-release-rules"></a></p>
+<h3 id="51-attribute-release-rules">5.1. Attribute Release Rules</h3>
+<p>Section <a href="#attribute-transformation">2.1</a>, &quot;<a href="#attribute-transformation">Attribute Transformation</a>&quot;, specifies how BankID attributes should be transformed into SAML attributes defined in [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]. However, it does not specify the attribute release rules stating which attributes that are to be released based on a particular request.</p>
+<p>A BankID Identity Provider compliant to the Swedish eID Framework MUST honor the attribute release rules specified in section 6.2.1, &quot;Attribute Release Rules&quot;, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. This section further extends these rules with the following:</p>
+<ul class="list">
+<li>A BankID Identity Provider SHOULD include the <code>transactionIdentifier</code>-attribute (a mapping of the BankID <code>orderRef</code>-attribute) in the <code>&lt;saml2:AttributeStatement&gt;</code> element independently of which attribute set that is requested. This attribute links the BankID operation to the assertion.</li>
+<li>It is RECOMMENDED that a BankID Identity Provider includes the <code>userSignature</code>-attribute (containing the BankID signature) in the <code>&lt;saml2:AttributeStatement&gt;</code> element when a BankID signature operation has been performed.</li>
+<li>Unless explicitly required<sup>1</sup> by the Service Provider the Identity Provider SHOULD NOT release any other attributes than those specified by the current attribute set(s)<sup>2</sup>.</li>
+</ul>
+<blockquote>
+<p>[1]: A Service Provider explicitly requests attributes by declaring them as requested attributes in the <code>&lt;md:AttributeConsumingService&gt;</code> element of the Service Provider&#39;s metadata entry. See section <a href="#service-providers">6.1</a>.</p>
+</blockquote>
+<blockquote>
+<p>[2]: Based on the service entity categories that a Service Provider has declared in its metadata, an Identity Provider derives which attribute sets to apply during attribute release.</p>
+</blockquote>
+<p><a name="error-responses"></a></p>
+<h3 id="52-error-responses">5.2. Error Responses</h3>
+<p>A BankID Identity Provider MUST map errors received from the underlying BankID-server into SAML error response messages where the top level status code is either:</p>
+<ul class="list">
+<li><code>urn:oasis:names:tc:SAML:2.0:status:Requester</code> - for errors that are due to authentication or signature failures or faults due to an error on the part of the Service Provider,</li>
+<li><code>urn:oasis:names:tc:SAML:2.0:status:Responder</code> - for errors that are due to an internal, or technical, error in the BankID-server or Identity Provider.</li>
+</ul>
+<p>Before a <code>&lt;saml2p:Response&gt;</code> message is posted back to the Service Provider the Identity Provider MUST display a relevant error message to the user.</p>
+<p>It is RECOMMENDED that authentication/signature errors and failures to start the BankID client are represented using the second level status code <code>urn:oasis:names:tc:SAML:2.0:status:AuthnFailed</code>.</p>
+<p>If the user cancels a BankID operation, either by clicking the Cancel-button in the Identity Provider user interface or the Cancel-button in the BankID app/Security Application, the Identity Provider SHOULD respond with a <code>&lt;saml2p:Response&gt;</code> message where the second level status code is <code>http://id.elegnamnden.se/status/1.0/cancel</code>.</p>
+<p>In cases where the Identity Provider receives the BankID error code <code>ALREADY_IN_PROGRESS</code> in response to an Auth- or Sign-call the Identity Provider MAY display a warning to the user that someone may have initiated a BankID operation using their personal identity number<sup>1</sup>. If this warning is displayed, it is RECOMMENDED that the second level status code <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> is included in the error response message posted back to the Service Provider.</p>
+<blockquote>
+<p>[1]: There have been reports where fraudsters remotely try to convince people of using their Mobile BankID to log in to a service. In these cases, the fraudster initiates a BankID authentication prior to the person he tries to trick into logging in to the service, and is waiting for the user to enter his or hers personal code, thus authenticating the fraudster&#39;s session. </p>
+</blockquote>
+<p><a name="metadata"></a></p>
+<h2 id="6-metadata">6. Metadata</h2>
+<p>This section extends section 2 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] with requirements specific for BankID.</p>
+<p><a name="service-providers"></a></p>
+<h3 id="61-service-providers">6.1. Service Providers</h3>
+<p>As stated in section <a href="#attribute-release-rules">5.1</a>, &quot;<a href="#attribute-release-rules">Attribute Release Rules</a>&quot;, a Service Provider may request additional attributes, other than those implicitly requested via the use of service entity categories, by declaring requested attributes under the <code>&lt;md:AttributeConsumingService&gt;</code> element.</p>
+<pre class="hljs"><code>&lt;<span class="hljs-built_in">md</span>:AttributeConsumingService index=<span class="hljs-string">&quot;0&quot;</span> isDefault=<span class="hljs-string">&quot;true&quot;</span> xmlns:<span class="hljs-built_in">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>&gt;
+  &lt;<span class="hljs-built_in">md</span>:ServiceName xmlns:xml=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> xml:lang=<span class="hljs-string">&quot;sv&quot;</span>&gt;E<span class="hljs-literal">-myndigheten</span>&lt;/<span class="hljs-built_in">md</span>:ServiceName&gt;
+  &lt;<span class="hljs-built_in">md</span>:ServiceName xmlns:xml=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> xml:lang=<span class="hljs-string">&quot;en&quot;</span>&gt;The e<span class="hljs-literal">-Authority</span>&lt;/<span class="hljs-built_in">md</span>:ServiceName&gt;
+  ...
+  &lt;<span class="hljs-built_in">md</span>:RequestedAttribute Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.2&quot;</span> isRequired=<span class="hljs-string">&quot;false&quot;</span>/&gt;
+  &lt;<span class="hljs-built_in">md</span>:RequestedAttribute Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.13&quot;</span> isRequired=<span class="hljs-string">&quot;false&quot;</span>/&gt;      
+&lt;/<span class="hljs-built_in">md</span>:AttributeConsumingService&gt;</code></pre><p><em>Example of how a Service Provider declares that it wishes to receive the transactionIdentifier and authServerSignature attributes in assertions.</em></p>
+<p>A Service Provider requesting an attribute that is not supported by all Identity Providers that it may communicate with MUST NOT set the <code>isRequired</code> attribute of the <code>&lt;md:RequestedAttribute&gt;</code> element to <code>true</code>.</p>
+<p>It is RECOMMENDED that Service Providers communicating with BankID Identity Providers include the <code>transactionIdentifier</code> attribute as a requested attribute.</p>
+<p><a name="identity-providers"></a></p>
+<h3 id="62-identity-providers">6.2. Identity Providers</h3>
+<p>A BankID Identity Provider MUST require authentication request messages to be signed. This is indicated by assigning the <code>WantAuthnRequestsSigned</code> attribute of the <code>&lt;md:IDPSSPDescriptor&gt;</code> element to a value of <code>true</code>. </p>
+<p>A BankID Identity Provider SHOULD declare the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element containing the attribute name for personalIdentityNumber (<code>urn:oid:1.2.752.29.4.13</code>) and include it in its metadata entry as described in section 2.1.3 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. </p>
+<p>Using this extension the Identity Provider announces that the requestor should send the personal identity number in the authentication request if this is known to the requestor. In this way, the Identity Provider does not have to prompt the user for the personal identity number for the use cases where this is required.</p>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">&quot;true&quot;</span>
+     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:protocol&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:ui&quot;</span>&gt;</span>
+      ...
+    <span class="hljs-tag">&lt;/<span class="hljs-name">mdui:UIInfo</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:RequestedPrincipalSelection</span> 
+         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span> /&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">psc:RequestedPrincipalSelection</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;signing&quot;</span>&gt;</span>
+    ...</code></pre><p><em>Example of how the Identity Provider declares the <code>RequestedPrincipalSelection</code> extension in its metadata.</em></p>
+<p>Also, since a BankID Identity Provider MUST support the display of BankID QR codes, it MUST declare this in its metadata using the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category. See [<a href="#sc-saml-entcat">SC.SAML.EntCat</a>].</p>
+<p>It is RECOMMENDED that the BankID Identity Provider supports the <code>&lt;umsg:UserMessage&gt;</code> authentication request extension as defined in [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>]. Support for this extension is declared by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category. See [<a href="#sc-saml-entcat">SC.SAML.EntCat</a>].</p>
+<p><a name="signature-services"></a></p>
+<h3 id="63-signature-services">6.3. Signature Services</h3>
+<p>It is RECOMMENDED that a Signature Service explicitly requires release of the <code>userSignature</code> attribute (<code>urn:oid:1.2.752.201.3.11</code>) in assertions. The reason for this is that the BankID-signature may then be part of the assertion that is included in the resulting signature created by the Signature Service giving a non-repudiation proof of the BankID signature process.</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:AttributeConsumingService</span> <span class="hljs-attr">index</span>=<span class="hljs-string">&quot;0&quot;</span> <span class="hljs-attr">isDefault</span>=<span class="hljs-string">&quot;true&quot;</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&quot;sv&quot;</span>&gt;</span>E-myndighetens underskriftstjänst<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&quot;en&quot;</span>&gt;</span>The e-Authority&#x27;s Signing Service<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
+  ...
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:RequestedAttribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.11&quot;</span> <span class="hljs-attr">isRequired</span>=<span class="hljs-string">&quot;false&quot;</span>/&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">md:AttributeConsumingService</span>&gt;</span></code></pre><p><em>Example of how the userSignature attribute is explicitly required.</em></p>
+<p><a name="references"></a></p>
+<h2 id="7-references">7. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="saml2meta"></a>
+<strong>[SAML2Meta]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">OASIS Standard, Metadata for the OASIS Security Assertion Markup
+Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="saml2metaattr"></a>
+<strong>[SAML2MetaAttr]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html">OASIS Committee Specification, SAML V2.0 Metadata Extension for
+Entity Attributes Version 1.0, August
+2009</a>.</p>
+</blockquote>
+<p><a name="bankid-md"></a>
+<strong>[BankID.MD]</strong></p>
+<blockquote>
+<p><a href="https://www.bankid.com/utvecklare/guider/formatera-text">BankID - Guidelines for Formatting Text</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-attrs"></a>
+<strong>[SC.SAML.Attrs]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-entcat"></a>
+<strong>[SC.SAML.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-saml-principal"></a>
+<strong>[SC.SAML.Principal]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="sc-saml-umsg"></a>
+<strong>[SC.SAML.UMsg]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="8-changes-between-versions">8. Changes between versions</h2>
+<p><strong>Changes between version 1.3 and 1.4</strong></p>
+<ul class="list">
+<li><p>New references to BankID resources are used, since BankID has abandoned its &quot;Relying Party Guidelines&quot;-document.</p>
+</li>
+<li><p>The discussions concerning QR-codes vs. prompting for personal ID number has been removed, since QR-code now is mandatory for the use case where the user agent and mobile phone are on different devices.</p>
+</li>
+<li><p>Section 2.1, &quot;Attribute Transformation&quot;, was updated to reflect changes in the BankID API.</p>
+</li>
+<li><p>A recommendation to support the &quot;User Message Extension&quot; was added to section 3, &quot;Identity Provider User Interface&quot;.</p>
+</li>
+<li><p>Section 3.3, &quot;Mobile BankID on another Device&quot;, was removed since personal identity number prompting is no longer allowed.</p>
+</li>
+<li><p>Section 4.2, &quot;Handling of Principal Selection&quot;, was introduced.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.2 and 1.3:</strong></p>
+<ul class="list">
+<li>Section 4.2.1.1, &quot;userVisibleData - Signature Message&quot;, was updated with information about the usage of Markdown in visible sign data.</li>
+</ul>
+<p><strong>Changes between version 1.1 and 1.2:</strong></p>
+<ul class="list">
+<li><p>Section 1.4, &quot;Relying Party Configuration&quot;, was added. The section describes how a Service Provider,
+using the <code>secure-authenticator-binding</code> entity category, may request that QR codes are used to initiate BankID operations (which is a more secure process).</p>
+</li>
+<li><p>Section 3.3 was renamed from &quot;Prompting for Personal Identity Number&quot; to &quot;Mobile BankID on another Device&quot; and its contents was updated to add requirements of the use of QR codes.</p>
+</li>
+<li><p>Since the BankID API now includes a cancel-method section 3.4, &quot;Cancelling an Operation&quot;, was updated to require usage of this method if the user cancels the operation.</p>
+</li>
+<li><p>Sections 3.3 and 4.2.2 were updated with new recommendations and requirements for the <code>&lt;psc:PrincipalSelection&gt;</code> extension.</p>
+</li>
+<li><p>Section 6.2 was updated with a requirement that a BankID Identity Provider should include the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element in its metadata.</p>
+</li>
+<li><p>The recommendation in section 3.2 concerning handling of non default browsers was updated.</p>
+</li>
+<li><p>Section 4.2 was updated with a requirement that ensures that only the intended user sees a sign message.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.0 and 1.1:</strong></p>
+<ul class="list">
+<li>Section 3.4, &quot;Cancelling an Operation&quot; was extended with a suggestion of how to avoid dangling sessions after user cancel.</li>
+<li>The profile now references the BankID Relying Party Guidelines that makes use of JSON.</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/13_-_Signature_Activation_Protocol.html b/docs/december-2024/13_-_Signature_Activation_Protocol.html
new file mode 100644
index 0000000..a130cd2
--- /dev/null
+++ b/docs/december-2024/13_-_Signature_Activation_Protocol.html
@@ -0,0 +1,489 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Signature Activation Protocol for Federated Signing</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="signature-activation-protocol-for-federated-signing">Signature Activation Protocol for Federated Signing</h1>
+<h3 id="version-12---2024-12-04">Version 1.2 - 2024-12-04</h3>
+<p>Registration number: <strong>2019-317</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirement-keywords">Requirement keywords</a></p>
+<p> 1.2. <a href="#xml-namespace-references">XML namespace references</a></p>
+<p> 1.3. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#signature-activation-protocol"><strong>Signature Activation Protocol</strong></a></p>
+<p> 2.1. <a href="#scope">Scope</a></p>
+<p> 2.2. <a href="#data-exchange">Data Exchange</a></p>
+</li>
+<li><p><a href="#data-elements"><strong>Data elements</strong></a></p>
+<p> 3.1. <a href="#sadrequest">SADRequest</a></p>
+<p> 3.1.1. <a href="#syntax">Syntax</a></p>
+<p> 3.1.2. <a href="#example">Example</a></p>
+<p> 3.2. <a href="#signature-activation-data">Signature Activation Data</a></p>
+<p> 3.2.1. <a href="#sad-json-web-token">SAD JSON Web Token</a></p>
+<p> 3.2.1.1. <a href="#registered-jwt-claims">Registered JWT Claims</a></p>
+<p> 3.2.1.2. <a href="#sad-extension-claim">SAD Extension Claim</a></p>
+<p> 3.2.2. <a href="#example">Example</a></p>
+<p> 3.2.3 <a href="#verification-of-a-sad">Verification of a SAD</a></p>
+</li>
+<li><p><a href="#schemas"><strong>Schemas</strong></a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This document specifies a <strong>Signature Activation Protocol</strong> (SAP) and its data elements for implementation of <strong>Sole Control Assurance Level 2</strong> (SCAL2) according the European standards prEN 419241 - Trustworthy Systems Supporting Server Signing - Part 1 and 2 (prEN 419 241-1 [<a href="#rsig-pp-1">RSIG-PP-1</a>] and prEN 419 241-2 [<a href="#rsig-pp-2">RSIG-PP-2</a>]).</p>
+<p>The Signature Activation Protocol (SAP) defined in this document is used to exchange data between a signature service and a delegated authenticating authority such as a SAML Identity Provider. The function of the SAP is to authenticate the intent of a signer to sign a particular document, or collection of documents, through exchange of the following data elements.</p>
+<ul class="list">
+<li>Signature Activation Data (SAD) - Signed data, asserting the signer&#39;s agreement to sign specific data.</li>
+<li>SADRequest - Request for a SAD.</li>
+</ul>
+<p>The SAP specified in this document is specifically designed to be used with a signing service operating in accordance with the federated signing specification [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p><a name="requirement-keywords"></a></p>
+<h3 id="11-requirement-keywords">1.1. Requirement keywords</h3>
+<p>The keywords <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
+<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
+[<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify
+requirements over protocol features and behavior that affect the
+interoperability and security of implementations. When these words are
+not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="xml-namespace-references"></a></p>
+<h3 id="12-xml-namespace-references">1.2. XML namespace references</h3>
+<p>The prefix <strong>sap:</strong> stands for the Signature Activation Protocol XML Schema namespace <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code> (<a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCsigSAP-1.1.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCsigSAP-1.1.xsd</a>).</p>
+<p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion Schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
+<p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol Schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
+<p><a name="structure"></a></p>
+<h3 id="13-structure">1.3. Structure</h3>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;Eid2Element&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
+<code>OtherCode</code>.</p>
+<p><a name="signature-activation-protocol"></a></p>
+<h2 id="2-signature-activation-protocol">2. Signature Activation Protocol</h2>
+<p><a name="scope"></a></p>
+<h3 id="21-scope">2.1. Scope</h3>
+<p>The scope of the Signature Activation Protocol (SAP) is to support request for and delivery of the Signature Activation Data (SAD) to the Signature Activation Module (SAM). The SAM is a tamper resistant module inside the Remote Signing Service which validates the SAD in order to ensure that:</p>
+<ul class="list">
+<li>the signer is properly authenticated,</li>
+<li>the signer agrees to sign the data to be signed, and,</li>
+<li>the correct signing key for this signer and this instance of signing is properly identified.</li>
+</ul>
+<p>The federated signing model does not use pre-assigned signing keys. Instead, a new signing key is generated for each sign request and then permanently deleted. This particular use-case is recognised by prEN 419 241-1 [<a href="#rsig-pp-1">RSIG-PP-1</a>] and prEN 419 241-2 [<a href="#rsig-pp-2">RSIG-PP-2</a>], which under these conditions allows the signature key reference to be implicit and derived from the signer&#39;s identity. For the present implementation of the SAP the following data is included in the SAD:</p>
+<ul class="list">
+<li>the signer&#39;s identity,</li>
+<li>information about how the signer was authenticated and by whom, and,</li>
+<li>reference to the signature request, binding this instance of authentication to the specific instance of signing, the data being signed and the agreement to sign.</li>
+</ul>
+<p>This implements the scenario where the Identity Provider is the sole entity which can verify the signer&#39;s private credentials via the SIC (Signer’s Interaction Component). This instance of authentication is used by the Identity Provider to generate the SAD in accordance with section 5.10 of [<a href="#rsig-pp-1">RSIG-PP-1</a>].</p>
+<p><a name="data-exchange"></a></p>
+<h3 id="22-data-exchange">2.2. Data exchange</h3>
+<p>This document specifies exchange of two data elements:</p>
+<ul class="list">
+<li><code>SADRequest</code></li>
+<li><code>SAD</code></li>
+</ul>
+<p>The <code>SADRequest</code> SHALL have the format defined in section <a href="#sadrequest">3.1</a>. When a Remote Signing Service request a SAD from the Identity Provider, it MUST include the <code>SADRequest</code> element as a request extension by including it as a child element to a <code>&lt;saml2p:Extensions&gt;</code> element in the <code>&lt;saml2p:AuthnRequest&gt;</code>.</p>
+<p>When an Identity Provider returns a SAD, as defined in section <a href="#signature-activation-data">3.2</a>, in a SAML Assertion, it MUST be included as a single string value of a <code>sad</code> attribute identified by the attribute name <code>urn:oid:1.2.752.201.3.12</code> as defined in the attribute specification [<a href="#eidattributes">EidAttributes</a>].</p>
+<p><a name="data-elements"></a></p>
+<h2 id="3-data-elements">3. Data elements</h2>
+<p>The SAD requested in the SAP binds the documents to be signed to the intent by the signer to sign. This is accomplished by the interaction of a number of independent information attributes and elements as follows:</p>
+<ul class="list">
+<li><strong>Sign request ID</strong>. Identifies the sign request for signing specific documents. This sign request is sent to the signing service from the service provider requesting the signature. The sign request bound by this identifier contains all detailed data about what is being signed.</li>
+<li><strong>LoA</strong>. The level of assurance declaration asserting the level of security used to authenticate the user.</li>
+<li><strong>Number of documents to sign</strong>. Ensures that the user is aware whether more than one document is being signed. This allows adaptations of the signing UI displayed by the Identity Provider.</li>
+<li><strong>Identity of the signer</strong>. Allows verification that the signature is bound to the appropriate signer.</li>
+<li><strong>SAD Request ID</strong>. Unique identifier for the <code>SADRequest</code> element. This identifier is later included in the SAD in order to accomplish a binding between the request and the issued SAD.</li>
+</ul>
+<p>The SAD request and the SAD specified in this section specifies the data that needs to be exchanged in addition to other protocol elements specified by SAML as well as the federated signing specification [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p><a name="sadrequest"></a></p>
+<h3 id="31-sadrequest">3.1. SADRequest</h3>
+<p><a name="syntax"></a></p>
+<h4 id="311-syntax">3.1.1. Syntax</h4>
+<p>The SAD Request is provided in a <code>&lt;sap:SADRequest&gt;</code> element. The element has the following elements and attributes:</p>
+<p><code>&lt;RequesterID&gt;</code> [Required]</p>
+<blockquote>
+<p>Specifies the SAML entityID of the requesting entity. The value for this element should be the same identifier as given in the <code>&lt;saml2:Issuer&gt;</code> element of the <code>&lt;saml2p:AuthnRequest&gt;</code> that encapsulates the <code>&lt;sap:SADRequest&gt;</code> extension.</p>
+</blockquote>
+<p><code>&lt;SignRequestID&gt;</code> [Required]</p>
+<blockquote>
+<p>Specifies the value of the <code>RequestID</code> attribute of the associated <code>SignRequest</code>.</p>
+</blockquote>
+<p><code>&lt;DocCount&gt;</code> [Required]</p>
+<blockquote>
+<p>The number of requested signatures in the associated sign request.</p>
+</blockquote>
+<p><code>&lt;RequestedVersion&gt;</code> [Optional Default=&quot;1.0&quot;]</p>
+<blockquote>
+<p>The requested version of the SAD.</p>
+</blockquote>
+<p><code>&lt;RequestParams&gt;</code> [Optional]</p>
+<blockquote>
+<p>Optional parameters provided as name-value pairs. This specification does not define any parameters. The use of parameters may be defined in profiles of this specification or may be negotiated by other means between a remote signing service and an Identity Provider.</p>
+</blockquote>
+<p><code>ID</code> [Required]</p>
+<blockquote>
+<p>Attribute holding a unique identifier for the <code>SADRequest</code>.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;sap:SADRequest&gt;</code> element:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SADRequest&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;sap:SADRequestType&quot;</span> /&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SADRequestType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequesterID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignRequestID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;DocCount&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:int&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedVersion&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> default=<span class="hljs-string">&quot;1.0&quot;</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestParams&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Parameter&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;sap:ParameterType&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;ID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:ID&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;ParameterType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="example"></a></p>
+<h4 id="312-example">3.1.2. Example</h4>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">sap:SADRequest</span> <span class="hljs-attr">ID</span>=<span class="hljs-string">&quot;_a74a068d0548a919e503e5f9ef901851&quot;</span> <span class="hljs-attr">xmlns:sap</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/sap/ns&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequesterID</span>&gt;</span>http://www.example.com/sigservice<span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequesterID</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">sap:SignRequestID</span>&gt;</span>f6e7d061a23293b0053dc7b038a04dad<span class="hljs-tag">&lt;/<span class="hljs-name">sap:SignRequestID</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">sap:DocCount</span>&gt;</span>1<span class="hljs-tag">&lt;/<span class="hljs-name">sap:DocCount</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequestedVersion</span>&gt;</span>1.0<span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequestedVersion</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequestParams</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">sap:Parameter</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;ParamName&quot;</span>&gt;</span>paramValue<span class="hljs-tag">&lt;/<span class="hljs-name">sap:Parameter</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequestParams</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">sap:SADRequest</span>&gt;</span></code></pre><p><em>Example of a SADRequest.</em></p>
+<p><a name="signature-activation-data"></a></p>
+<h3 id="32-signature-activation-data">3.2. Signature Activation Data</h3>
+<p><a name="sad-json-web-token"></a></p>
+<h4 id="321-sad-json-web-token">3.2.1. SAD JSON Web Token</h4>
+<p>This section specifies a JSON Web Token (JWT) in accordance with [<a href="#rfc7519">RFC7519</a>] as the SAD container, binding the data as defined in section <a href="#scope">2.1</a>.</p>
+<p>The SAD JWT MUST have the form of a signed JWS (JSON Web Signature).</p>
+<p><a name="registered-jwt-claims"></a></p>
+<h5 id="3211-registered-jwt-claims">3.2.1.1. Registered JWT Claims</h5>
+<p>The data signed by the SAD JWT is carried in the JWS payload in the form of JWT claims using registered claim names (as specified in [<a href="#rfc7519">RFC7519</a>]) in addition to one private claim name (<code>seElnSadext</code>) specified in section <a href="#sad-extension-claim">3.2.1.2</a>. The following table defines the use of registered claims.</p>
+<table>
+<thead>
+<tr>
+<th>name</th>
+<th>Content</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>sub</strong></td>
+<td>Subject - holds the attribute value of the signer&#39;s unique identifier.</td>
+</tr>
+<tr>
+<td><strong>aud</strong></td>
+<td>Audience - holds the entityID of the Signature Service which is the legitimate recipient of this SAD. This value corresponds to the <code>&lt;sap:RequesterID&gt;</code> element of the SAD request.</td>
+</tr>
+<tr>
+<td><strong>iss</strong></td>
+<td>Issuer - holds the entityID of the IdP that generated this SAD.</td>
+</tr>
+<tr>
+<td><strong>exp</strong></td>
+<td>Expiry - specifies the time when this SAD is no longer valid (epoch time/seconds since 1970-01-01).</td>
+</tr>
+<tr>
+<td><strong>iat</strong></td>
+<td>Issued At - specifies the time when this SAD was issued (epoch time/seconds since 1970-01-01).</td>
+</tr>
+<tr>
+<td><strong>jti</strong></td>
+<td>Unique identifier of this SAD.</td>
+</tr>
+</tbody></table>
+<p><a name="sad-extension-claim"></a></p>
+<h5 id="3212-sad-extension-claim">3.2.1.2. SAD Extension Claim</h5>
+<p>A private claim name is defined in this specification which extends the registered claims with additional SAD data:</p>
+<blockquote>
+<p><code>seElnSadext</code></p>
+</blockquote>
+<p>The claim identified by this name has the value of a JSON object holding name-value pairs in accordance with the following table:</p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Type</th>
+<th>Content</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>ver</strong></td>
+<td>String</td>
+<td>The version of this claim, default 1.0 (Optional).</td>
+</tr>
+<tr>
+<td><strong>irt</strong></td>
+<td>String</td>
+<td>In Response To - holds the identifier of the SAD request (<code>ID</code> attribute) that was used to request this SAD.</td>
+</tr>
+<tr>
+<td><strong>attr</strong></td>
+<td>String</td>
+<td>Attribute - holds the URI identifier of the attribute specifying the users unique identifier value.</td>
+</tr>
+<tr>
+<td><strong>loa</strong></td>
+<td>String</td>
+<td>LevelOfAssurance - holds the URI identifier of the level of assurance (LoA) used to authenticate the signer.</td>
+</tr>
+<tr>
+<td><strong>reqid</strong></td>
+<td>String</td>
+<td>RequestID - holds the ID of the sign request associated with this SAD. Inclusion of this ID assert that the authenticated subject agrees to sign the docuements identified by this sign reqeust.</td>
+</tr>
+<tr>
+<td><strong>docs</strong></td>
+<td>Integer</td>
+<td>Specifies the number of documents to be signed in the associated sign request.</td>
+</tr>
+</tbody></table>
+<p><a name="example"></a></p>
+<h4 id="322-example">3.2.2. Example</h4>
+<p>The following example illustrates a claim binding the following claim values:</p>
+<p><strong>Registered Claims</strong></p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>sub</strong></td>
+<td><code>197802031877</code></td>
+</tr>
+<tr>
+<td><strong>aud</strong></td>
+<td><code>https://sandbox.swedenconnect.se/eid2cssp</code></td>
+</tr>
+<tr>
+<td><strong>iss</strong></td>
+<td><code>http://dev.test.swedenconnect.se/idp</code></td>
+</tr>
+<tr>
+<td><strong>exp</strong></td>
+<td><code>1666128029</code> (Oct 18, 2022, 23:20:29 CET)</td>
+</tr>
+<tr>
+<td><strong>iat</strong></td>
+<td><code>1666127729</code> (Oct 18, 2022, 23:15:29 CET)</td>
+</tr>
+<tr>
+<td><strong>jti</strong></td>
+<td><code>NbnmpGA1gwtL3AgtKPfe77Ia</code></td>
+</tr>
+</tbody></table>
+<p><strong>seElnSadext Claim</strong></p>
+<table>
+<thead>
+<tr>
+<th>Name</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>ver</strong></td>
+<td><code>1.0</code></td>
+</tr>
+<tr>
+<td><strong>irt</strong></td>
+<td><code>752c30b3-30c1-49f0-ab04-a28909dc3b67</code></td>
+</tr>
+<tr>
+<td><strong>attr</strong></td>
+<td><code>urn:oid:1.2.752.29.4.13</code></td>
+</tr>
+<tr>
+<td><strong>loa</strong></td>
+<td><code>http://id.elegnamnden.se/loa/1.0/loa3</code></td>
+</tr>
+<tr>
+<td><strong>reqid</strong></td>
+<td><code>70fabf30-d474-4d21-8463-2c6811005ce0</code></td>
+</tr>
+<tr>
+<td><strong>docs</strong></td>
+<td><code>4</code></td>
+</tr>
+</tbody></table>
+<p><strong>JWS Header</strong></p>
+<p>The Header of the JWS specifies that it is a JWT by the &quot;typ&quot; parameter and the signature algoritm through the &quot;alg&quot; parameter. In this example the header is <code>{&quot;typ&quot;:&quot;JWT&quot;,&quot;alg&quot;:&quot;RS256&quot;}</code>. The Base64 URL-encoded header is:</p>
+<blockquote>
+<p>eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9</p>
+</blockquote>
+<p><strong>JWS Payload</strong></p>
+<p>The JWS payload holding the JWT claims is represented by the following JSON object:</p>
+<pre class="hljs"><code>{
+    <span class="hljs-attr">&quot;sub&quot;</span>: <span class="hljs-string">&quot;197802031877&quot;</span>,
+    <span class="hljs-attr">&quot;aud&quot;</span>: <span class="hljs-string">&quot;https://sandbox.swedenconnect.se/eid2cssp&quot;</span>,
+    <span class="hljs-attr">&quot;iss&quot;</span>: <span class="hljs-string">&quot;http://dev.test.swedenconnect.se/idp&quot;</span>,
+    <span class="hljs-attr">&quot;exp&quot;</span>: <span class="hljs-number">1666128029</span>,
+    <span class="hljs-attr">&quot;iat&quot;</span>: <span class="hljs-number">1666127729</span>,
+    <span class="hljs-attr">&quot;jti&quot;</span>: <span class="hljs-string">&quot;NbnmpGA1gwtL3AgtKPfe77Ia&quot;</span>,
+    <span class="hljs-attr">&quot;seElnSadext&quot;</span>: {
+        <span class="hljs-attr">&quot;ver&quot;</span>: <span class="hljs-string">&quot;1.0&quot;</span>,
+        <span class="hljs-attr">&quot;irt&quot;</span>: <span class="hljs-string">&quot;752c30b3-30c1-49f0-ab04-a28909dc3b67&quot;</span>,
+        <span class="hljs-attr">&quot;attr&quot;</span>: <span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span>,
+        <span class="hljs-attr">&quot;loa&quot;</span>: <span class="hljs-string">&quot;http://id.elegnamnden.se/loa/1.0/loa3&quot;</span>,
+        <span class="hljs-attr">&quot;reqid&quot;</span>: <span class="hljs-string">&quot;70fabf30-d474-4d21-8463-2c6811005ce0&quot;</span>,
+        <span class="hljs-attr">&quot;docs&quot;</span>: <span class="hljs-number">4</span>
+    }
+}
+</code></pre><p>This payload is represented by the following Base64 URL-encoded string:</p>
+<blockquote>
+<p>eyJzdWIiOiIxOTc4MDIwMzE4NzciLCJhdWQiOiJodHRwczovL3NhbmRib3guc3dlZGVuY29ubmVjdC5zZS9laWQyY3NzcCIsImlzcyI6Imh0dHA6Ly9kZXYudGVzdC5zd2VkZW5jb25uZWN0LnNlL2lkcCIsImV4cCI6MTY2NjEyODAyOSwiaWF0IjoxNjY2MTI3NzI5LCJqdGkiOiJOYm5tcEdBMWd3dEwzQWd0S1BmZTc3SWEiLCJzZUVsblNhZGV4dCI6eyJ2ZXIiOiIxLjAiLCJpcnQiOiI3NTJjMzBiMy0zMGMxLTQ5ZjAtYWIwNC1hMjg5MDlkYzNiNjciLCJhdHRyIjoidXJuOm9pZDoxLjIuNzUyLjI5LjQuMTMiLCJsb2EiOiJodHRwOi8vaWQuZWxlZ25hbW5kZW4uc2UvbG9hLzEuMC9sb2EzIiwicmVxaWQiOiI3MGZhYmYzMC1kNDc0LTRkMjEtODQ2My0yYzY4MTEwMDVjZTAiLCJkb2NzIjo0fX0</p>
+</blockquote>
+<p><strong>JWT</strong></p>
+<p>The complete SAD JWT including signature:</p>
+<blockquote>
+<p>eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxOTc4MDIwMzE4NzciLCJhdWQiOiJodHRwczovL3NhbmRib3guc3dlZGVuY29ubmVjdC5zZS9laWQyY3NzcCIsImlzcyI6Imh0dHA6Ly9kZXYudGVzdC5zd2VkZW5jb25uZWN0LnNlL2lkcCIsImV4cCI6MTY2NjEyODAyOSwiaWF0IjoxNjY2MTI3NzI5LCJqdGkiOiJOYm5tcEdBMWd3dEwzQWd0S1BmZTc3SWEiLCJzZUVsblNhZGV4dCI6eyJ2ZXIiOiIxLjAiLCJpcnQiOiI3NTJjMzBiMy0zMGMxLTQ5ZjAtYWIwNC1hMjg5MDlkYzNiNjciLCJhdHRyIjoidXJuOm9pZDoxLjIuNzUyLjI5LjQuMTMiLCJsb2EiOiJodHRwOi8vaWQuZWxlZ25hbW5kZW4uc2UvbG9hLzEuMC9sb2EzIiwicmVxaWQiOiI3MGZhYmYzMC1kNDc0LTRkMjEtODQ2My0yYzY4MTEwMDVjZTAiLCJkb2NzIjo0fX0.Qn-K-5V5-979GMITVSXgqWOrSVQfYFUMLv0P8PLUMSZzF6s6Zk05SOztH3XGN-4AjmjQeBHcqylpzoqG26eIXW7kuJZB9zodhAyTcvOogQj62XUFsoun5wfWpou8v8-Cpw1G4cwFZdMKt-oRbN43ViZ8u7EIZHBjzYMxfJNgMv2YGmzMQDPQLmtIW-f_O0nE_NPcFsaweYGJXcEWxi7fE3wzNnOR2rPBgQ3L0oehF2mP9dhenlptKrugH6Ru6eLZH66yFaAtR5RRA2m1wh2fXnwXJWO0-8jrvIZiZ9GLDt9W0r1Hs5Le--KPeuPcStli0nIi5YVLoAiGUaHc-Eb_DILwdqYpHS6mxJL3lb8j8u5JsIdEj9FEpqD8MlCbVM4HaWDL_wIiU16QVUOrxPUjoo3wyxLYhW6x3WnQ2an8fhIgahck7m9gS6_rVHKG1OAL_jn4h5jZzP-gX9yZeNcfTmhSiEdwrObydZ4dKx7JGEbmKn4EK1-8Pc65SOj9Zg5jTsRsl6uo9dMoJ-35Tb-x5IKsGs9Y1_94NCuqJH_a7HgC8nORfHBDOTPjzG008FLEFHSRmql6hYSYEd9F3kvR5816KixZpLT_BEED1m4RNdufa8nYEgEroi6X_AvmjpZKiwXCgnJyW6_80IIV89EMViiQ-BjTSSt8AK5KxxpTLkA</p>
+</blockquote>
+<p><a name="verification-of-a-sad"></a></p>
+<h4 id="323-verification-of-a-sad">3.2.3. Verification of a SAD</h4>
+<p>The recipient of a requested SAD MUST verify it as part of the SAML response processing by asserting the following:</p>
+<ul class="list">
+<li> That the signature of the SAD JWT verifies correctly using the signature certificate of the issuing Identity Provider (found in the Identity Provider metadata).</li>
+<li> That the version of the SAD (<code>seElnSadext.ver</code>) matches the <code>&lt;sap:RequestedVersion&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>.</li>
+<li> That the audience (<code>aud</code>) matches the entityID of the recipient, i.e., matches the <code>&lt;sap:RequesterID&gt;</code> element from the <code>&lt;sap:SADRequest&gt;</code>.</li>
+<li> That the issuer (<code>iss</code>) value matches the issuer entityID of the assertion containing the SAD (*).</li>
+<li> That the SAD is valid by checking the expiry (<code>exp</code>) and issued-at (<code>iat</code>) values (allowing for a reasonable clock skew).</li>
+<li> That the in-response-to (<code>seElnSadExt.irt</code>) value matches that <code>ID</code> of the corresponding <code>&lt;sap:SADRequest&gt;</code>.</li>
+<li> That the subject (<code>sub</code>) value is also represented in the SAML assertion as an attribute having the name given by the <code>seElnSadExt.attr</code> field.</li>
+<li> That the level of assurance (<code>seElnSadEx.loa</code>) value matches the value given in the <code>&lt;saml2:AuthnContextClassRef&gt;</code> element of the assertion.</li>
+<li> That the request ID (<code>seElnSadEx.reqid</code>) value matches the ID for the sign request (which is passed in the <code>&lt;sap:SignRequestID&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>).</li>
+<li> That the number of documents specified in the SAD (<code>seElnSadEx.docs</code>) matches the <code>&lt;sap:DocCount&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>.</li>
+</ul>
+<p>If any of the above verification steps fail, the Signature Service MUST reject the assertion.</p>
+<blockquote>
+<p>[*]: In the case where a Signature Service communicates with a Proxy Identity Provider that forwards requests to an <em>authenticating</em> Identity Provider that issues a SAD, the <code>iss</code>-value of the SAD will differ from the issuer of the assertion that is received by the Signature Service. In these cases the Signature Service should compare the <code>iss</code>-value with the value found in the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element of the assertion, or with relevant local policy and out-of-band configuration data.</p>
+</blockquote>
+<p><a name="schemas"></a></p>
+<h2 id="4-schemas">4. Schemas</h2>
+<p>The following XML schema defines the <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code> name space:</p>
+<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
+    targetNamespace=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/sap/ns&quot;</span>
+    xmln<span class="hljs-variable">s:sap</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/csig/1.1/sap/ns&quot;</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/csig/<span class="hljs-number">1.1</span>/EidCsigSAP-<span class="hljs-number">1.1</span>.xsd
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SADRequest&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;sap:SADRequestType&quot;</span> /&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;SADRequestType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequesterID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;SignRequestID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;DocCount&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:int&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedVersion&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> default=<span class="hljs-string">&quot;1.0&quot;</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> name=<span class="hljs-string">&quot;RequestParams&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+            &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Parameter&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;sap:ParameterType&quot;</span> minOccurs=<span class="hljs-string">&quot;0&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+          &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;ID&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:ID&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;ParameterType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
+<h2 id="5-normative-references">5. Normative References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="rfc7519"></a>
+<strong>[RFC7519]</strong></p>
+<blockquote>
+<p><a href="http://www.rfc-editor.org/info/rfc7519">Jones, M., Bradley, J., and N. Sakimura, &quot;JSON Web Token (JWT)&quot;, RFC 7519, DOI 10.17487/RFC7519, May 2015</a>.</p>
+</blockquote>
+<p><a name="eidattributes"></a>
+<strong>[EidAttributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="dss-ext"></a>
+<strong>[DSS-Ext]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
+</blockquote>
+<p><a name="rsig-pp-1"></a>
+<strong>[RSIG-PP-1]</strong></p>
+<blockquote>
+<p>European Standard prEN 419241-1 - Trustworthy Systems Supporting Server Signing - Part 1:
+General System Security Requirements</p>
+</blockquote>
+<p><a name="rsig-pp-2"></a>
+<strong>[RSIG-PP-2]</strong></p>
+<blockquote>
+<p>European Standard prEN 419241-2 - Trustworthy Systems Supporting Server Signing - Part 2:
+Protection profile for QSCD for Server Signing</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="6-changes-between-versions">6. Changes between versions</h2>
+<p><strong>Changes between version 1.1 and 1.2:</strong></p>
+<ul class="list">
+<li><p>The protocol logic was clarified by removing references to sign message (which was never present in the actual protocol) and replacing this with a clarification of the semantics of including the Sign Request ID in SAD to assert the acceptance to sign the documents referenced in that Sign Request.</p>
+</li>
+<li><p>Updated examples where the use of &quot;signmessage&quot; LoA URI:s was removed.</p>
+</li>
+<li><p>Updated broken links.</p>
+</li>
+</ul>
+<p><strong>Changes between version 1.0 and 1.1:</strong></p>
+<ul class="list">
+<li>The <code>RequestedVersion</code> element of the <code>SADRequestType</code> is now marked as optional in the schema definition.</li>
+</ul>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html b/docs/december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
new file mode 100644
index 0000000..887e865
--- /dev/null
+++ b/docs/december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
@@ -0,0 +1,234 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Principal Selection in SAML Authentication Requests</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</h1>
+<h3 id="version-10---2020-01-17">Version 1.0 - 2020-01-17</h3>
+<p>Registration number: <strong>2019-318</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2020. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.2. <a href="#xml-namespace-references">XML Namespace References</a></p>
+<p> 1.3. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#data-elements"><strong>Data elements</strong></a></p>
+<p> 2.1. <a href="#principalselection">PrincipalSelection</a></p>
+<p> 2.1.1. <a href="#matchvalue">MatchValue</a></p>
+<p> 2.2. <a href="#requestedprincipalselection">RequestedPrincipalSelection</a></p>
+</li>
+<li><p><a href="#examples"><strong>Examples</strong></a></p>
+<p> 3.1. <a href="#authentication-requests">Authentication Requests</a></p>
+<p> 3.2. <a href="#metadata-extension">Metadata Extension</a></p>
+</li>
+<li><p><a href="#schemas"><strong>Schemas</strong></a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>When a Service Provider requests authentication of a user (principal), the Service Provider may have prior knowledge about the user to be authenticated, for example, when re-authenticating an already authenticated user, or when a user authenticates to a signature service where the user signs a document in a context where he or she already has been authenticated.</p>
+<p>This specification defines the <code>&lt;psc:PrincipalSelection&gt;</code> element that may be included in the <code>&lt;saml2p:Extensions&gt;</code> element of a SAML <code>&lt;saml2p:AuthnRequest&gt;</code> where the requesting Service Provider can specify matching criteria that may be used by the Identity Provider to select the particular user that should be authenticated.</p>
+<p>The specification also defines the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element that should be used by Identity Providers that may need information about a known user in order to avoid prompting for the user ID<sup>1</sup>. The element should be included as an extension in the Identity Provider metadata under the <code>&lt;md:IDPSSODescriptor&gt;</code> element.</p>
+<p>Even though the main purpose of the <code>&lt;psc:PrincipalSelection&gt;</code> extension is to aid the Identity Provider
+in selecting a particular subject for the authentication, an Identity Provider MAY also compare the match 
+values present in the extension with the resulting attributes from the user authentication, and in case of a 
+mismatch, respond with an error. In these cases the second-level SAML status code MUST be set to
+<code>urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal</code> [<a href="#saml2core">SAML2Core</a>].</p>
+<blockquote>
+<p>[1]: The typical use case is when a user once has authenticated for a service and provided his or hers user ID to the Identity Provider, and is about to perform a signature. If the Identity Provider prompts the user for the user ID once again the user experience is poor and the Service Provider will receive customer complaints.</p>
+</blockquote>
+<p><a name="requirements-notation"></a></p>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
+<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
+[<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="xml-namespace-references"></a></p>
+<h3 id="12-xml-namespace-references">1.2. XML Namespace References</h3>
+<p>The prefix <strong>psc:</strong> stands for the Principal Selection Criteria XML schema namespace <code>http://id.swedenconnect.se/authn/1.0/principal-selection/ns</code>. </p>
+<p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
+<p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
+<p>The prefix <strong>md:</strong> stands for the OASIS SAML 2 Metadata schema namespace <code>urn:oasis:names:tc:SAML:2.0:metadata</code>.</p>
+<p><a name="structure"></a></p>
+<h3 id="13-structure">1.3. Structure</h3>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;LocalElement&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
+<code>OtherCode</code>.</p>
+<p><a name="data-elements"></a></p>
+<h2 id="2-data-elements">2. Data elements</h2>
+<p>This specification defines the element <code>&lt;PrincipalSelection&gt;</code> to be included in the <code>&lt;Extensions&gt;</code> element of an <code>AuthnRequest</code>. </p>
+<p>This element MAY be used by an Identity Provider to select the subject to authenticate. </p>
+<p><a name="principalselection"></a></p>
+<h3 id="21-principalselection">2.1. PrincipalSelection</h3>
+<p>The Principal Selection Criteria is provided in a <code>&lt;PrincipalSelection&gt;</code> element. The element has the following elements and attributes:</p>
+<p><code>&lt;MatchValue&gt;</code> [One or more]</p>
+<blockquote>
+<p>This element holds values that MAY be used by the Identity Provider to match against a principal to be authenticated.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;PrincipalSelection&gt;</code> element:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;PrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span>/&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PrincipalSelectionType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> name=<span class="hljs-string">&quot;MatchValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:MatchValueType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span>/&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="matchvalue"></a></p>
+<h4 id="211-matchvalue">2.1.1 MatchValue</h4>
+<p>The <code>&lt;MatchValue&gt;</code> element contains a string value to be matched against the selected principal. This element has the following attributes which determines the meaning of the match value:</p>
+<p><code>Name</code> [Required]</p>
+<blockquote>
+<p>The identifying name of the type of identifier value expressed in the <code>MatchValue</code> element. This is analogous to the <code>Name</code> attribute of a SAML <code>&lt;saml2:Attribute&gt;</code> element.</p>
+</blockquote>
+<p><code>NameFormat</code> [Default <code>urn:oasis:names:tc:SAML:2.0:attrname-format:uri</code>]</p>
+<blockquote>
+<p>Attribute specifying the format of the <code>Name</code> attribute value. This attribute is analogous to the <code>NameFormat</code> attribute of a SAML <code>&lt;saml2:Attribute&gt;</code> element.</p>
+</blockquote>
+<p><code>##any</code> [Optional]</p>
+<blockquote>
+<p>Extension point for any attribute in accordance with local conventions and future specifications.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;MatchValueType&gt;</code> complex type:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MatchValueType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;NameFormat&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span>
+          default=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span>/&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="requestedprincipalselection"></a></p>
+<h3 id="22-requestedprincipalselection">2.2. RequestedPrincipalSelection</h3>
+<p>An Identity Provider uses the <code>&lt;RequestedPrincipalSelection&gt;</code> element to declare that it wishes to receive the <code>&lt;PrincipalSelection&gt;</code> extension element in authentication requests. The contained <code>MatchValue</code> elements should contain no values, only the attribute name of a <code>MatchValue</code> element is relevant to declare which attributes of a known user that is interest for the Identity Provider.</p>
+<p>The following schema fragment defines the <code>&lt;RequestedPrincipalSelection&gt;</code> element:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:RequestedPrincipalSelectionType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelectionType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="examples"></a></p>
+<h2 id="3-examples">3. Examples</h2>
+<p>Attributes in the examples below are specified in [<a href="#eidattributes">EidAttributes</a>].</p>
+<p><a name="authentication-requests"></a></p>
+<h3 id="31-authentication-requests">3.1. Authentication Requests</h3>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span>&gt;</span>197309069289<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">psc:PrincipalSelection</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
+...</code></pre><p>Example of a <code>PrincipalSelection</code> specifying a Swedish personal identity number (personnummer) as match attribute.</p>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span>&gt;</span>198906059483<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.4&quot;</span>&gt;</span>NO:05068907693<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">psc:PrincipalSelection</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
+...</code></pre><p>Example of a <code>PrincipalSelection</code> specifying two alternative matching policies. The first policy specifies a Swedish personal identity number (personnummer) and the second specifies a ProvisionalID attribute.</p>
+<p><a name="metadata-extension"></a></p>
+<h3 id="32-metadata-extension">3.2. Metadata Extension</h3>
+<pre class="hljs"><code>...
+<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">&quot;true&quot;</span>
+     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:protocol&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:ui&quot;</span>&gt;</span>
+      ...
+    <span class="hljs-tag">&lt;/<span class="hljs-name">mdui:UIInfo</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:RequestedPrincipalSelection</span> 
+         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span> /&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">psc:RequestedPrincipalSelection</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;signing&quot;</span>&gt;</span>
+    ...</code></pre><p>Example of how an Identity Provider advertises, it its metadata, that it wishes to receive the Swedish personal identity number (personnummer) of the user in a <code>&lt;PrincipalSelection&gt;</code> extension element of the authentication request if this information is known to the requestor.</p>
+<p><a name="schemas"></a></p>
+<h2 id="4-schemas">4. Schemas</h2>
+<p>The following XML schema defines the <code>http://id.swedenconnect.se/authn/1.0/principal-selection/ns</code> namespace:</p>
+<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
+  targetNamespace=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>
+  xmln<span class="hljs-variable">s:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/authn/<span class="hljs-number">1.0</span>/PrincipalSelection-<span class="hljs-number">1.0</span>.xsd
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;PrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PrincipalSelectionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;MatchValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:MatchValueType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:RequestedPrincipalSelectionType&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelectionType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MatchValueType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;NameFormat&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> 
+            default=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> /&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+  
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
+<h2 id="5-normative-references">5. Normative References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="eidattributes"></a>
+<strong>[EidAttributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="6-changes-between-versions">6. Changes between versions</h2>
+<p>This is the first version of this specification.</p>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html b/docs/december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
new file mode 100644
index 0000000..c3906c6
--- /dev/null
+++ b/docs/december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
@@ -0,0 +1,220 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>User Message Extension in SAML Authentication Requests</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="user-message-extension-in-saml-authentication-requests">User Message Extension in SAML Authentication Requests</h1>
+<h3 id="version-10---2024-12-04">Version 1.0 - 2024-12-04</h3>
+<p>Registration number: <strong>2024-7673</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
+<p> 1.2. <a href="#xml-namespace-references">XML Namespace References</a></p>
+<p> 1.3. <a href="#structure">Structure</a></p>
+</li>
+<li><p><a href="#data-elements"><strong>Data elements</strong></a></p>
+</li>
+<li><p><a href="#usage-requirements"><strong>Usage Requirements</strong></a></p>
+<p> 3.1. <a href="#identity-provider-requirements">Identity Provider Requirements</a></p>
+<p> 3.2. <a href="#service-provider-requirements">Service Provider Requirements</a></p>
+</li>
+<li><p><a href="#examples"><strong>Examples</strong></a></p>
+</li>
+<li><p><a href="#schemas"><strong>Schemas</strong></a></p>
+</li>
+<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>When a Service Provider requests authentication of a user, the Service Provider may want to pass a message along for the user to see during the authentication phase at the Identity Provider. Normally, an Identity Provider displays information about the requesting Service Provider for the user based on the registered presentation data from the SP&#39;s SAML metadata entry. This information is static and its purpose is to show for the user that he or she is still in the context of the Service Provider.</p>
+<p>By using dynamic user messages to be displayed at the Identity Provider side (possibly in an authentication device such as a mobile phone), the Service Provider may further strengthen the coupling to its current context. Examples of messages can be information about the purpose of the authentication or warnings and prompts for the user to not authenticate based on another person&#39;s request. </p>
+<p>This specification defines the <code>&lt;umsg:UserMessage&gt;</code> element that may be included in the <code>&lt;saml2p:Extensions&gt;</code> element of a SAML <code>&lt;saml2p:AuthnRequest&gt;</code> where the requesting Service Provider can specify a message text that is to be displayed by the Identity Provider during the user authentication process.</p>
+<p><a name="requirements-notation"></a></p>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The keywords <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
+<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
+[<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="xml-namespace-references"></a></p>
+<h3 id="12-xml-namespace-references">1.2. XML Namespace References</h3>
+<p>The prefix <strong>umsg:</strong> stands for the User Message Extension XML schema namespace <code>http://id.swedenconnect.se/authn/1.0/user-message/ns</code>. </p>
+<p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
+<p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
+<p>The prefix <strong>md:</strong> stands for the OASIS SAML 2 Metadata schema namespace <code>urn:oasis:names:tc:SAML:2.0:metadata</code>.</p>
+<p><a name="structure"></a></p>
+<h3 id="13-structure">1.3. Structure</h3>
+<p>This specification uses the following typographical conventions in text:
+<code>&lt;LocalElement&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
+<code>OtherCode</code>.</p>
+<p><a name="data-elements"></a></p>
+<h2 id="2-data-elements">2. Data elements</h2>
+<p>This specification defines the element <code>&lt;UserMessage&gt;</code> to be included in the <code>&lt;Extensions&gt;</code> element of an <code>AuthnRequest</code>. </p>
+<p>This element MAY be included by a Service Provider asking the Identity Provider to display a given message for the user during the authentication phase. The element has the following elements and attributes:</p>
+<p><code>&lt;Message&gt;</code> [One or more]</p>
+<blockquote>
+<p>Element that holds the user message for a specific language. See below.</p>
+</blockquote>
+<p><code>mimeType</code></p>
+<blockquote>
+<p>The MIME type for the text contained in all <code>Message</code> elements. This specification defines two possible values that are <code>text/plain</code> (where ;charset=UTF-8 is an implicit condition) and <code>text/markdown</code><sup>1</sup>. If no value is given for this field, <code>text/plain</code> MUST be assumed. Other profiles MAY add support for additional MIME types.</p>
+</blockquote>
+<p>The following schema fragment defines the <code>&lt;UserMessage&gt;</code> element:</p>
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;UserMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:UserMessageType&quot;</span>/&gt;
+
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;UserMessageType&quot;</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:MessageType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span>/&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;mimeType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> default=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;The format of the user message(s)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p>The <code>&lt;Message&gt;</code> element is defined by the following schema definition:</p>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">xs:complexType</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;MessageType&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">xs:extension</span> <span class="hljs-attr">base</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">xs:attribute</span> <span class="hljs-attr">ref</span>=<span class="hljs-string">&quot;xml:lang&quot;</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;required&quot;</span>/&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">xs:anyAttribute</span> <span class="hljs-attr">namespace</span>=<span class="hljs-string">&quot;##any&quot;</span> <span class="hljs-attr">processContents</span>=<span class="hljs-string">&quot;lax&quot;</span>/&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">xs:extension</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">xs:complexType</span>&gt;</span></code></pre><p>The <code>&lt;Message&gt;</code> element contains the Base64-encoding of the UTF-8 string holding the message to display to the user for a specific language.</p>
+<p>The required <code>xml:lang</code> attribute contains the language tag for the message&#39;s language according to [<a href="#bcp47">BCP47</a>].</p>
+<blockquote>
+<p><strong>[1]</strong>: The Markdown dialect, and potential restrictions for tags, is not regulated in this specification. However, the Markdown SHOULD NOT contain HTML-tags for security reasons.</p>
+</blockquote>
+<p><a name="usage-requirements"></a></p>
+<h2 id="3-usage-requirements">3. Usage Requirements</h2>
+<p><a name="identity-provider-requirements"></a></p>
+<h3 id="31-identity-provider-requirements">3.1. Identity Provider Requirements</h3>
+<p>An Identity Provider that supports the <code>&lt;umsg:UserMessage&gt;</code> extension MUST declare this support in its metadata entry by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category (see section 6.3 of [<a href="#sc-saml-entcat">SC.SAML.EntCat</a>]).</p>
+<p>Identity Providers compliant with this specification MUST support the <code>text/plain</code> and <code>text/markdown</code> MIME types.</p>
+<p>An OpenID Provider MUST NOT display a user message unless the user is being authenticated. Thus, if the <code>IsPassive</code>-flag of the authentication request is set to <code>true</code>, the Identity Provider MUST NOT display the user message.</p>
+<p>An Identity Provider that receives a <code>&lt;umsg:UserMessage&gt;</code> extension containing user messages in several languages SHOULD display the message that best matches the user&#39;s current locale at the Identity Provider. If no message matches the user&#39;s current locale, the Identity Provider SHOULD select the first message from the list.</p>
+<p>An Identity Provider MUST refuse to display a message if it does not support a given MIME type. It MAY respond with an error if a non-supported MIME type is received.</p>
+<p>Should a message contain illegal characters, or any other constructs not accepted by the Identity Provider, the Identity Provider MAY choose not to display the message, or filter the message before displaying it.</p>
+<p>The Identity Provider MUST be able to handle messages containing line breaks.</p>
+<p><a name="service-provider-requirements"></a></p>
+<h3 id="32-service-provider-requirements">3.2. Service Provider Requirements</h3>
+<p>A Service Provider SHOULD check whether an Identity Provider supports the <code>&lt;umsg:UserMessage&gt;</code> extension before including it in a <code>&lt;saml2p:AuthnRequest&gt;</code> element. This is done by checking the Identity Provider metadata entry for the presence of the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category (see <a href="#identity-provider-requirements">3.1</a> above).</p>
+<p>A Service Provider MUST NOT supply user messages that contains integrity sensitive information. The message will be displayed for the user <strong>before</strong> he or she is authenticated.</p>
+<p><a name="examples"></a></p>
+<h2 id="4-examples">4. Examples</h2>
+<p>Example of supplying a user message in Swedish (&quot;Jag vill logga in till example.com&quot;) and in
+English (&quot;I wish to log in to example.com&quot;):</p>
+<pre class="hljs"><code>...
+&lt;saml2p:Extensions&gt;
+  &lt;ums<span class="hljs-variable">g:UserMessage</span> xmln<span class="hljs-variable">s:umsg</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>
+                    mimeType=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
+    &lt;ums<span class="hljs-variable">g:Message</span> <span class="hljs-keyword">xm</span><span class="hljs-variable">l:lang</span>=<span class="hljs-string">&quot;sv&quot;</span>&gt;
+      SmFnIHZpbGwgbG9nZ2EgaW4gdGlsbCBleGFtcGxlLmNvbQ==
+    &lt;/ums<span class="hljs-variable">g:Message</span>&gt;
+    &lt;ums<span class="hljs-variable">g:Message</span> <span class="hljs-keyword">xm</span><span class="hljs-variable">l:lang</span>=<span class="hljs-string">&quot;en&quot;</span>&gt;
+      SSB3aXNoIHRvIGxvZ2luIHRvIGV4YW1wbGUuY29t
+    &lt;/ums<span class="hljs-variable">g:Message</span>&gt;
+  &lt;/ums<span class="hljs-variable">g:UserMessage</span>&gt;
+&lt;/saml2p:Extensions&gt;
+...</code></pre><p><a name="schemas"></a></p>
+<h2 id="5-schemas">5. Schemas</h2>
+<p>The following XML schema defines the <code>http://id.swedenconnect.se/authn/1.0/user-message/ns</code> namespace:</p>
+<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
+           targetNamespace=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>
+           xmln<span class="hljs-variable">s:umsg</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:import</span> namespace=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> schemaLocation=<span class="hljs-string">&quot;http://www.w3.org/2001/xml.xsd&quot;</span>/&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/authn/<span class="hljs-number">1.0</span>/UserMessage-<span class="hljs-number">1.0</span>.xsd
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;UserMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:UserMessageType&quot;</span>/&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;UserMessageType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;List of user <span class="hljs-keyword">messages</span> (in different languages)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:MessageType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span>/&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;mimeType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> default=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;The MIME <span class="hljs-built_in">type</span> of the user message(s)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MessageType&quot;</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+        The Base64-encoding of UTF-<span class="hljs-number">8</span> <span class="hljs-built_in">string</span> holding the user message.
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> ref=<span class="hljs-string">&quot;xml:lang&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>/&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
+      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
+    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
+  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
+
+&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
+<h2 id="6-normative-references">6. Normative References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
+Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="bcp47"></a>
+<strong>[BCP47]</strong></p>
+<blockquote>
+<p><a href="https://www.rfc-editor.org/rfc/rfc5646.txt">Tags for Identifying Languages, September 2009</a>.</p>
+</blockquote>
+<p><a name="saml2core"></a>
+<strong>[SAML2Core]</strong></p>
+<blockquote>
+<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
+Assertion Markup Language (SAML) V2.0, March
+2005</a>.</p>
+</blockquote>
+<p><a name="sc-saml-entcat"></a>
+<strong>[SC.SAML.EntCat]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="7-changes-between-versions">7. Changes between versions</h2>
+<p>This is the first version of this specification.</p>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html b/docs/december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html
new file mode 100644
index 0000000..18915a4
--- /dev/null
+++ b/docs/december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html
@@ -0,0 +1,381 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>OpenID Connect Claims and Scopes Specification for Sweden Connect</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="openid-connect-claims-and-scopes-specification-for-sweden-connect">OpenID Connect Claims and Scopes Specification for Sweden Connect</h1>
+<h3 id="version-10---2024-12-04">Version 1.0 - 2024-12-04</h3>
+<p>Registration number: <strong>2024-7704</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation-and-conventions">Requirements Notation and Conventions</a></p>
+</li>
+<li><p><a href="#claims"><strong>Claims</strong></a></p>
+<p> 2.1. <a href="#eidas-claims">eIDAS Claims</a></p>
+<p> 2.1.1. <a href="#provisional-identifier">Provisional Identifier</a></p>
+<p> 2.1.2. <a href="#provisional-identifier-persistence-indicator">Provisional Identifier Persistence Indicator</a></p>
+<p> 2.1.3. <a href="#mapped-swedish-personal-identity-number">Mapped Swedish Personal Identity Number</a></p>
+<p> 2.1.4. <a href="#mapped-swedish-coordination-number">Mapped Swedish Coordination Number</a></p>
+<p> 2.1.5. <a href="#identity-binding">Identity Binding</a></p>
+<p> 2.1.6. <a href="#eidas-person-identifier">eIDAS Person Identifier</a></p>
+<p> 2.1.7. <a href="#eidas-country">eIDAS Country</a></p>
+</li>
+<li><p><a href="#scopes"><strong>Scopes</strong></a></p>
+<p> 3.1. <a href="#eidas-scopes">eIDAS Scopes</a></p>
+<p> 3.1.1. <a href="#eidas-natural-person-identity">eIDAS Natural Person Identity</a></p>
+<p> 3.1.2. <a href="#eidas-natural-person-with-swedish-identity">eIDAS Natural Person with Swedish Identity</a></p>
+<p> 3.1.3. <a href="#additional-eidas-claims">Additional eIDAS Claims</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<p>Appendix A: <a href="#conversion-of-eidas-attributes"><strong>Conversion of eIDAS Attributes</strong></a></p>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This specification extends the &quot;Claims and Scopes Specification for the Swedish OpenID Connect Profile&quot;, [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>], with OpenID Connect claims and scopes for usage within the Sweden Connect federation.</p>
+<p><a name="requirements-notation-and-conventions"></a></p>
+<h3 id="11-requirements-notation-and-conventions">1.1. Requirements Notation and Conventions</h3>
+<p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="claims"></a></p>
+<h2 id="2-claims">2. Claims</h2>
+<p>This section defines a set of claims that extend the claims defined in [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>], and the set of standard claims defined in [<a href="#rfc7515">RFC7515</a>] and section 5.1 of [<a href="#openid-core">OpenID.Core</a>]. A full listing of standard claims can be found in the <a href="https://www.iana.org/assignments/jwt/jwt.xhtml#claims">IANA JSON Web Token Claims Registry</a>, [<a href="#iana-reg">IANA-Reg</a>].</p>
+<p>The claims defined in this specification are named in a collision-resistant manner, as described in JSON Web Token (JWT), [<a href="#rfc7515">RFC7515</a>], specification. All claims defined within this specification are prefixed with the namespace <code>https://id.swedenconnect.se/claim/</code>.</p>
+<p><a name="eidas-claims"></a></p>
+<h3 id="21-eidas-claims">2.1. eIDAS Claims</h3>
+<p>This section defines how identity attributes received from, or in conjunction with, an eIDAS authentication is represented as OpenID claims within the Sweden Connect federation. </p>
+<p><a href="#conversion-of-eidas-attributes">Appendix A: Conversion of eIDAS Attributes</a> presents a full listing of all eIDAS attributes and how they map to OpenID Connect claims. The subsections below define additional claims that may be added by the Swedish eIDAS-node.</p>
+<p><a name="provisional-identifier"></a></p>
+<h4 id="211-provisional-identifier">2.1.1. Provisional Identifier</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/prid</code></p>
+<p><strong>Description:</strong> Provisional Identifier used to represent a subject that has been authenticated by the Swedish eIDAS Connector. See section 3.3.1 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] for details.</p>
+<p><strong>Type:</strong> String</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.4</code> (prid) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<p><a name="provisional-identifier-persistence-indicator"></a></p>
+<h4 id="212-provisional-identifier-persistence-indicator">2.1.2. Provisional Identifier Persistence Indicator</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/pridPersistence</code></p>
+<p><strong>Description:</strong> Indicator for the expected persistence of the <code>prid</code> claim. See section 3.3.1 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] for details.</p>
+<p><strong>Type:</strong> String, where the possible values are <code>A</code>, <code>B</code> or <code>C</code>. See [<a href="#sc-constructed-attr">SC.Constructed</a>] for details.</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.5</code> (pridPersistence) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<p><a name="mapped-swedish-personal-identity-number"></a></p>
+<h4 id="213-mapped-swedish-personal-identity-number">2.1.3. Mapped Swedish Personal Identity Number</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/mappedPersonalIdentityNumber</code></p>
+<p><strong>Description:</strong> A Swedish civic registration number (&quot;personnummer&quot;). This claim is used to represent a Swedish civic registration number that was the result of a query from the Swedish eIDAS Connector to the identity binding service after the subject was authenticated at a foreign eIDAS node. See section 3.3.2 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] for details.</p>
+<p>Normally a Swedish civic registration number is represented using the claim <code>https://id.oidc.se/claim/personalIdentityNumber</code> defined in [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>], but in order to avoid consumption of this claim without checking how the binding was made, i.e., how trustworthy the process of binding the Swedish 
+identity to the identity attributes from the eIDAS authentication is, the identity number is represented in a separate claim. See <a href="#identity-binding">Identity Binding</a> below.</p>
+<p><strong>Type:</strong> String where the format is 12 digits without a hyphen.</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.16</code> (mappedPersonalIdentityNumber) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<p><a name="mapped-swedish-coordination-number"></a></p>
+<h4 id="214-mapped-swedish-coordination-number">2.1.4. Mapped Swedish Coordination Number</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/mappedCoordinationNumber</code></p>
+<p><strong>Description:</strong> A Swedish coordination number (&quot;samordningsnummer&quot;). This claim is used to represent a Swedish coordination number that was the result of a query from the Swedish eIDAS Connector to the identity binding service after the subject was authenticated at a foreign eIDAS node. See section 3.3.2 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] for details.</p>
+<p>Normally a Swedish coordination number is represented using the claim <code>https://id.oidc.se/claim/coordinationNumber</code> defined in [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>], but for the same reasons as described for the <code>mappedPersonalIdentityNumber</code> claim above, a mapped coordination number is represented in a separate claim.</p>
+<p><strong>Type:</strong> String where the format is 12 digits without a hyphen.</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.16</code> (mappedPersonalIdentityNumber) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<p><a name="identity-binding"></a></p>
+<h4 id="215-identity-binding">2.1.5. Identity Binding</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/identityBinding</code></p>
+<p><strong>Description:</strong> A semicolon separated list of URI:s identifying the &quot;binding process(es)&quot; for a <code>mappedPersonalIdentityNumber</code> or <code>mappedCoordinationNumber</code> claim. See section 3.3.2 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] and [<a href="#sc-id-bidning">SC.ID-Binding</a>] for details.</p>
+<p><strong>Type:</strong> Semicolon separated list of URI:s. Possible values are defined in section 3 of [<a href="#sc-id-bidning">SC.ID-Binding</a>].</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.6</code> (personalIdentityNumberBinding) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<p><a name="eidas-person-identifier"></a></p>
+<h4 id="216-eidas-person-identifier">2.1.6. eIDAS Person Identifier</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/eidasPersonIdentifier</code></p>
+<p><strong>Description:</strong> A claim that holds the value for the eIDAS Person Identifier attribute, <code>http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier</code>. This value is issued by the foreign eIDAS node, and within the eIDAS federation this is the unique user identifier. See [<a href="#eidas-attr">eIDAS.Attributes</a>].</p>
+<p><strong>Type:</strong> String</p>
+<p><strong>Corresponding SAML Attribute:</strong> <code>urn:oid:1.2.752.201.3.7</code> (eidasPersonIdentifier) - [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]</p>
+<blockquote>
+<p>Within eIDAS, the corresponding SAML attribute is: <code>http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier</code> [<a href="#eidas-attr">eIDAS.Attributes</a>].</p>
+</blockquote>
+<p><a name="eidas-country"></a></p>
+<h4 id="217-eidas-country">2.1.7. eIDAS Country</h4>
+<p><strong>Claim:</strong> <code>https://id.swedenconnect.se/claim/eidasCountry</code></p>
+<p><strong>Description:</strong> A claim that identifies the eIDAS member state that is providing the claims of the subject.</p>
+<p><strong>Type:</strong> String representing country in [<a href="#iso3166-1">ISO3166-1</a>] Alpha-2 or [<a href="#iso3166-3">ISO3166-3</a>] syntax. </p>
+<p><strong>Corresponding SAML Attribute:</strong> No specific SAML attribute exists for &quot;eIDAS country&quot;. However, the generic <code>urn:oid:2.5.4.6</code> (c) attribute is included in assertions issued by the Swedish eIDAS node.</p>
+<p><a name="scopes"></a></p>
+<h2 id="3-scopes">3. Scopes</h2>
+<p>This section defines a set of scope that extends the claims defined in section 3 of [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>].</p>
+<p>The scopes defined in this specification are named in a collision-resistant manner, as described in JSON Web Token (JWT), [<a href="#rfc7515">RFC7515</a>], specification. All scopes defined within this specification are prefixed with the namespace <code>https://id.swedenconnect.se/scope/</code>.</p>
+<p><a name="eidas-scopes"></a></p>
+<h3 id="31-eidas-scopes">3.1. eIDAS Scopes</h3>
+<p>Section 3 of [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>] states the following:</p>
+<blockquote>
+<p>Many Relying Parties that use OpenID Connect to authenticate users cannot solely depend on the user&#39;s session at the OpenID Provider and the <code>sub</code> claim to log in the user to the RP application. In the context of Swedish eID there are some obvious claims that are regarded to be &quot;primary&quot; identity claims by Relying Parties, for example, a Swedish personal identity number. Such claims are needed by the Relying Party in order to log in a user to its application. Therefore, this specification&#39;s scope definitions will define that some claims are to be delivered in the ID Token so that a Relying Party can fully log in a user without having to make a potentially unnecessary call to the UserInfo endpoint.</p>
+</blockquote>
+<p>The above is true also for Relying Parties authenticating users against the Swedish eIDAS Connector.</p>
+<p><a name="eidas-natural-person-identity"></a></p>
+<h4 id="311-eidas-natural-person-identity">3.1.1. eIDAS Natural Person Identity</h4>
+<p><strong>Scope:</strong> <code>https://id.swedenconnect.se/scope/eidasNaturalPersonIdentity</code></p>
+<p><strong>Description:</strong> A scope that defines a claim set that provides identity information for a natural person authenticated via the Swedish eIDAS-node (via a eIDAS member state). </p>
+<table>
+<thead>
+<tr>
+<th align="left">Requested Claims</th>
+<th align="left">Description/comment</th>
+<th align="left">Reference</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/prid</code></td>
+<td align="left">Provisional identifier</td>
+<td align="left">This specification - [<a href="#provisional-identifier">2.1.1</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/pridPersistence</code></td>
+<td align="left">Persistence indicator for the above <code>prid</code> claim</td>
+<td align="left">This specification - [<a href="#provisional-identifier-persistence-indicator">2.1.2</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/eidasPersonIdentifier</code></td>
+<td align="left">eIDAS Person Identifier</td>
+<td align="left">This specification - [<a href="#eidas-person-identifier">2.1.6</a>]</td>
+</tr>
+</tbody></table>
+<p><strong>Claims Parameter Equivalent:</strong></p>
+<pre class="hljs"><code>{
+  <span class="hljs-attr">&quot;userinfo&quot;</span> : {
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/prid&quot;</span> : { <span class="hljs-attr">&quot;essential&quot;</span> : <span class="hljs-literal">true</span> },
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/pridPersistence&quot;</span> : { <span class="hljs-attr">&quot;essential&quot;</span> : <span class="hljs-literal">true</span> },
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/eidasPersonIdentifier&quot;</span>: { <span class="hljs-attr">&quot;essential&quot;</span> : <span class="hljs-literal">true</span> },
+  },
+  <span class="hljs-attr">&quot;id_token&quot;</span> : {
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/prid&quot;</span> : { <span class="hljs-attr">&quot;essential&quot;</span> : <span class="hljs-literal">true</span> },
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/pridPersistence&quot;</span> : { <span class="hljs-attr">&quot;essential&quot;</span> : <span class="hljs-literal">true</span> }
+  }
+}</code></pre><p><strong>Note:</strong> It is RECOMMENDED that Swedish Relying Parties use the <code>https://id.swedenconnect.se/claim/prid</code> claim as a primary identity for a user identified using eIDAS and therefore this claim will be available in the ID Token. The eIDAS Person Identifier, which is the identifier issued by the member state eIDAS-node, may be logged/saved by the Relying Party for potential future use in contacts with the member state node. </p>
+<p><a name="eidas-natural-person-with-swedish-identity"></a></p>
+<h4 id="312-eidas-natural-person-with-swedish-identity">3.1.2. eIDAS Natural Person with Swedish Identity</h4>
+<p><strong>Scope:</strong> <code>https://id.swedenconnect.se/scope/eidasSwedishIdentity</code></p>
+<p><strong>Description:</strong> The Swedish eIDAS Connector has an integration against an &quot;Identity Binding Service&quot; holding bindings between eIDAS eID identities and Swedish identities (see [<a href="#sc-id-bidning">SC.ID-Binding</a>] for details). If this scope is requested by a Relying Party, the eIDAS Connector will check if there exists a binding between the user&#39;s eIDAS identity and a Swedish identity, and if so, make those claims available for the Relying Party.</p>
+<table>
+<thead>
+<tr>
+<th align="left">Requested Claims</th>
+<th align="left">Description/comment</th>
+<th align="left">Reference</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/</code><br /><code>mappedPersonalIdentityNumber</code></td>
+<td align="left">A Swedish civic registration number (&quot;personnummer&quot;) that was the result of a query  from the Swedish eIDAS Connector to the identity binding service after the subject was authenticated at a foreign eIDAS node.</td>
+<td align="left">This specification - [<a href="#mapped-swedish-personal-identity-number">2.1.3</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/</code><br /><code>mappedCoordinationNumber</code></td>
+<td align="left">A Swedish coordination number (&quot;samordningsnummer&quot;) that was the result of a query  from the Swedish eIDAS Connector to the identity binding service after the subject was authenticated at a foreign eIDAS node.</td>
+<td align="left">This specification - [<a href="#mapped-swedish-coordination-number">2.1.4</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>https://id.swedenconnect.se/claim/</code><br /><code>identityBinding</code></td>
+<td align="left">Identification of the binding process(es) that were applied to obtain the binding between the eIDAS identity and the <code>mappedPersonalIdentityNumber</code> or <code>mappedCoordinationNumber</code>. See [<a href="#sc-id-bidning">SC.ID-Binding</a>].</td>
+<td align="left">This specification - [<a href="#identity-binding">2.1.5</a>]</td>
+</tr>
+</tbody></table>
+<p><strong>Claims Parameter Equivalent:</strong></p>
+<pre class="hljs"><code>{
+  <span class="hljs-attr">&quot;userinfo&quot;</span> : {
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/mappedPersonalIdentityNumber&quot;</span> : <span class="hljs-literal">null</span>,
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/mappedCoordinationNumber&quot;</span> : <span class="hljs-literal">null</span>,
+    <span class="hljs-attr">&quot;https://id.swedenconnect.se/claim/identityBinding&quot;</span> : <span class="hljs-literal">null</span>
+  }
+}</code></pre><p><strong>Note:</strong> None of the claims are marked as &quot;essential&quot; since the eIDAS Connector will only deliver the claims if an identity binding exists. Also, the scope definition states that the claims should be delivered via the UserInfo endpoint and not directly in the ID Token. The reason for this is that a mapped identity can never be seen as a primary eIDAS identity (since the claims are only delivered if a binding exists).</p>
+<p><strong>Note (ii):</strong> The <code>mappedPersonalIdentityNumber</code> and <code>mappedCoordinationNumber</code> claims are mutually exclusive. A user has bound his or hers eIDAS identity to a Swedish civic registration number (&quot;personnummer&quot;) <strong>or</strong> a Swedish coordination number (&quot;samordningsnummer&quot;), never both.</p>
+<p><a name="additional-eidas-claims"></a></p>
+<h4 id="313-additional-eidas-claims">3.1.3. Additional eIDAS Claims</h4>
+<p>Not all eIDAS attributes/claims listed in <a href="#conversion-of-eidas-attributes">Appendix A</a> are covered by the above scope definitions. This section is an informational text informing Relying Parties how to obtain additional claims for an eIDAS authentication.</p>
+<ul class="list">
+<li><p>To obtain name and date of birth claims, include the <code>https://id.oidc.se/scope/naturalPersonInfo</code> scope (section 3.1 of  [<a href="#oidc-sweden-claims">OIDC.Sweden.Claims</a>]).</p>
+</li>
+<li><p>For the transaction identifier holding the ID of the SAML assertion delivered from the foreign member state (as described in section 2.5 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]), include an explicit claim request for the <code>txn</code> claim ([<a href="#rfc8417">RFC8417</a>]).</p>
+</li>
+<li><p>For the country code of the eIDAS country at which the user was authenticated (as described in section 2.5 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>]), include an explicit claim request for the <code>https://id.swedenconnect.se/claim/eidasCountry</code> claim (<a href="#eidas-country">2.1.7</a>).</p>
+</li>
+<li><p>For all other optional eIDAS attributes (see <a href="#conversion-of-eidas-attributes">Appendix A</a>), an explicit claim request should be included. These claims SHOULD NOT be marked as &quot;essential&quot; since they are not mandatory according to [<a href="#eidas-attr">eIDAS.Attributes</a>]. </p>
+</li>
+</ul>
+<blockquote>
+<p>Section 2.2.1 of [<a href="#eidas-attr">eIDAS.Attributes</a>] defines the eIDAS Minimum Dataset for Natural Persons. This set consists of the eIDAS attributes FamilyName, FirstName, DateOfBirth and PersonIdentifier. In order for a Relying Party to obtain the corresponding OpenID Connect claims from an eIDAS authentication it should specify the <code>https://id.oidc.se/scope/naturalPersonInfo</code> and <code>https://id.swedenconnect.se/scope/eidasNaturalPersonIdentity</code> scopes in an authentication request sent to the Swedish eIDAS Connector.</p>
+</blockquote>
+<p><a name="references"></a></p>
+<h2 id="4-references">4. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="openid-core"></a>
+<strong>[OpenID.Core]</strong></p>
+<blockquote>
+<p>[Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, &quot;OpenID Connect Core 1.0&quot;, August 2015] (<a href="https://openid.net/specs/openid-connect-core-1_0.html">https://openid.net/specs/openid-connect-core-1_0.html</a>).</p>
+</blockquote>
+<p><a name="rfc7515"></a>
+<strong>[RFC7515]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7515">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT)”, May 2015</a>.</p>
+</blockquote>
+<p><a name="iana-reg"></a>
+<strong>[IANA-Reg]</strong></p>
+<blockquote>
+<p><a href="https://www.iana.org/assignments/jwt/jwt.xhtml#claims">IANA JSON Web Token Claims Registry</a>.</p>
+</blockquote>
+<p><a name="oidc-sweden-claims"></a>
+<strong>[OIDC.Sweden.Claims]</strong></p>
+<blockquote>
+<p><a href="https://www.oidc.se/specifications/swedish-oidc-claims-specification-1_0.html">Claims and Scopes Specification for the Swedish OpenID Connect Profile - Version 1.0</a>.</p>
+</blockquote>
+<p><a name="saml-sc-attributes"></a>
+<strong>[SAML.SC.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-constructed-attr"></a>
+<strong>[SC.Constructed]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-id-bidning"></a>
+<strong>[SC.ID-Binding]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS Identities to Records in the Swedish Population Register</a>.</p>
+</blockquote>
+<p><a name="eidas-attr"></a>
+<strong>[eIDAS.Attributes]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.4_final.pdf">eIDAS SAML Attribute Profile, version 1.4, 31 October 2023</a>.</p>
+</blockquote>
+<p><a name="oidc-iac"></a>
+<strong>[OIDC.IAC]</strong></p>
+<blockquote>
+<p><a href="https://openid.net/specs/openid-connect-4-ida-claims-1_0-final.html">T. Lodderstedt, D. Fett, M. Haine, A. Pulido, K. Lehmann, K. Koiwai, &quot;OpenID Connect for Identity Assurance Claims Registration 1.0&quot;, October 2024</a>.</p>
+</blockquote>
+<p><a name="rfc8417"></a>
+<strong>[RFC8417]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc8417">P. Hunt, M. Jones, W. Denniss, M. Ansari, &quot;Security Event Token (SET)&quot;, July 2018</a>.</p>
+</blockquote>
+<p><a name="iso3166-1"></a>
+<strong>[ISO3166-1]</strong></p>
+<blockquote>
+<p><a href="https://www.iso.org/standard/72482.html">ISO, &quot;ISO 3166-1:2020. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes&quot;, 2020</a>.</p>
+</blockquote>
+<p><a name="iso3166-3"></a>
+<strong>[ISO3166-3]</strong></p>
+<blockquote>
+<p><a href="https://www.iso.org/standard/72482.html">ISO, &quot;ISO 3166-3:2020. Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries&quot;, 2020</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="5-changes-between-versions">5. Changes between versions</h2>
+<p>This is the first version of this specification.</p>
+<p><a name="conversion-of-eidas-attributes"></a></p>
+<h2 id="appendix-a-conversion-of-eidas-attributes">Appendix A: Conversion of eIDAS Attributes</h2>
+<p>This section provides a listing of how the eIDAS attributes for natural persons defined in section 2.2 of [<a href="#eidas-attr">eIDAS.Attributes</a>] are mapped to their corresponding OpenID Connect claims.</p>
+<blockquote>
+<p>Also see section 3.3.3 of [<a href="#saml-sc-attributes">SAML.SC.Attributes</a>] where a corresponding mapping between eIDAS attributes and Sweden Connect SAML attributes is presented.</p>
+</blockquote>
+<table>
+<thead>
+<tr>
+<th align="left">eIDAS attribute</th>
+<th align="left">Claim</th>
+<th align="left">Reference</th>
+</tr>
+</thead>
+<tbody><tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/PersonIdentifier</code> - PersonIdentifier</td>
+<td align="left"><code>https://id.swedenconnect.se/claim/</code><br /><code>eidasPersonIdentifier</code></td>
+<td align="left">This specification</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/CurrentFamilyName</code> - FamilyName</td>
+<td align="left"><code>family_name</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/CurrentGivenName</code> - FirstName</td>
+<td align="left"><code>given_name</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/DateOfBirth</code> - DateOfBirth</td>
+<td align="left"><code>birthdate</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/BirthName</code> - BirthName</td>
+<td align="left"><code>birth_family_name</code><br /><code>birth_given_name</code><br /><code>birth_middle_name</code></td>
+<td align="left">[<a href="#oidc-iac">OIDC.IAC</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/PlaceOfBirth</code> - PlaceOfBirth</td>
+<td align="left"><code>place_of_birth</code></td>
+<td align="left">[<a href="#oidc-iac">OIDC.IAC</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/CurrentAddress</code> - CurrentAddress</td>
+<td align="left"><code>address</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/Gender</code> - Gender</td>
+<td align="left"><code>gender</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/Nationality</code> - Nationality</td>
+<td align="left"><code>nationalities</code></td>
+<td align="left">[<a href="#oidc-iac">OIDC.IAC</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/CountryOfBirth</code> - CountryOfBirth</td>
+<td align="left"><code>place_of_birth.country</code></td>
+<td align="left">[<a href="#oidc-iac">OIDC.IAC</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br ><code>naturalperson/TownOfBirth</code> - TownOfBirth</td>
+<td align="left"><code>place_of_birth.locality</code></td>
+<td align="left">[<a href="#oidc-iac">OIDC.IAC</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/CountryOfResidence</code> - CountryOfResidence</td>
+<td align="left"><code>address.country</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/PhoneNumber</code> - PhoneNumber</td>
+<td align="left"><code>phone_number</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+<tr>
+<td align="left"><code>http://eidas.europa.eu/attributes/</code><br /><code>naturalperson/EmailAddress</code> - EmailAddress</td>
+<td align="left"><code>email</code></td>
+<td align="left">[<a href="#openid-core">OpenID.Core</a>]</td>
+</tr>
+</tbody></table>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html b/docs/december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html
new file mode 100644
index 0000000..4001601
--- /dev/null
+++ b/docs/december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html
@@ -0,0 +1,247 @@
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>OpenID Connect Profile for Sweden Connect</title>
+    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
+    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
+  </head>
+  <body>
+    <article class="markdown-body"><p>
+<img align="left" src="img/sweden-connect.png"></img>
+<img align="right" src="img/digg_centered.png"></img>
+</p>
+<p>
+<img align="center" src="img/transparent.png"></img>
+</p>
+
+<h1 id="openid-connect-profile-for-sweden-connect">OpenID Connect Profile for Sweden Connect</h1>
+<h3 id="version-10---2024-12-04">Version 1.0 - 2024-12-04</h3>
+<p>Registration number: <strong>2024-7674</strong></p>
+<hr>
+<p class="copyright-statement">
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
+</p>
+
+<h2 id="table-of-contents">Table of Contents</h2>
+<ol class="list">
+<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
+<p> 1.1. <a href="#requirements-notation-and-conventions">Requirements Notation and Conventions</a></p>
+<p> 1.2. <a href="#conformance">Conformance</a></p>
+</li>
+<li><p><a href="#openid-provider-requirements"><strong>OpenID Provider Requirements</strong></a></p>
+<p> 2.1. <a href="#openid-provider-discovery-and-metadata-requirements">OpenID Provider Discovery and Metadata Requirements</a></p>
+<p> 2.2. <a href="#op-authentication-request-requirements">Authentication Request Requirements</a></p>
+<p> 2.2.1. <a href="#single-sign-on-processing">Single Sign-on Processing</a></p>
+<p> 2.2.2. <a href="#user-message-request-parameter">User Message Request Parameter</a></p>
+<p> 2.2.3. <a href="#requested-authentication-provider-parameter">Requested Authentication Provider Parameter</a></p>
+<p> 2.3. <a href="#op-token-endpoint-requirements">Token Endpoint Requirements</a></p>
+<p> 2.3.1. <a href="#client-authentication-requirements">Client Authentication Requirements</a></p>
+<p> 2.3.2. <a href="#token-response-requirements">Token Response Requirements</a></p>
+<p> 2.4. <a href="#eidas-requirements">eIDAS Requirements</a></p>
+</li>
+<li><p><a href="#relying-party-requirements"><strong>Relying Party Requirements</strong></a></p>
+<p> 3.1. <a href="#client-authentication-request-requirements">Authentication Request Requirements</a></p>
+<p> 3.2. <a href="#client-registration-and-metadata-requirements">Client Registration and Metadata Requirements</a></p>
+</li>
+<li><p><a href="#references"><strong>References</strong></a></p>
+</li>
+<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
+</li>
+</ol>
+<hr>
+<p><a name="introduction"></a></p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This profile is an extension of <a href="#oidc-sweden-profile">The Swedish OpenID Connect Profile</a>, [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>], for the <a href="https://www.swedenconnect.se">Sweden Connect</a> identity federation.</p>
+<p>The profile aims to get a baseline security and to facilitate interoperability between relying parties and OpenID providers within the Sweden Connect identity federation.</p>
+<blockquote>
+<p><strong>Note:</strong> This version of the profile does not address features concerning &quot;Signature Services&quot; and requirements for &quot;authentication for Signature&quot; that are specified in the corresponding Sweden Connect SAML deployment profile, [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. Nor does the profile specify how OpenID Provider metadata and Relying Party/Client metadata is distributed and made available to the members of the federation. This will be added in future versions of the profile.</p>
+</blockquote>
+<p><a name="requirements-notation-and-conventions"></a></p>
+<h3 id="11-requirements-notation-and-conventions">1.1. Requirements Notation and Conventions</h3>
+<p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
+<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
+<p><a name="conformance"></a></p>
+<h3 id="12-conformance">1.2. Conformance</h3>
+<p>This profile defines requirements for OpenID Connect Relying Parties (clients) and OpenID Providers (identity providers), and the interaction between them. </p>
+<p>Components compliant with this profile MUST adhere to the requirements of <a href="#oidc-sweden-profile">The Swedish OpenID Connect Profile</a>, [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] along with the extensions and requirements stated in the rest of this profile.</p>
+<p><a name="openid-provider-requirements"></a></p>
+<h2 id="2-openid-provider-requirements">2. OpenID Provider Requirements</h2>
+<p>An OpenID Provider compliant with this profile MUST adhere to the requirements stated in [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] along with the additions declared below.</p>
+<p><a name="openid-provider-discovery-and-metadata-requirements"></a></p>
+<h3 id="21-openid-provider-discovery-and-metadata-requirements">2.1. OpenID Provider Discovery and Metadata Requirements</h3>
+<p>The following requirements concerning OpenID Provider Metadata documents apply in addition to section 5.2 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>]:</p>
+<ul class="list">
+<li><p>The OP Metadata document SHOULD contain a <code>service_documentation</code> parameter having as its value a URL pointing to a resource containing human-readable information about the OP (for example, information about client registration). See section 3 of [<a href="#openid-discovery">OpenID.Discovery</a>].</p>
+</li>
+<li><p>The OP Metadata document MUST contain the <code>ui_locales_supported</code> parameter, and its value MUST contain English (<code>en</code>) and Swedish (<code>sv</code>), and MAY contain support for other languages. See section 3 of [<a href="#openid-discovery">OpenID.Discovery</a>].</p>
+</li>
+</ul>
+<blockquote>
+<p><strong>Note:</strong> This version of the profile does not specify how OpenID Provider Metadata documents are made available to the Relying Parties/Clients of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing metadata.</p>
+</blockquote>
+<p><a name="op-authentication-request-requirements"></a></p>
+<h3 id="22-authentication-request-requirements">2.2. Authentication Request Requirements</h3>
+<p><a name="single-sign-on-processing"></a></p>
+<h4 id="221-single-sign-on-processing">2.2.1. Single Sign-on Processing</h4>
+<p>Sweden Connect is a national identity federation and the Relying Parties of the federation generally have no organizational affinity, other than they use the same OpenID Providers for authentication of their users. Therefore, the feature of Single Sign-on by relying on a user&#39;s security context/session at an OpenID Provider that is used by several, non-connected, Relying Parties, should be used with great care. </p>
+<p>This profile states the following requirements regarding the re-use of user sessions:</p>
+<ul class="list">
+<li><p>An OpenID Provider within the Sweden Connect federation MUST NOT allow user sessions to exceed 60 minutes. </p>
+</li>
+<li><p>If the <code>prompt</code> parameter is not present in an authentication request, the OpenID Provider MUST treat this request as if it would contain the <code>prompt</code> parameter with a value of <code>login</code>, meaning that a user (re-)authentication is required, no matter the state of the current user session at the provider.</p>
+</li>
+<li><p>If the <code>prompt</code> parameter is present and its value is set to <code>none</code> (meaning that the Relying Party wishes to make use of an existing user security context/session, i.e., SSO), the following requirements apply:</p>
+<ul class="list">
+<li>If the security context/user session has expired, the OP MUST respond with an error holding the error code <code>login_required</code>.</li>
+<li>If the original authentication process, which led to the establishment of the security context, was created based on the request from another Relying Party than the sender of the current request, the OP MUST respond with an error holding the error code <code>login_required</code>. <br /><br />The exception to this requirement is that an OP is allowed to maintain a configuration of &quot;groups of Relying Parties&quot;, where SSO is allowed. How this configuration is maintained is out of scope for this profile.  </li>
+<li>If the original authentication process, which led to the establishment of the security context, was performed using another authentication method or <code>acr</code> (Authentication Context Class Reference) than what is requested in the current authentication request, the OP MUST respond with an error holding the error code <code>login_required</code>.</li>
+<li>If the original authentication process, which led to the establishment of the security context, involved user consent for a set of claims, and the current authentication request contains a request for a different set of identity claims, the OP MUST respond with an error holding the error code <code>interaction_required</code>.</li>
+</ul>
+</li>
+</ul>
+<p>See section 3.1.2.1 of [<a href="#openid-core">OpenID.Core</a>] and section 2.1.4 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] regarding further requirements for the <code>prompt</code> request parameter.</p>
+<p><a name="user-message-request-parameter"></a></p>
+<h4 id="222-user-message-request-parameter">2.2.2. User Message Request Parameter</h4>
+<p>It is RECOMMENDED that OpenID Providers compliant with this profile supports the <code>https://id.oidc.se/param/userMessage</code> request parameter according to section 2.1 of [<a href="#oidc-sweden-rpar">OIDC.Sweden.RPar</a>]. This parameter gives the Relying Party the possibility to request that a message (set by the RP) is displayed to the user during the authentication process.</p>
+<p>OpenID Providers that support the <code>https://id.oidc.se/param/userMessage</code> request parameter MUST include the <code>https://id.oidc.se/disco/userMessageSupported</code> parameter in its Metadata document (see section 3.3.1 of [<a href="#oidc-sweden-rpar">OIDC.Sweden.RPar</a>]). If MIME types other than <code>text/plain</code> is supported, the OP MUST include the <code>https://id.oidc.se/disco/userMessageSupportedMimeTypes</code> parameter and as its value state all supported MIME types.</p>
+<p><a name="requested-authentication-provider-parameter"></a></p>
+<h4 id="223-requested-authentication-provider-parameter">2.2.3. Requested Authentication Provider Parameter</h4>
+<p>An OpenID Provider that acts as a proxy for underlying authentication mechanisms SHOULD support the <code>https://id.oidc.se/param/authnProvider</code> request parameter extension (see section 2.2 of [<a href="#oidc-sweden-rpar">OIDC.Sweden.RPar</a>]).</p>
+<p>OpenID Providers that support the <code>https://id.oidc.se/param/authnProvider</code> request parameter, MUST declare this support in its Metadata document using the <code>https://id.oidc.se/disco/authnProviderSupported</code> parameter, see section 3.2 of [<a href="#oidc-sweden-rpar">OIDC.Sweden.RPar</a>].</p>
+<p><a name="op-token-endpoint-requirements"></a></p>
+<h3 id="23-token-endpoint-requirements">2.3. Token Endpoint Requirements</h3>
+<p>This section extends section 3 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] with additional requirements for Token endpoint requests and responses.</p>
+<p><a name="client-authentication-requirements"></a></p>
+<h4 id="231-client-authentication-requirements">2.3.1. Client Authentication Requirements</h4>
+<p>The following requirements apply in addition to the requirements stated in section 3.1.1 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>].</p>
+<p>In the context of the Sweden Connect federation, the OpenID Provider MUST NOT accept any other client authentication methods than <code>private_key_jwt</code>, or, if a bilateral agreement exists with a Relying Party, mutual TLS authentication.</p>
+<p>Mutual TLS authentication may be <code>tls_client_auth</code> or <code>self_signed_tls_client_auth</code>, and the requirements stated in section 2 of [<a href="#rfc8705">RFC8705</a>] MUST be followed. </p>
+<p><a name="token-response-requirements"></a></p>
+<h4 id="232-token-response-requirements">2.3.2. Token Response Requirements</h4>
+<p>The contents of the Access Token issued in a Token response MUST NOT reveal any information about the user&#39;s identity or the authentication process.</p>
+<p>Section 4.2 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] states:</p>
+<blockquote>
+<p>An OpenID Provider compliant with this profile MUST NOT release any identity claims in the ID Token, or via the UserInfo endpoint, if they have not been explicitly requested via scope and/or claims request parameters, or indirectly by a policy known, and accepted, by the involved parties. </p>
+</blockquote>
+<p>If the Access Token is a cleartext JWT holding user identity data, information that the Relying Party may not be authorized to access may be leaked. Therefore, it is RECOMMENDED that opaque strings are used as Access Tokens.</p>
+<p>Note: An OpenID Provider that also acts as an OAuth2 Authorization Server may of course issue JWT Access Tokens. The above requirement only applies to the Access Tokens that are issued during authentication (i.e., for granting access to the UserInfo endpoint).</p>
+<p><a name="relying-party-requirements"></a></p>
+<h2 id="3-relying-party-requirements">3. Relying Party Requirements</h2>
+<p>An OpenID Connect Relying Party (Client) compliant with this profile MUST adhere to the requirements stated in [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] along with the additions declared below.</p>
+<p><a name="client-authentication-request-requirements"></a></p>
+<h3 id="31-authentication-request-requirements">3.1. Authentication Request Requirements</h3>
+<p>For all authentication requests where the Relying Party expects the user to authenticate itself, the RP SHOULD include the <code>prompt</code> request parameter and assign the <code>login</code> value. This is to prevent un-wanted SSO. See section 2.1.4 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>].</p>
+<p>It is RECOMMENDED that Relying Parties send authentication requests containing Request Objects, i.e., the request parameters are included in a JWT, and its encoding is assigned to the <code>request</code> parameter according to section 6.1 of [<a href="#openid-core">OpenID.Core</a>]. It is also RECOMMENDED that the Request Object JWT is signed.</p>
+<blockquote>
+<p>The above recommendation gives a higher level of security, and may be changed to an imperative requirement in future versions of this profile.</p>
+</blockquote>
+<p><a name="client-registration-and-metadata-requirements"></a></p>
+<h3 id="32-client-registration-and-metadata-requirements">3.2. Client Registration and Metadata Requirements</h3>
+<p>Relying Parties compliant with this profile MUST follow the requirements stated in section 6 of [<a href="#oidc-sweden-profile">OIDC.Sweden.Profile</a>] with the additions stated below.</p>
+<p>The Relying Party/Client metadata MUST contain the following additional parameters:</p>
+<ul class="list">
+<li><p>The <code>contacts</code> parameter holding at least one email address of people/groups responsible for the Relying Party.</p>
+</li>
+<li><p>The <code>client_name</code> parameter holding the client presentation name. This name may be presented to the end-user by the OpenID Provider during authentication. The name MUST be given in Swedish (<code>sv</code>) and English (<code>en</code>).</p>
+</li>
+<li><p>The <code>logo_uri</code> parameter containing a URL referencing a logotype for the Relying Party. This logotype may be displayed by the OpenID Provider for the end-user during authentication. The URL MUST use the HTTPS-scheme and point to a valid image file. It is RECOMMENDED that the image file is in SVG-format. The parameter MAY be given for different languages.</p>
+</li>
+<li><p>The <code>client_uri</code> parameter containing a URL that is the home page for the Relying Party. This link may be used by the OpenID Provider when interacting with the user. The URL MUST use the HTTPS-scheme and point to a valid web page. The parameter MAY be given for different languages.</p>
+</li>
+</ul>
+<p>Also, it is RECOMMENDED, that a Relying Party includes the <code>organization_name</code> claim and provides its human-readable organization name in Swedish and English. See section 5.2.2 of [<a href="#openid-federation">OpenID.Federation</a>]. </p>
+<p><strong>Example:</strong></p>
+<pre class="hljs"><code>{
+  ...
+  <span class="hljs-attr">&quot;contacts&quot;</span>: [
+    <span class="hljs-string">&quot;operations@example.com&quot;</span>
+  ],
+  <span class="hljs-attr">&quot;client_name#en&quot;</span>: <span class="hljs-string">&quot;The Example Service&quot;</span>,
+  <span class="hljs-attr">&quot;client_name#sv&quot;</span>: <span class="hljs-string">&quot;Exempeltjänsten&quot;</span>,
+  <span class="hljs-attr">&quot;logo_uri&quot;</span>: <span class="hljs-string">&quot;https://www.example.com/logo.svg&quot;</span>,
+  <span class="hljs-attr">&quot;client_uri#en&quot;</span>: <span class="hljs-string">&quot;https://www.example.com&quot;</span>,
+  <span class="hljs-attr">&quot;client_uri#sv&quot;</span>: <span class="hljs-string">&quot;https://www.example.com/sv&quot;</span>,
+  <span class="hljs-attr">&quot;organization_name#en&quot;</span> : <span class="hljs-string">&quot;Example Organization&quot;</span>,
+  <span class="hljs-attr">&quot;organization_name#sv&quot;</span> : <span class="hljs-string">&quot;Exempelorganisationen&quot;</span>
+  ...
+}</code></pre><p>See further requirements concerning client metadata in section 2 of [<a href="#openid-registration">OpenID.Registration</a>].</p>
+<blockquote>
+<p><strong>Note:</strong> This version of the profile does not specify how client metadata is registered at/distributed to the OpenID Providers of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing client metadata.</p>
+</blockquote>
+<p><a name="references"></a></p>
+<h2 id="4-references">4. References</h2>
+<p><a name="rfc2119"></a>
+<strong>[RFC2119]</strong></p>
+<blockquote>
+<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997</a>.</p>
+</blockquote>
+<p><a name="openid-core"></a>
+<strong>[OpenID.Core]</strong></p>
+<blockquote>
+<p>[Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, &quot;OpenID Connect Core 1.0&quot;, August 2015] (<a href="https://openid.net/specs/openid-connect-core-1_0.html">https://openid.net/specs/openid-connect-core-1_0.html</a>).</p>
+</blockquote>
+<p><a name="openid-discovery"></a>
+<strong>[OpenID.Discovery]</strong></p>
+<blockquote>
+<p><a href="https://openid.net/specs/openid-connect-discovery-1_0.html">Sakimura, N., Bradley, J., Jones, M. and E. Jay, &quot;OpenID Connect Discovery 1.0&quot;, August 2015</a>.</p>
+</blockquote>
+<p><a name="openid-registration"></a>
+<strong>[OpenID.Registration]</strong></p>
+<blockquote>
+<p><a href="https://openid.net/specs/openid-connect-registration-1_0.html">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014</a>.</p>
+</blockquote>
+<p><a name="openid-federation"></a>
+<strong>[OpenID.Federation]</strong></p>
+<blockquote>
+<p><a href="https://openid.net/specs/openid-federation-1_0.html">Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., De Marco, G. and V. Dzhuvinov, &quot;OpenID Federation 1.0&quot;</a>.</p>
+</blockquote>
+<p><a name="rfc7515"></a>
+<strong>[RFC7515]</strong></p>
+<blockquote>
+<p><a href="https://tools.ietf.org/html/rfc7515">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT)”, May 2015</a>.</p>
+</blockquote>
+<p><a name="rfc8705"></a>
+<strong>[RFC8705]</strong></p>
+<blockquote>
+<p><a href="https://datatracker.ietf.org/doc/html/rfc8705">B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt, &quot;OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens&quot;, February 2020</a>.</p>
+</blockquote>
+<p><a name="iana-reg"></a>
+<strong>[IANA-Reg]</strong></p>
+<blockquote>
+<p><a href="https://www.iana.org/assignments/jwt/jwt.xhtml#claims">IANA JSON Web Token Claims Registry</a>.</p>
+</blockquote>
+<p><a name="oidc-sweden-profile"></a>
+<strong>[OIDC.Sweden.Profile]</strong></p>
+<blockquote>
+<p><a href="https://www.oidc.se/specifications/swedish-oidc-profile-1_0.html">The Swedish OpenID Connect Profile - version 1.0</a>.</p>
+</blockquote>
+<p><a name="oidc-sweden-claims"></a>
+<strong>[OIDC.Sweden.Claims]</strong></p>
+<blockquote>
+<p><a href="https://www.oidc.se/specifications/swedish-oidc-claims-specification-1_0.html">Claims and Scopes Specification for the Swedish OpenID Connect Profile - Version 1.0</a>.</p>
+</blockquote>
+<p><a name="oidc-sweden-rpar"></a>
+<strong>[OIDC.Sweden.RPar]</strong></p>
+<blockquote>
+<p><a href="https://www.oidc.se/specifications/request-parameter-extensions-1_1.html">Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile - Version 1.1</a>.</p>
+</blockquote>
+<p><a name="oidc-sweden-sign"></a>
+<strong>[OIDC.Sweden.Sign]</strong></p>
+<blockquote>
+<p><a href="https://www.oidc.se/specifications/oidc-signature-extension-1_1.html">Signature Extension for OpenID Connect - Version 1.1</a>.</p>
+</blockquote>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="5-changes-between-versions">5. Changes between versions</h2>
+<p>This is the first version of this specification.</p>
+    </article>
+  </body>
+</html>
diff --git a/docs/december-2024/index.html b/docs/december-2024/index.html
index 0f94212..80d4d02 100644
--- a/docs/december-2024/index.html
+++ b/docs/december-2024/index.html
@@ -1,135 +1,165 @@
 <!doctype html>
-<html>
+<html lang="en">
 <head>
-<meta charset="utf-8">
-<meta name="viewport" content="width=device-width, initial-scale=1">
-<title>Specifications for the Swedish eID Framework</title>
-<link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-<link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-<link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print">
-<link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print">
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title>Specifications for the Swedish eID Framework</title>
+  <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
+  <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
+  <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print">
+  <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print">
 </head>
 <body>
-	<article class="markdown-body">
-		<p>
-			<img align="left" src="img/sweden-connect.png"></img>
-			<img align="right" src="img/digg_centered.png"></img>
-		</div>
-		</p>
-		<p>
-			<img align="center" src="img/transparent.png"></img>
-		</p>
+<article class="markdown-body">
+  <p>
+    <img align="left" src="img/sweden-connect.png" alt="Sweden Connect Logo" />
+    <img align="right" src="img/digg_centered.png" />
+    </div>
+  </p>
+  <p>
+    <img align="center" src="img/transparent.png"></img>
+  </p>
 
-		<h1 id="specifications-for-the-swedish-eid-framework">Sweden Connect Specifications</h1>
-		<h3 id="month,-year">December 2024</h3>
-		<hr>
-		<p>Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.</p>
-		<hr>
-		<p>
-		  This is the December 2024 version of the Sweden Connect Framework. It replaces the previous
-			November 2021 release as the official version for the Sweden Connect Framework.
-		</p>
-		<h3 id="changes-since-last-version">Changes since last version</h3>
-		<p>Below follows a listing of all significant changes since the November 2021 release of the Sweden Connect Framework.</p>
-		<ul class="list">
-			<li>
-				The OpenID Connect specifications <a href="OpenID_Connect_Profile_for_Sweden_Connect.html">OpenID Connect Profile for Sweden Connect</a>
-				and <a href="OpenID_Connect_Claims_and_Scopes_Specification.html">OpenID Connect Claims and Scopes Specification for Sweden Connect</a>
-				were introduced. Future versions of the Sweden Connect Framework will include more OpenID Connect support. The two specifications
-				added to this version is intended to serve as support for early adopters of the OpenID Connect technology within the Sweden Connect
-				federation.
-			</li>
-			<li>
-				The specification <a href="18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>
-				was added. This specification introduces a SAML Authentication Request extension for Service Providers wishing to
-				pass a custom "authentication message" for the Identity Provider to display for the user during the authentication.
-			</li>
-			<li>
-				The document <a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS Identities to Records in the Swedish Population Register</a>
-				was introduced to describe the process of eIDAS Identity Binding.
-			</li>
-			<li>
-				Section 3.3.2 of <a href="04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>
-				was updated with extended descriptions of how the <i>mappedPersonalIdentityNumber</i> and <i>personalIdentityNumberBinding</i>
-				attributes should be consumed when eIDAS Identity Binding has been applied.
-			</li>
-		</ul>
+  <h1 id="specifications-for-the-swedish-eid-framework">Sweden Connect Specifications</h1>
+  <h3 id="month,-year">December 2024</h3>
+  <hr>
+  <p>Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All
+    Rights Reserved.</p>
+  <hr>
+  <p>
+    This is the December 2024 version of the Sweden Connect Framework. It replaces the previous
+    November 2021 release as the official version for the Sweden Connect Framework.
+  </p>
+  <h3 id="changes-since-last-version">Changes since last version</h3>
+  <p>Below follows a listing of all significant changes since the November 2021 release of the Sweden Connect
+    Framework.</p>
+  <ul class="list">
+    <li>
+      The OpenID Connect specifications <a href="OpenID_Connect_Profile_for_Sweden_Connect.html">OpenID Connect Profile
+      for Sweden Connect</a> and <a href="OpenID_Connect_Claims_and_Scopes_Specification.html">OpenID Connect Claims and
+      Scopes Specification for Sweden Connect</a> were introduced. Future versions of the Sweden Connect Framework will
+      include more OpenID Connect support. The two specifications added to this version is intended to serve as support
+      for early adopters of the OpenID Connect technology within the Sweden Connect federation.
+    </li>
+    <li>
+      The specification <a href="18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message
+      Extension in SAML Authentication Requests</a> was added. This specification introduces a SAML Authentication
+      Request extension for Service Providers wishing to pass a custom "authentication message" for the Identity
+      Provider to display for the user during the authentication.
+    </li>
+    <li>
+      The document <a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS
+      Identities to Records in the Swedish Population Register</a> was introduced to describe the process of eIDAS
+      Identity Binding.
+    </li>
+    <li>
+      Section 3.3.2 of <a href="04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification
+      for the Swedish eID Framework</a> was updated with extended descriptions of how the <i>mappedPersonalIdentityNumber</i>
+      and <i>personalIdentityNumberBinding</i> attributes should be consumed when eIDAS Identity Binding has been
+      applied.
+    </li>
+    <li>
+      The <a href="12_-_BankID_Profile_for_the_Swedish_eID_Framework.html">BankID Profile for the Swedish eID
+      Framework</a> was updated to reflect the latest changes in the BankID API:s.
+    </li>
+    <li>
+      New Sign Response status codes were defined in section 2.2.2 of <a
+        href="07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for
+      using DSS in Central Signing Services</a>.
+    </li>
+    <li>
+      In section 3.1, of <a href="09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated
+      Signing Services</a>, the requirements for <code>NotBefore</code> and <code>NotOnOrAfter</code> to be present
+      under the <code>saml:Conditions</code> element was removed. The reason for this is that it will always be the
+      SignService itself that determines whether a message has expired or not.
+    </li>
+  </ul>
+  <p>
+    Each document also contains a "Changes between versions" section where you can see what has been updated for
+    that particular specification.
+  </p>
+  <p>
+    For a detailed list of changes you can view all changes in GitHub using this link: <a
+      href="https://github.com/swedenconnect/technical-framework/compare/january-2020...november-2021">https://github.com/swedenconnect/technical-framework/compare</a>.
+  </p>
+
+  <h3 id="introduction">Introduction</h3>
+  <p>Overview that describes the different parts of the Sweden Connect Framework.</p>
+  <blockquote>
     <p>
-      Each document also contains a "Changes between versions" section where you can see what has been updated for
-      that particular specification.
+      <a href="00_-_Tekniskt_ramverk_-_Introduktion.html">En introduktion till Sweden Connect Tekniskt ramverk</a> - In
+      Swedish
     </p>
-		<p>
-			For a detailed list of changes you can view all changes in GitHub
-			using this link: <a
-				href="https://github.com/swedenconnect/technical-framework/compare/january-2020...november-2021">https://github.com/swedenconnect/technical-framework/compare</a>.
-		</p>
     <p>
-      Check out the GitHub project for this release: <a href="https://github.com/swedenconnect/technical-framework/projects/4">https://github.com/swedenconnect/technical-framework/projects/4</a>.
-      Here you can see all the GitHub issues describing each change that was made to the specifications.
+      <a href="00_-_Swedish_eID_Framework_-_Introduction.html">Introduction to the Sweden Connect Technical
+        Framework</a> - In English
     </p>
-
-		<h3 id="introduction">Introduction</h3>
-		<p>Overview that describes the different parts of the Sweden Connect Framework.</p>
-		<blockquote>
-			<p>
-				<a href="00_-_Tekniskt_ramverk_-_Introduktion.html">En introduktion till Sweden Connect Tekniskt ramverk</a> - In Swedish
-			</p>
-			<p>
-				<a href="00_-_Swedish_eID_Framework_-_Introduction.html">Introduction to the Sweden Connect Technical Framework</a> - In English
-			</p>
-		</blockquote>
-		<h3 id="specifications">Specifications</h3>
-		<ul class="list">
-			<li>
-				<a href="03_-_Registry_for_Identifiers.html"><strong>Sweden Connect - Registry for Identifiers</strong></a> - version 1.8
-			</li>
-			<li>
-			  <a href="02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html"><strong>Deployment Profile for the Swedish eID Framework</strong></a> - version 1.8
-		  </li>
-			<li>
-				<a href="OpenID_Connect_Profile_for_Sweden_Connect.html">OpenID Connect Profile for Sweden Connect</a> - version 1.0
-			</li>
-			<li>
-			  <a href="04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html"><strong>Attribute Specification for the Swedish eID Framework</strong></a> - version 1.8
-			</li>
-			<li>
-				<a href="OpenID_Connect_Claims_and_Scopes_Specification.html">OpenID Connect Claims and Scopes Specification for Sweden Connect</a> - version 1.0
-			</li>
-			<li>
-			  <a href="06_-_Entity_Categories_for_the_Swedish_eID_Framework.html"><strong>Entity Categories for the Swedish eID Framework</strong></a> - version 1.9
-		  </li>
-			<li>
-				<a href="11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html"><strong>eIDAS Constructed Attributes Specification for the Swedish eID Framework</strong></a> - version 1.2
-			</li>
-			<li>
-				<a href="14_-_Principal_Selection_in_SAML_Authentication_Requests.html"><strong>Principal Selection in SAML Authentication Requests</strong></a> - version 1.0
-			</li>
-			<li>
-				<a href="18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a> - version 1.0
-			</li>
-			<li>
-				<a href="12_-_BankID_Profile_for_the_Swedish_eID_Framework.html"><strong>BankID Profile for the Swedish eID Framework</strong></a> - version 1.4
-			</li>
-			<li>
-			  <a href="07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html"><strong>Implementation Profile for using DSS in Central Signing Services</strong></a> - version 1.6
-		  </li>
-			<li>
-			  <a href="08_-_Certificate_Profile_for_Central_Signing_Services.html"><strong>Certificate Profile for Central Signing Services</strong></a> - version 1.2
-		  </li>
-			<li>
-			  <a href="09_-_DSS_Extension_for_Federated_Signing_Services.html"><strong>DSS Extension for Federated Signing Services</strong></a> - version 1.5
-			</li>
-			<li>
-			  <a href="13_-_Signature_Activation_Protocol.html"><strong>Signature Activation Protocol</strong></a> - version 1.2
-			</li>
-		</ul>
-		<blockquote>
-			<p>
-				All specifications are also available in Markdown format on GitHub -
-				<a href="https://github.com/swedenconnect/technical-framework">https://github.com/swedenconnect/technical-framework</a>.
-				Here you can follow the further development of the Sweden Connect Framework.
-			</p>
-		</blockquote>
-	</article>
+  </blockquote>
+  <h3 id="specifications">Specifications</h3>
+  <ul class="list">
+    <li>
+      <a href="03_-_Registry_for_Identifiers.html"><strong>Sweden Connect - Registry for Identifiers</strong></a> -
+      version 1.8
+    </li>
+    <li>
+      <a href="02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html"><strong>Deployment Profile for the Swedish
+        eID Framework</strong></a> - version 1.8
+    </li>
+    <li>
+      <a href="OpenID_Connect_Profile_for_Sweden_Connect.html"><strong>OpenID Connect Profile for Sweden Connect</strong></a> - version
+      1.0
+    </li>
+    <li>
+      <a href="04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html"><strong>Attribute Specification for the
+        Swedish eID Framework</strong></a> - version 1.8
+    </li>
+    <li>
+      <a href="OpenID_Connect_Claims_and_Scopes_Specification.html"><strong>OpenID Connect Claims and Scopes Specification for
+        Sweden Connect</strong></a> - version 1.0
+    </li>
+    <li>
+      <a href="06_-_Entity_Categories_for_the_Swedish_eID_Framework.html"><strong>Entity Categories for the Swedish eID
+        Framework</strong></a> - version 1.9
+    </li>
+    <li>
+      <a href="11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html"><strong>eIDAS
+        Constructed Attributes Specification for the Swedish eID Framework</strong></a> - version 1.2
+    </li>
+    <li>
+      <a href="14_-_Principal_Selection_in_SAML_Authentication_Requests.html"><strong>Principal Selection in SAML
+        Authentication Requests</strong></a> - version 1.0
+    </li>
+    <li>
+      <a href="18_-_User_Message_Extension_in_SAML_Authentication_Requests.html"><strong>User Message Extension in SAML
+        Authentication Requests</strong></a> - version 1.0
+    </li>
+    <li>
+      <a href="12_-_BankID_Profile_for_the_Swedish_eID_Framework.html"><strong>BankID Profile for the Swedish eID
+        Framework</strong></a> - version 1.4
+    </li>
+    <li>
+      <a href="07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html"><strong>Implementation
+        Profile for using DSS in Central Signing Services</strong></a> - version 1.6
+    </li>
+    <li>
+      <a href="08_-_Certificate_Profile_for_Central_Signing_Services.html"><strong>Certificate Profile for Central
+        Signing Services</strong></a> - version 1.2
+    </li>
+    <li>
+      <a href="09_-_DSS_Extension_for_Federated_Signing_Services.html"><strong>DSS Extension for Federated Signing
+        Services</strong></a> - version 1.5
+    </li>
+    <li>
+      <a href="13_-_Signature_Activation_Protocol.html"><strong>Signature Activation Protocol</strong></a> - version 1.2
+    </li>
+  </ul>
+  <blockquote>
+    <p>
+      All specifications are also available in Markdown format on GitHub -
+      <a href="https://github.com/swedenconnect/technical-framework">https://github.com/swedenconnect/technical-framework</a>.
+      Here you can follow the further development of the Sweden Connect Framework.
+    </p>
+  </blockquote>
+</article>
 </body>
 </html>
diff --git a/docs/latest/00_-_Swedish_eID_Framework_-_Introduction.html b/docs/latest/00_-_Swedish_eID_Framework_-_Introduction.html
index 39f4da6..add31a8 120000
--- a/docs/latest/00_-_Swedish_eID_Framework_-_Introduction.html
+++ b/docs/latest/00_-_Swedish_eID_Framework_-_Introduction.html
@@ -1 +1 @@
-../updates/00_-_Swedish_eID_Framework_-_Introduction.html
\ No newline at end of file
+../december-2024/00_-_Swedish_eID_Framework_-_Introduction.html
\ No newline at end of file
diff --git a/docs/latest/00_-_Tekniskt_ramverk_-_Introduktion.html b/docs/latest/00_-_Tekniskt_ramverk_-_Introduktion.html
index 20d8fb8..3b2d32b 120000
--- a/docs/latest/00_-_Tekniskt_ramverk_-_Introduktion.html
+++ b/docs/latest/00_-_Tekniskt_ramverk_-_Introduktion.html
@@ -1 +1 @@
-../updates/00_-_Tekniskt_ramverk_-_Introduktion.html
\ No newline at end of file
+../december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html
\ No newline at end of file
diff --git a/docs/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html b/docs/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
index dd12be3..c34f5eb 120000
--- a/docs/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
+++ b/docs/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/03_-_Registry_for_Identifiers.html b/docs/latest/03_-_Registry_for_Identifiers.html
index 42e4679..6487b0e 120000
--- a/docs/latest/03_-_Registry_for_Identifiers.html
+++ b/docs/latest/03_-_Registry_for_Identifiers.html
@@ -1 +1 @@
-../november-2021/03_-_Registry_for_Identifiers.html
\ No newline at end of file
+../december-2024/03_-_Registry_for_Identifiers.html
\ No newline at end of file
diff --git a/docs/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html b/docs/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
index e40e71e..2841068 120000
--- a/docs/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
+++ b/docs/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html b/docs/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
index 29a9773..4cd40cf 120000
--- a/docs/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
+++ b/docs/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html b/docs/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
index f88a8a9..9dca9cc 120000
--- a/docs/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
+++ b/docs/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
@@ -1 +1 @@
-../november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
\ No newline at end of file
+../december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html b/docs/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html
index cf8774d..d4381da 120000
--- a/docs/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html
+++ b/docs/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html
@@ -1 +1 @@
-../november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html
\ No newline at end of file
+../december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html b/docs/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html
index 8682a61..86f50f6 120000
--- a/docs/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html
+++ b/docs/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html
@@ -1 +1 @@
-../november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html
\ No newline at end of file
+../december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html b/docs/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
index d10a54f..8ef2f45 120000
--- a/docs/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
+++ b/docs/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html b/docs/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
index 79304ff..a02897a 120000
--- a/docs/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
+++ b/docs/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/13_-_Signature_Activation_Protocol.html b/docs/latest/13_-_Signature_Activation_Protocol.html
index 9038148..0f17b6d 120000
--- a/docs/latest/13_-_Signature_Activation_Protocol.html
+++ b/docs/latest/13_-_Signature_Activation_Protocol.html
@@ -1 +1 @@
-../november-2021/13_-_Signature_Activation_Protocol.html
\ No newline at end of file
+../december-2024/13_-_Signature_Activation_Protocol.html
\ No newline at end of file
diff --git a/docs/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html b/docs/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
index f80c2ae..c843de4 120000
--- a/docs/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
+++ b/docs/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
@@ -1 +1 @@
-../november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
\ No newline at end of file
+../december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
\ No newline at end of file
diff --git a/docs/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html b/docs/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
new file mode 120000
index 0000000..38d335a
--- /dev/null
+++ b/docs/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
@@ -0,0 +1 @@
+../december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0600_-_Tekniskt_ramverk_-_Introduktion.html b/docs/latest/ELN-0600_-_Tekniskt_ramverk_-_Introduktion.html
deleted file mode 120000
index 5c908d5..0000000
--- a/docs/latest/ELN-0600_-_Tekniskt_ramverk_-_Introduktion.html
+++ /dev/null
@@ -1 +0,0 @@
-00_-_Tekniskt_ramverk_-_Introduktion.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0602_-_Deployment_Profile_for_the_Swedish_eID_Framework.html b/docs/latest/ELN-0602_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
deleted file mode 120000
index 2a40b5a..0000000
--- a/docs/latest/ELN-0602_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1 +0,0 @@
-02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0603_-_Registry_for_Identifiers.html b/docs/latest/ELN-0603_-_Registry_for_Identifiers.html
deleted file mode 120000
index 8814a52..0000000
--- a/docs/latest/ELN-0603_-_Registry_for_Identifiers.html
+++ /dev/null
@@ -1 +0,0 @@
-03_-_Registry_for_Identifiers.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0604_-_Attribute_Specification_for_the_Swedish_eID_Framework.html b/docs/latest/ELN-0604_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
deleted file mode 120000
index 1932c65..0000000
--- a/docs/latest/ELN-0604_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1 +0,0 @@
-04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0606_-_Entity_Categories_for_the_Swedish_eID_Framework.html b/docs/latest/ELN-0606_-_Entity_Categories_for_the_Swedish_eID_Framework.html
deleted file mode 120000
index 905ebde..0000000
--- a/docs/latest/ELN-0606_-_Entity_Categories_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1 +0,0 @@
-06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0607_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html b/docs/latest/ELN-0607_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
deleted file mode 120000
index 4828740..0000000
--- a/docs/latest/ELN-0607_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
+++ /dev/null
@@ -1 +0,0 @@
-07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0608_-_Certificate_Profile_for_Central_Signing_Services.html b/docs/latest/ELN-0608_-_Certificate_Profile_for_Central_Signing_Services.html
deleted file mode 120000
index a18101a..0000000
--- a/docs/latest/ELN-0608_-_Certificate_Profile_for_Central_Signing_Services.html
+++ /dev/null
@@ -1 +0,0 @@
-08_-_Certificate_Profile_for_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0609_-_DSS_Extension_for_Federated_Signing_Services.html b/docs/latest/ELN-0609_-_DSS_Extension_for_Federated_Signing_Services.html
deleted file mode 120000
index 9878a75..0000000
--- a/docs/latest/ELN-0609_-_DSS_Extension_for_Federated_Signing_Services.html
+++ /dev/null
@@ -1 +0,0 @@
-09_-_DSS_Extension_for_Federated_Signing_Services.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0611_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html b/docs/latest/ELN-0611_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
deleted file mode 120000
index e233ff8..0000000
--- a/docs/latest/ELN-0611_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1 +0,0 @@
-11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0612_-_BankID_Profile_for_the_Swedish_eID_Framework.html b/docs/latest/ELN-0612_-_BankID_Profile_for_the_Swedish_eID_Framework.html
deleted file mode 120000
index cc6a6b8..0000000
--- a/docs/latest/ELN-0612_-_BankID_Profile_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1 +0,0 @@
-12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0613_-_Signature_Activation_Protocol.html b/docs/latest/ELN-0613_-_Signature_Activation_Protocol.html
deleted file mode 120000
index 2acc9db..0000000
--- a/docs/latest/ELN-0613_-_Signature_Activation_Protocol.html
+++ /dev/null
@@ -1 +0,0 @@
-13_-_Signature_Activation_Protocol.html
\ No newline at end of file
diff --git a/docs/latest/ELN-0614_-_Principal_Selection_in_SAML_Authentication_Requests.html b/docs/latest/ELN-0614_-_Principal_Selection_in_SAML_Authentication_Requests.html
deleted file mode 120000
index d43544a..0000000
--- a/docs/latest/ELN-0614_-_Principal_Selection_in_SAML_Authentication_Requests.html
+++ /dev/null
@@ -1 +0,0 @@
-14_-_Principal_Selection_in_SAML_Authentication_Requests.html
\ No newline at end of file
diff --git a/docs/latest/OpenID_Connect_Claims_and_Scopes_Specification.html b/docs/latest/OpenID_Connect_Claims_and_Scopes_Specification.html
new file mode 120000
index 0000000..1c38ad2
--- /dev/null
+++ b/docs/latest/OpenID_Connect_Claims_and_Scopes_Specification.html
@@ -0,0 +1 @@
+../december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html
\ No newline at end of file
diff --git a/docs/latest/OpenID_Connect_Profile_for_Sweden_Connect.html b/docs/latest/OpenID_Connect_Profile_for_Sweden_Connect.html
new file mode 120000
index 0000000..2954279
--- /dev/null
+++ b/docs/latest/OpenID_Connect_Profile_for_Sweden_Connect.html
@@ -0,0 +1 @@
+../december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html
\ No newline at end of file
diff --git a/docs/november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html b/docs/november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
index 6ef70a5..882b1b6 100644
--- a/docs/november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
+++ b/docs/november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
@@ -19,7 +19,7 @@
 </p>
 
 <h1 id="implementation-profile-for-using-oasis-dss-in-central-signing-services">Implementation Profile for using OASIS DSS in Central Signing Services</h1>
-<h3 id="version-16---2024-11-26---draft-version">Version 1.6 - 2024-11-26 - <em>Draft version</em></h3>
+<h3 id="version-16---2024-12-04">Version 1.6 - 2024-12-04</h3>
 <p>Registration number: <strong>2019-312</strong></p>
 <hr>
 <p class="copyright-statement">
@@ -30,7 +30,7 @@ <h2 id="table-of-contents">Table of Contents</h2>
 <ol class="list">
 <li><p><a href="#introduction"><strong>Introduction</strong></a></p>
 <p> 1.1. <a href="#terminology">Terminology</a></p>
-<p> 1.2. <a href="#requirement-key-words">Requirement key words</a></p>
+<p> 1.2. <a href="#requirements-notation">Requirements Notation</a></p>
 <p> 1.3. <a href="#namespace-references">Namespace references</a></p>
 <p> 1.4. <a href="#identification">Identification</a></p>
 <p> 1.5. <a href="#structure">Structure</a></p>
@@ -105,9 +105,9 @@ <h3 id="11-terminology">1.1. Terminology</h3>
 <td>A centralized service that manages the process to authenticate the user that has been requested to sign a document, and the process to obtain the user’s signature on the requested document.</td>
 </tr>
 </tbody></table>
-<p><a name="requirement-key-words"></a></p>
-<h3 id="12-requirement-key-words">1.2. Requirement key words</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
+<p><a name="requirements-notation"></a></p>
+<h3 id="12-requirements-notation">1.2. Requirements Notation</h3>
+<p>The keywords <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
 <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
 <strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
 [<a href="#rfc2119">RFC2119</a>].</p>
@@ -302,14 +302,14 @@ <h6 id="21381-signmessage-element">2.1.3.8.1. SignMessage Element</h6>
 </tbody></table>
 <p>Allowed HTML entities for character replacement SHALL be restricted to
 <code>amp</code>, <code>gt</code>, <code>lt</code>, <code>quot</code> and <code>nbsp</code> (in the form <code>&amp;entity-name;</code>).</p>
-<p>HTML messages MUST NOT contain any URI references to data outside of the
+<p>HTML messages MUST NOT contain any URI references to data outside the
 message and MUST NOT contain any JavaScript in any form.</p>
 <p><a name="requesting-identity-provider-to-display-signmessage"></a></p>
 <h6 id="21382-requesting-identity-provider-to-display-signmessage">2.1.3.8.2. Requesting Identity Provider to Display SignMessage</h6>
 <p>The means through which the Service Provider requests the Identity
 Provider to display a sign message is defined in section 7.1.1 of “Deployment Profile
-for the Swedish eID Framework” [<a href="#eid-profile">Eid-Profile</a>].</p>
-<p>In addition to the requirements in section 7.1.1 of [<a href="#eid-profile">Eid-Profile</a>] the 
+for the Swedish eID Framework” [<a href="#sc-saml-profile">SC.SAML.Profile</a>].</p>
+<p>In addition to the requirements in section 7.1.1 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] the 
 Signature Service MUST apply the following process regarding the inclusion of the
 <code>AuthnContextClassRef</code> URI to include in the <code>AuthnRequest</code> sent to the Identity Provider 
 when authenticating the user for signing:</p>
@@ -328,8 +328,8 @@ <h6 id="21382-requesting-identity-provider-to-display-signmessage">2.1.3.8.2. Re
 <p><a name="certrequestproperties"></a></p>
 <h5 id="2139-certrequestproperties">2.1.3.9. CertRequestProperties</h5>
 <p>This element MAY be present to provide requested properties of generated
-signature certificates according with section 3.1.1 of [<a href="#dss-ext">DSS-Ext</a>].</p>
-<p>When the <code>CertType</code> attribute is present with a value of <code>QC/SSCD</code> the signature service MUST request authentication in accordance with section 7.1.2 of “Deployment Profile for the Swedish eID Framework” [<a href="#eid-profile">Eid-Profile</a>], or reject the request.</p>
+signature certificates according to section 3.1.1 of [<a href="#dss-ext">DSS-Ext</a>].</p>
+<p>When the <code>CertType</code> attribute is present with a value of <code>QC/SSCD</code> the signature service MUST request authentication in accordance with section 7.1.2 of “Deployment Profile for the Swedish eID Framework” [<a href="#sc-saml-profile">SC.SAML.Profile</a>], or reject the request.</p>
 <p><a name="authncontextclassref"></a></p>
 <h6 id="21391-authncontextclassref">2.1.3.9.1. AuthnContextClassRef</h6>
 <p>This element MAY be present to specify the Level of Assurance(s) required
@@ -400,7 +400,7 @@ <h4 id="222-sign-response-status-information">2.2.2. Sign Response Status Inform
 | <code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code> | The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud). |</p>
 <p><strong>Note:</strong> The <code>authn-failed</code> and <code>security-violation</code> codes were introduced for version 1.5 (of [<a href="#dss-ext">DSS-Ext</a>]), and a client not supporting this version will fail to understand these error codes. Whether a Signature Service checks the client version support or not before using these codes are out of scope for this profile. </p>
 <blockquote>
-<p>[*]: Also listed in section 3.1.7 of [<a href="#eid-registry">Eid-Registry</a>].</p>
+<p>[*]: Also listed in section 3.1.7 of [<a href="#sc-registry">SC.Registry</a>].</p>
 </blockquote>
 <p><a name="generated-signature"></a></p>
 <h4 id="223-generated-signature">2.2.3. Generated Signature</h4>
@@ -419,14 +419,14 @@ <h5 id="2241-version">2.2.4.1. Version</h5>
 request was processed and response was constructed. This version MUST be the same
 version as given in the <code>SignRequestExtension</code> (see section <a href="#version">2.1.3.1</a>, &quot;<a href="#version">Version</a>)&quot;.</p>
 <p>For backwards compatibility reasons that attribute MAY be absent if version &quot;1.1&quot; was requested. 
-Otherwise it MUST be set.</p>
+Otherwise, it MUST be set.</p>
 <p><a name="responsetime"></a></p>
 <h5 id="2242-responsetime">2.2.4.2. ResponseTime</h5>
 <p>The <code>&lt;ResponseTime&gt;</code> element MUST be present in the response.</p>
 <p><a name="request"></a></p>
 <h5 id="2243-request">2.2.4.3. Request</h5>
 <p>The <code>&lt;Request&gt;</code> element MAY be present in a response. However, it is RECOMMENDED not to include this
-element since it makes the response message unnecessary large. Instead the requester of a sign operation
+element since it makes the response message unnecessary large, instead the requester of a sign operation
 is expected to save the request message in its session for later use when processing a response message.</p>
 <p><a name="signerassertioninfo"></a></p>
 <h5 id="2244-signerassertioninfo">2.2.4.4. SignerAssertionInfo</h5>
@@ -609,20 +609,20 @@ <h3 id="41-normative-references">4.1. Normative References</h3>
 <blockquote>
 <p>XML Signature Schema. World Wide Web Consortium. See <a href="https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd</a>.</p>
 </blockquote>
-<p><a name="eid-profile"></a>
-<strong>[Eid-Profile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
 <p><a name="dss-ext"></a>
 <strong>[DSS-Ext]</strong></p>
 <blockquote>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
 </blockquote>
-<p><a name="eid-registry"></a>
-<strong>[Eid-Registry]</strong></p>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
+</blockquote>
+<p><a name="sc-registry"></a>
+<strong>[SC.Registry]</strong></p>
 <blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Sweden Connect - Registry for identifiers</a>.</p>
 </blockquote>
 <p><a name="informative-references"></a></p>
 <h3 id="42-informative-references">4.2. Informative References</h3>
@@ -635,7 +635,7 @@ <h3 id="42-informative-references">4.2. Informative References</h3>
 <h2 id="5-changes-between-versions">5. Changes between versions</h2>
 <p><strong>Changes between version 1.5 and version 1.6:</strong></p>
 <ul class="list">
-<li><p>Section 2.2.2, &quot;Sign Response Status Information&quot;, now defines the DSS status codes previously only appearing in [[Eid-Registry(#eid-registry)]. The status codes <code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code> and <code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code> were also introduced.</p>
+<li><p>Section 2.2.2, &quot;Sign Response Status Information&quot;, now defines the DSS status codes previously only appearing in [<a href="#sc-registry">SC.Registry</a>]. The status codes <code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code> and <code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code> were also introduced.</p>
 </li>
 <li><p>Section 2.1.3.2, &quot;Conditions&quot;, was updated with requirements on how to interpret <code>NotBefore</code> and/or <code>NotOnOrAfter</code> values.</p>
 </li>
@@ -659,11 +659,11 @@ <h2 id="5-changes-between-versions">5. Changes between versions</h2>
 </ul>
 <p><strong>Changes between version 1.2 and version 1.3:</strong></p>
 <ul class="list">
-<li>In section 2.1.3.9, &quot;CertRequestProperties&quot;, an requirement to adapt authentication request procedures when the requested signature is a qualified electronic signature was added.</li>
+<li>In section 2.1.3.9, &quot;CertRequestProperties&quot;, a requirement to adapt authentication request procedures when the requested signature is a qualified electronic signature was added.</li>
 </ul>
 <p><strong>Changes between version 1.1 and version 1.2:</strong></p>
 <ul class="list">
-<li>In section 2.2.2, a reference to section 3.1.5 in [Eid-Registry] was changed to section 3.1.7.</li>
+<li>In section 2.2.2, a reference to section 3.1.5 in [SC.Registry] was changed to section 3.1.7.</li>
 </ul>
 <p><strong>Changes between version 1.0 and version 1.1:</strong></p>
 <ul class="list">
diff --git a/docs/november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html b/docs/november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html
index 972de5d..8ee4f82 100644
--- a/docs/november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html
+++ b/docs/november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html
@@ -19,7 +19,7 @@
 </p>
 
 <h1 id="certificate-profile-for-certificates-issued-by-central-signing-services">Certificate Profile for Certificates Issued by Central Signing Services</h1>
-<h3 id="version-1.2---2020-01-17">Version 1.2 - 2020-01-17</h3>
+<h3 id="version-12---2020-01-17">Version 1.2 - 2020-01-17</h3>
 <p>Registration number: <strong>2019-313</strong> (<em>previously: ELN-0608</em>)</p>
 <hr>
 <h2 id="table-of-contents">Table of Contents</h2>
@@ -49,12 +49,12 @@ <h2 id="table-of-contents">Table of Contents</h2>
 </ol>
 <hr>
 <p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
+<h2 id="1-introduction">1. Introduction</h2>
 <p>This document specifies a certificate profile for certificates issued by
 a signature service based on the OASIS DSS protocol [<a href="#dss">DSS</a>], enhanced by
 the DSS Extensions for Federated Central Signing Services [<a href="#dss-ext">DSS-Ext</a>].</p>
 <p><a name="requirement-key-words"></a></p>
-<h3 id="1.1.-requirement-key-words">1.1. Requirement key words</h3>
+<h3 id="11-requirement-key-words">1.1. Requirement key words</h3>
 <p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
 <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
 <strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
@@ -64,7 +64,7 @@ <h3 id="1.1.-requirement-key-words">1.1. Requirement key words</h3>
 interoperability and security of implementations. When these words are
 not capitalized, they are meant in their natural-language sense.</p>
 <p><a name="xml-namespace-references"></a></p>
-<h3 id="1.2.-xml-namespace-references">1.2. XML namespace references</h3>
+<h3 id="12-xml-namespace-references">1.2. XML namespace references</h3>
 <p>The prefix <strong>saci:</strong> stands for the SAML Authentication Context Information XML Schema 
 namespace, <code>http://id.elegnamnden.se/auth-cont/1.0/saci</code>.</p>
 <blockquote>
@@ -76,14 +76,14 @@ <h3 id="1.2.-xml-namespace-references">1.2. XML namespace references</h3>
 <p>Schema location URL: <a href="https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-ExtAuthInfo-1.0.xsd">https://docs.swedenconnect.se/schemas/cert-schemas/1.0/CertAuthContextExtension-ExtAuthInfo-1.0.xsd</a></p>
 </blockquote>
 <p><a name="structure"></a></p>
-<h3 id="1.3.-structure">1.3. Structure</h3>
+<h3 id="13-structure">1.3. Structure</h3>
 <p>This specification uses the following typographical conventions in text:
 <code>&lt;Eid2Element&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
 <code>OtherCode</code>.</p>
 <p><a name="certificate-profile"></a></p>
-<h2 id="2.-certificate-profile">2. Certificate Profile</h2>
+<h2 id="2-certificate-profile">2. Certificate Profile</h2>
 <p><a name="standards"></a></p>
-<h3 id="2.1.-standards">2.1. Standards</h3>
+<h3 id="21-standards">2.1. Standards</h3>
 <p>The following standards provides normative requirements for this
 certificate profile:</p>
 <table>
@@ -94,8 +94,7 @@ <h3 id="2.1.-standards">2.1. Standards</h3>
 <th>Reference</th>
 </tr>
 </thead>
-<tbody>
-<tr>
+<tbody><tr>
 <td>RFC 5280</td>
 <td>Main certificate standard</td>
 <td>[<a href="#rfc5280">RFC5280</a>]</td>
@@ -130,21 +129,20 @@ <h3 id="2.1.-standards">2.1. Standards</h3>
 <td>Declaration of qualified certificate properties</td>
 <td>[<a href="#eu-cert-qc">EU-CERT-QC</a>]</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="qualified-and-pkc-certificates"></a></p>
-<h3 id="2.2.-qualified-and-pkc-certificates">2.2. Qualified and PKC Certificates</h3>
+<h3 id="22-qualified-and-pkc-certificates">2.2. Qualified and PKC Certificates</h3>
 <p>This profile supports both Qualified Certificates as well as certificates that are not Qualified Certificates, here named PKC certificates (Public Key Certificates).</p>
 <p>All profile requirements apply to both Qualified Certificates and to PKC certificates unless it is explicitly stated that a particular requirement applies only to PKC or Qualified Certificates.</p>
 <p><a name="certificate-content"></a></p>
-<h3 id="2.3.-certificate-content">2.3. Certificate Content</h3>
+<h3 id="23-certificate-content">2.3. Certificate Content</h3>
 <p>All certificates SHALL be fully compliant with  [<a href="#rfc5280">RFC5280</a>] and [<a href="#en-cert-np">EU-CERT-NP</a>]. All Qualified Certificates SHALL also implement mandatory QC statements as defined in [<a href="#eu-cert-qc">EU-CERT-QC</a>].</p>
 <p><a name="subject-attributes-and-name-forms"></a></p>
-<h4 id="2.3.1.-subject-attributes-and-name-forms">2.3.1. Subject Attributes and Name Forms</h4>
+<h4 id="231-subject-attributes-and-name-forms">2.3.1. Subject Attributes and Name Forms</h4>
 <p><a name="person-identifier-attributes"></a></p>
-<h5 id="2.3.1.1.-person-identifier-attributes">2.3.1.1. Person Identifier Attributes</h5>
+<h5 id="2311-person-identifier-attributes">2.3.1.1. Person Identifier Attributes</h5>
 <p><a name="data-source"></a></p>
-<h6 id="2.3.1.1.1.-data-source">2.3.1.1.1. Data Source</h6>
+<h6 id="23111-data-source">2.3.1.1.1. Data Source</h6>
 <p>All certificates SHALL contain a unique person identifier, carried in the <code>serialNumber</code> attribute (OID 2.5.4.5) in the subject field. The person identifier SHALL be obtained from the Identity Provider in the form of a SAML attribute. For PKC certificates, the SAML attribute SHOULD be one of the attributes listed below. For Qualified Certificates, the SAML attribute SHALL be one of the attributes listed below.</p>
 <table>
 <thead>
@@ -154,8 +152,7 @@ <h6 id="2.3.1.1.1.-data-source">2.3.1.1.1. Data Source</h6>
 <th>Specification</th>
 </tr>
 </thead>
-<tbody>
-<tr>
+<tbody><tr>
 <td>Swedish Personal Identity Number (personnummer)</td>
 <td>urn:oid:1.2.752.29.4.13</td>
 <td>[<a href="#attrspec">AttrSpec</a>]</td>
@@ -170,10 +167,9 @@ <h6 id="2.3.1.1.1.-data-source">2.3.1.1.1. Data Source</h6>
 <td>urn:oid:1.2.752.201.3.7</td>
 <td>[<a href="#attrspec">AttrSpec</a>]</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="data-format"></a></p>
-<h6 id="2.3.1.1.1.-data-format">2.3.1.1.1. Data Format</h6>
+<h6 id="23111-data-format">2.3.1.1.1. Data Format</h6>
 <p>The identifier data obtained from the SAML assertion SHALL be stored in the <code>serialNumber</code> attribute using one of the following formats:</p>
 <ul class="list">
 <li>using exactly the same format as it was obtained from the SAML attribute, or,</li>
@@ -202,10 +198,10 @@ <h6 id="2.3.1.1.1.-data-format">2.3.1.1.1. Data Format</h6>
 <p>A new version of the [<a href="#eu-cert-gen">EU-CERT-GEN</a>] is processed for approval at the time of publication of this document. The new version will specify a semantics identifier for storing eIDAS person identifier attributes using the semantics identifier OID <code>0.4.0.194121.1.3</code>. This semantics identifier (<code>id-etsi-qcs-semanticsId-eIDASNatural</code>) is not yet present in the latest published version of the standard.</p>
 </blockquote>
 <p><a name="other-attribute-requirements"></a></p>
-<h5 id="2.3.1.2.-other-attribute-requirements">2.3.1.2. Other Attribute Requirements</h5>
+<h5 id="2312-other-attribute-requirements">2.3.1.2. Other Attribute Requirements</h5>
 <p>An e-mail address, when present, SHALL be stored in a Subject Alternative Name extension as an rfc822Name.</p>
 <p><a name="authentication-context-and-attribute-mapping"></a></p>
-<h4 id="2.3.2.-authentication-context-and-attribute-mapping">2.3.2. Authentication Context and Attribute Mapping</h4>
+<h4 id="232-authentication-context-and-attribute-mapping">2.3.2. Authentication Context and Attribute Mapping</h4>
 <p>Certificates MUST include an <code>AuthContextExtension</code> according to [<a href="#rfc7773">RFC7773</a>]. This extension SHALL include one SAML Authentication Context Information element identified by the XML schema namespace identifier:</p>
 <blockquote>
 <p><code>http://id.elegnamnden.se/auth-cont/1.0/saci</code></p>
@@ -217,45 +213,45 @@ <h4 id="2.3.2.-authentication-context-and-attribute-mapping">2.3.2. Authenticati
 <code>&lt;saci:AttributeMapping&gt;</code> element SHALL provide the <code>&lt;saml:AttributeValue&gt;</code> that were obtained from
 the SAML assertion.</p>
 <p><a name="extended-authentication-information"></a></p>
-<h5 id="2.3.2.1.-extended-authentication-information">2.3.2.1. Extended Authentication Information</h5>
+<h5 id="2321-extended-authentication-information">2.3.2.1. Extended Authentication Information</h5>
 <p>In addition to the attributes of <code>&lt;saci:AuthContextInfo&gt;</code> it is possible to provide additional authentication information through the extensibility of the <code>&lt;saci:AuthContextInfo&gt;</code> element which allows inclusion of a sequence of any element.</p>
 <p>One such element is defined in this section, the <code>&lt;sacex:ExtAuthInfo&gt;</code> element.</p>
 <p>This element MAY be included to provide a name of a parameter and its associated value. </p>
 <p>This element MAY be used to carry the value of any single valued attribute from the associated SAML assertion as long as the SAML attribute value is not composed of a complex type. When used to carry a SAML attribute value, the value of the <code>&lt;sacex:ExtAuthInfo&gt;</code> element SHALL be identical to the content of the SAML attribute value element and the <code>Name</code> attribute SHALL hold the same value as the <code>Name</code> attribute of the corresponding SAML attribute.</p>
 <p>The <code>&lt;sacex:ExtAuthInfo&gt;</code> element is defined by the following XML Schema:</p>
-<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">"1.0"</span> encoding=<span class="hljs-string">"UTF-8"</span>?&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">"http://www.w3.org/2001/XMLSchema"</span> elementFormDefault=<span class="hljs-string">"qualified"</span>
-    targetNamespace=<span class="hljs-string">"http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info"</span>
-    xmln<span class="hljs-variable">s:sacex</span>=<span class="hljs-string">"http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info"</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"ExtAuthInfo"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"sacex:ExtAuthInfoType"</span> /&gt;
+<pre class="hljs"><code><span class="hljs-meta">&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">xs:schema</span> <span class="hljs-attr">xmlns:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> <span class="hljs-attr">elementFormDefault</span>=<span class="hljs-string">&quot;qualified&quot;</span>
+    <span class="hljs-attr">targetNamespace</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>
+    <span class="hljs-attr">xmlns:sacex</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>&gt;</span>
+    
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:element</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;ExtAuthInfo&quot;</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&quot;sacex:ExtAuthInfoType&quot;</span> /&gt;</span>
 
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"ExtAuthInfoType"</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"Name"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> use=<span class="hljs-string">"required"</span> /&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">"##any"</span> processContents=<span class="hljs-string">"lax"</span> /&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><strong>Example:</strong></p>
+  <span class="hljs-tag">&lt;<span class="hljs-name">xs:complexType</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;ExtAuthInfoType&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">xs:extension</span> <span class="hljs-attr">base</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">xs:attribute</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-attr">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;required&quot;</span> /&gt;</span>
+        <span class="hljs-tag">&lt;<span class="hljs-name">xs:anyAttribute</span> <span class="hljs-attr">namespace</span>=<span class="hljs-string">&quot;##any&quot;</span> <span class="hljs-attr">processContents</span>=<span class="hljs-string">&quot;lax&quot;</span> /&gt;</span>
+      <span class="hljs-tag">&lt;/<span class="hljs-name">xs:extension</span>&gt;</span>
+    <span class="hljs-tag">&lt;/<span class="hljs-name">xs:simpleContent</span>&gt;</span>
+  <span class="hljs-tag">&lt;/<span class="hljs-name">xs:complexType</span>&gt;</span>
+<span class="hljs-tag">&lt;/<span class="hljs-name">xs:schema</span>&gt;</span></code></pre><p><strong>Example:</strong></p>
 <p>The following example illustrates inclusion of the content of a transaction identifier SAML 
 attribute as extended authentication information.</p>
 <pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saci:SAMLAuthContext</span>
-    <span class="hljs-attr">xmlns:saci</span>=<span class="hljs-string">"http://id.elegnamnden.se/auth-cont/1.0/saci"</span>
-    <span class="hljs-attr">xmlns:sacext</span>=<span class="hljs-string">"http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saci:AuthContextInfo</span> <span class="hljs-attr">IdentityProvider</span>=<span class="hljs-string">"http://eid.example.com/idp"</span>
-      <span class="hljs-attr">AuthenticationInstant</span>=<span class="hljs-string">"2020-01-10T17:02:46.000Z"</span>
-      <span class="hljs-attr">AuthnContextClassRef</span>=<span class="hljs-string">"http://id.elegnamnden.se/loa/1.0/loa3"</span>
-      <span class="hljs-attr">AssertionRef</span>=<span class="hljs-string">"_936e075dc2725b016de57b9a0624c766"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">sacext:ExtAuthInfo</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.2"</span>&gt;</span>dc6ac7656H89bfb51<span class="hljs-tag">&lt;/<span class="hljs-name">sacext:ExtAuthInfo</span>&gt;</span>
+    <span class="hljs-attr">xmlns:saci</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/auth-cont/1.0/saci&quot;</span>
+    <span class="hljs-attr">xmlns:sacext</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">saci:AuthContextInfo</span> <span class="hljs-attr">IdentityProvider</span>=<span class="hljs-string">&quot;http://eid.example.com/idp&quot;</span>
+      <span class="hljs-attr">AuthenticationInstant</span>=<span class="hljs-string">&quot;2020-01-10T17:02:46.000Z&quot;</span>
+      <span class="hljs-attr">AuthnContextClassRef</span>=<span class="hljs-string">&quot;http://id.elegnamnden.se/loa/1.0/loa3&quot;</span>
+      <span class="hljs-attr">AssertionRef</span>=<span class="hljs-string">&quot;_936e075dc2725b016de57b9a0624c766&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">sacext:ExtAuthInfo</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.2&quot;</span>&gt;</span>dc6ac7656H89bfb51<span class="hljs-tag">&lt;/<span class="hljs-name">sacext:ExtAuthInfo</span>&gt;</span>
   <span class="hljs-tag">&lt;/<span class="hljs-name">saci:AuthContextInfo</span>&gt;</span>
   <span class="hljs-tag">&lt;<span class="hljs-name">saci:IdAttributes</span>&gt;</span>...<span class="hljs-tag">&lt;/<span class="hljs-name">saci:IdAttributes</span>&gt;</span>
 <span class="hljs-tag">&lt;/<span class="hljs-name">saci:SAMLAuthContext</span>&gt;</span></code></pre><p><a name="certificate-policy"></a></p>
-<h4 id="2.3.3.-certificate-policy">2.3.3. Certificate Policy</h4>
+<h4 id="233-certificate-policy">2.3.3. Certificate Policy</h4>
 <p>Certificates SHALL contain at least one referenced certificate policy. PKC certificates SHALL contain at least one reference to a policy identified in [<a href="#eu-pol-ncp">EU-POL-NCP</a>]. Qualified Certificates SHALL reference at least one certificate policy identified in [<a href="#eu-pol-qc">EU-POL-QC</a>].</p>
 <p><a name="normative-references"></a></p>
-<h2 id="3.-normative-references">3. Normative References</h2>
+<h2 id="3-normative-references">3. Normative References</h2>
 <p><a name="dss"></a>
 <strong>[DSS]</strong></p>
 <blockquote>
@@ -333,7 +329,7 @@ <h2 id="3.-normative-references">3. Normative References</h2>
 Samordningsnummer</a>.</p>
 </blockquote>
 <p><a name="changes-between-versions"></a></p>
-<h2 id="4.-changes-between-versions">4. Changes between versions</h2>
+<h2 id="4-changes-between-versions">4. Changes between versions</h2>
 <p><strong>Changes between version 1.1 and version 1.2:</strong></p>
 <ul class="list">
 <li><p>Update of logotype, fixes of typos and reference list.</p>
diff --git a/docs/november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html b/docs/november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html
index 10891e4..ec4276d 100644
--- a/docs/november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html
+++ b/docs/november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html
@@ -19,7 +19,7 @@
 </p>
 
 <h1 id="dss-extension-for-federated-central-signing-services">DSS Extension for Federated Central Signing Services</h1>
-<h3 id="version-15---2024-11-25---draft-version">Version 1.5 - 2024-11-25 - <em>Draft version</em></h3>
+<h3 id="version-15---2024-12-04">Version 1.5 - 2024-12-04</h3>
 <p>Registration number: <strong>2019-314</strong></p>
 <hr>
 <p class="copyright-statement">
@@ -30,7 +30,7 @@ <h2 id="table-of-contents">Table of Contents</h2>
 <ol class="list">
 <li><p><a href="#introduction"><strong>Introduction</strong></a></p>
 <p> 1.1. <a href="#terminology">Terminology</a></p>
-<p> 1.1.1. <a href="#key-words">Key words</a></p>
+<p> 1.1.1. <a href="#keywords">Keywords</a></p>
 <p> 1.1.2. <a href="#structure">Structure</a></p>
 <p> 1.1.3. <a href="#definitions">Definitions</a></p>
 <p> 1.2. <a href="#schema-organization-and-namespaces">Schema Organization and Namespaces</a></p>
@@ -69,7 +69,7 @@ <h2 id="table-of-contents">Table of Contents</h2>
 <p>Appendix A. <a href="#appendix-a.xml-schema"><strong>XML Schema</strong></a></p>
 <p><a name="introduction"></a></p>
 <h2 id="1-introduction">1. Introduction</h2>
-<p>This specifications defines elements that extend the
+<p>This specification defines elements that extend the
 <code>&lt;dss:SignRequest&gt;</code> and <code>&lt;dss:SignResponse&gt;</code> elements of
 [<a href="#dss">OASIS-DSS</a>].</p>
 <p>One element <code>&lt;SignRequestExtension&gt;</code> is defined for extending sign
@@ -106,9 +106,9 @@ <h2 id="1-introduction">1. Introduction</h2>
 request.</p>
 <p><a name="terminology"></a></p>
 <h3 id="11-terminology">1.1. Terminology</h3>
-<p><a name="key-words"></a></p>
-<h4 id="111--key-words">1.1.1.  Key words</h4>
-<p>The key words <em>MUST</em>, <em>MUST NOT</em>, <em>REQUIRED</em>, <em>SHALL</em>, <em>SHALL NOT</em>,
+<p><a name="keywords"></a></p>
+<h4 id="111--keywords">1.1.1.  Keywords</h4>
+<p>The keywords <em>MUST</em>, <em>MUST NOT</em>, <em>REQUIRED</em>, <em>SHALL</em>, <em>SHALL NOT</em>,
 <em>SHOULD</em>, <em>SHOULD NOT</em>, <em>RECOMMENDED</em>, <em>MAY</em>, and <em>OPTIONAL</em> are to be
 interpreted as described in [<a href="#rfc2119">RFC 2119</a>].</p>
 <p>These keywords are capitalized when used to unambiguously specify
@@ -123,7 +123,7 @@ <h4 id="112-structure">1.1.2. Structure</h4>
 <strong>Datatype</strong>, OtherCode.</p>
 <p>Listings of DSS schemas appear like this.</p>
 <p><a name="definitions"></a></p>
-<h4 id="113--definitions">1.1.3.  Definitions</h4>
+<h4 id="113-definitions">1.1.3. Definitions</h4>
 <p><strong>Identity Provider</strong></p>
 <blockquote>
 <p>An Identity Provider that is assigned to authenticate the signer.</p>
@@ -153,7 +153,7 @@ <h3 id="12-schema-organization-and-namespaces">1.2. Schema Organization and Nam
 different namespace.</p>
 <p>Conventional XML namespace prefixes are used in the schema:</p>
 <ul class="list">
-<li><p>The prefix <code>csig</code>: stands for the this specification&#39;s XML schema
+<li><p>The prefix <code>csig</code>: stands for this specification&#39;s XML schema
   namespace [<a href="#csig-xsd">Csig-XSD</a>].</p>
 </li>
 <li><p>The prefix <code>dss</code>: stands for the DSS core namespace
@@ -202,7 +202,7 @@ <h4 id="131-string-values">1.3.1. String values</h4>
 <p>Unless otherwise noted in this specification, all elements that have the
 XML Schema <strong>xs:string</strong> type, or a type derived from that, MUST be
 compared using an exact binary comparison. In particular,
-implementations MUST NOT depend on case insensitive string comparisons,
+implementations MUST NOT depend on case-insensitive string comparisons,
 normalization or trimming of whitespace, or conversion of
 locale-specific formats such as numbers or currency. This requirement is
 intended to conform to the W3C working group note &quot;Requirements for String
@@ -615,7 +615,7 @@ <h4 id="312-element-signmessage">3.1.2. Element &lt;SignMessage&gt;</h4>
 <p>The MIME type defining the message format. This is an enumeration of
 the valid attribute values <code>text</code> (plain text), <code>text/html</code> (html) or
 <code>text/markdown</code> (markdown). This specification does not specify any
-particular restrictions on the provided message but it is RECOMMENDED
+particular restrictions on the provided message, but it is RECOMMENDED
 that sign message content is restricted to a limited set of valid tags
 and attributes, and that the display entity performs filtering to
 enforce these restrictions before displaying the message. The means
@@ -834,7 +834,7 @@ <h4 id="322-type-certificatechaintype">3.2.2. Type CertificateChainType</h4>
 Certificates MUST be provided in sequence with the end-entity
 certificate first in the sequence followed by any CA certificates that
 can be used to verify the previous certificate in the sequence, ending
-with a self signed root certificate.</p>
+with a self-signed root certificate.</p>
 <p>The <strong>CertificateChainType</strong> complex type has the following elements:</p>
 <p><code>&lt;X509Certificate&gt;</code> [One or More]</p>
 <blockquote>
@@ -1056,7 +1056,7 @@ <h2 id="5-signing-sign-requests-and-responses">5. Signing Sign Requests and Res
 requests and responses for signature creation to protect against
 spoofing and substitution attacks. If a hash of the document to be
 signed is replaced in a sign request, the signer may end up signing
-something completely different than what the requesting service
+something completely different from what the requesting service
 presented to the signer.</p>
 <p>When a <code>&lt;dss:SignRequest&gt;</code> is signed, the signature of that request
 MUST be placed as the last child element in the
@@ -1073,7 +1073,7 @@ <h2 id="6-normative-references">6. Normative References</h2>
 <p><a name="csig-xsd"></a>
 <strong>[Csig-XSD]</strong></p>
 <blockquote>
-<p>This specification&#39;s DSS Extensions schema Version 1.1.3, <a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd</a>, November, 2024.</p>
+<p>This specification&#39;s DSS Extensions schema Version 1.1.3, <a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCentralSigDssExt-1.1.3.xsd</a>, November 2024.</p>
 </blockquote>
 <p><a name="dss"></a>
 <strong>[OASIS-DSS]</strong></p>
diff --git a/docs/november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html b/docs/november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
index 4052224..0f81095 100644
--- a/docs/november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
+++ b/docs/november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
@@ -19,7 +19,7 @@
 </p>
 
 <h1 id="eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</h1>
-<h3 id="version-1.2---2021-11-11">Version 1.2 - 2021-11-11</h3>
+<h3 id="version-12---2021-11-11">Version 1.2 - 2021-11-11</h3>
 <p>Registration number: <strong>2019-315</strong></p>
 <hr>
 <p class="copyright-statement">
@@ -47,7 +47,7 @@ <h2 id="table-of-contents">Table of Contents</h2>
 </ol>
 <p>Appendix A. <a href="#prid-algorithm-implementations-java"><strong>PRID Algorithm implementations (Java)</strong></a></p>
 <p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
+<h2 id="1-introduction">1. Introduction</h2>
 <p>This document extends “Attribute Specification for the Swedish eID
 Framework”, [<a href="#eidattributes">EidAttributes</a>], providing specifications for constructed
 attributes.</p>
@@ -61,7 +61,7 @@ <h2 id="1.-introduction">1. Introduction</h2>
 authenticated user (subject) received from the foreign Identity Provider
 service (typically an eIDAS node).</p>
 <p><a name="requirement-key-words"></a></p>
-<h3 id="1.1.-requirement-key-words">1.1. Requirement key words</h3>
+<h3 id="11-requirement-key-words">1.1. Requirement key words</h3>
 <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
 “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
 interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
@@ -70,7 +70,7 @@ <h3 id="1.1.-requirement-key-words">1.1. Requirement key words</h3>
 interoperability and security of implementations. When these words are
 not capitalized, they are meant in their natural-language sense.</p>
 <p><a name="provisional-identifier"></a></p>
-<h2 id="2.-provisional-identifier">2. Provisional Identifier</h2>
+<h2 id="2-provisional-identifier">2. Provisional Identifier</h2>
 <p>The Attribute Specification for the Swedish eID Framework, [<a href="#eidattributes">EidAttributes</a>], defines the attributes <code>prid</code> and <code>pridPersistence</code>.</p>
 <p>The <code>prid</code> attribute holds a unique identifier for a person derived from
 attributes provided from another country. The purpose of this attribute
@@ -85,7 +85,7 @@ <h2 id="2.-provisional-identifier">2. Provisional Identifier</h2>
 <p>This document defines a set of <code>prid</code> algorithms, when to use each
 algorithm and the resulting <code>pridPersistence</code> value.</p>
 <p><a name="provisional-identifier-prid-attribute"></a></p>
-<h3 id="2.1.-provisional-identifier-(prid)-attribute">2.1. Provisional Identifier (prid) Attribute</h3>
+<h3 id="21-provisional-identifier-prid-attribute">2.1. Provisional Identifier (prid) Attribute</h3>
 <p>The provisional identifier (<code>prid</code>) attribute is a SAML attribute
 identified by the SAML attribute name <code>urn:oid:1.2.752.201.3.4</code>.</p>
 <p>The <code>prid</code> attribute holds a string value containing the following data:</p>
@@ -123,7 +123,7 @@ <h3 id="2.1.-provisional-identifier-(prid)-attribute">2.1. Provisional Identifie
 character, for example, the character sequence “1-2-3-4-56” is not
 allowed as it only holds 6 distinguishing ID characters.</p>
 <p><a name="provisional-identifier-persistence-indicator-pridpersistence-attribute"></a></p>
-<h3 id="2.2.-provisional-identifier-persistence-indicator-(pridpersistence)-attribute">2.2. Provisional Identifier Persistence Indicator (pridPersistence) Attribute</h3>
+<h3 id="22-provisional-identifier-persistence-indicator-pridpersistence-attribute">2.2. Provisional Identifier Persistence Indicator (pridPersistence) Attribute</h3>
 <p>The provisional identifier (<code>pridPersistence</code>) attribute is a SAML
 attribute identified by the SAML attribute name <code>urn:oid:1.2.752.201.3.5</code>.</p>
 <p>The pridPersistence attribute holds a string value containing the
@@ -141,32 +141,30 @@ <h3 id="2.2.-provisional-identifier-persistence-indicator-(pridpersistence)-attr
 <table>
 <thead>
 <tr>
-<th style="text-align:left">Value</th>
-<th style="text-align:left">Defined meaning</th>
+<th align="left">Value</th>
+<th align="left">Defined meaning</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">A</td>
-<td style="text-align:left">Persistence over time is expected to be comparable or better than a Swedish personal identity number (personnummer). This means that the identifier typically is stable throughout the lifetime of the subject and is typically preserved even if the subject changes address, name or civil status.</td>
+<tbody><tr>
+<td align="left">A</td>
+<td align="left">Persistence over time is expected to be comparable or better than a Swedish personal identity number (personnummer). This means that the identifier typically is stable throughout the lifetime of the subject and is typically preserved even if the subject changes address, name or civil status.</td>
 </tr>
 <tr>
-<td style="text-align:left">B</td>
-<td style="text-align:left">Persistence over time is expected to be relatively stable, but lower than a Swedish personal identity number (personnummer). This means that the identifier typically remains unchanged as long as the person does not change address, name or civil status. Such or similar event may cause the identifier to change but the identifier will not change just because the subject gets a new eID (electronic identification means) or changes eID provider.</td>
+<td align="left">B</td>
+<td align="left">Persistence over time is expected to be relatively stable, but lower than a Swedish personal identity number (personnummer). This means that the identifier typically remains unchanged as long as the person does not change address, name or civil status. Such or similar event may cause the identifier to change but the identifier will not change just because the subject gets a new eID (electronic identification means) or changes eID provider.</td>
 </tr>
 <tr>
-<td style="text-align:left">C</td>
-<td style="text-align:left">No expectations regarding persistence over time. The identifier may change if the subject changes eID or eID provider.</td>
+<td align="left">C</td>
+<td align="left">No expectations regarding persistence over time. The identifier may change if the subject changes eID or eID provider.</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="algorithms"></a></p>
-<h3 id="2.3.-algorithms">2.3. Algorithms</h3>
+<h3 id="23-algorithms">2.3. Algorithms</h3>
 <p>This section defines algorithms for generating the identifier component
 of <code>prid</code> attribute values. The identifier component makes up the
 characters following the “:” (colon) character in the <code>prid</code>.</p>
 <p><a name="algorithm-default-eidas"></a></p>
-<h4 id="2.3.1.-algorithm:-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
+<h4 id="231-algorithm-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
 <p><strong>Name:</strong> <code>default-eIDAS</code></p>
 <p><strong>Input values</strong>:</p>
 <ul class="list">
@@ -198,7 +196,7 @@ <h4 id="2.3.1.-algorithm:-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
 <blockquote>
 <p>Return <code>normalizedID</code></p>
 </blockquote>
-<p>If length of <code>normalizedID</code> &gt; 30 characters<strong>:</strong></p>
+<p>If length of <code>normalizedID</code> &gt; 30 characters**:**</p>
 <blockquote>
 <p>Return the string representation of the first 30 hexadecimal digits of
 the SHA256 hash of the UTF-8 encoded bytes of <code>strippedID</code>.</p>
@@ -209,8 +207,8 @@ <h4 id="2.3.1.-algorithm:-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
 fails:</p>
 </blockquote>
 <ol class="list">
-<li>Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
-<li><code>normalizedID</code> &lt; 6 characters (not counting “-“ (hyphen) characters).</li>
+<li> Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
+<li> <code>normalizedID</code> &lt; 6 characters (not counting “-“ (hyphen) characters).</li>
 </ol>
 <p><strong>Collision resistance:</strong></p>
 <p>All eIDAS PersonIdentifier attributes are required to be unique. That
@@ -223,10 +221,10 @@ <h4 id="2.3.1.-algorithm:-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
 <p>In case the normalized identifier string exceeds 30 characters this
 algorithm falls back on providing a 30 hex digit representation of a
 concatenated SHA-2 hash value. The collision probability for such
-identifier among 2 users is 1 in 1,25 * 10\^36 (Calculated as 16\^30 –
-16\^29 since first digit can not be 0). For a population of 100 million
+identifier among 2 users is 1 in 1,25 * 10^36 (Calculated as 16^30 –
+16^29 since first digit can not be 0). For a population of 100 million
 people the probability of a collision is approximately 1 in 2.5 *
-10\^20 or 1 in 250 trillion countries of that population size<sup><a href="#footnote-2-3-1">1</a></sup>.</p>
+10^20 or 1 in 250 trillion countries of that population size<sup><a href="#footnote-2-3-1">1</a></sup>.</p>
 <p>Countries typically do not use ID attributes that exceed 30 characters
 in size, but it cannot be ruled out that some countries will generate an
 ID for cross-border use that is different from a national ID and that
@@ -244,55 +242,53 @@ <h4 id="2.3.1.-algorithm:-default-eidas">2.3.1. Algorithm: default-eIDAS</h4>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">PersonIdentifier</th>
-<th style="text-align:left">Resulting prid</th>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">NO/SE/05068907693</td>
-<td style="text-align:left">NO:05068907693</td>
+<tbody><tr>
+<td align="left">NO/SE/05068907693</td>
+<td align="left">NO:05068907693</td>
 </tr>
 <tr>
-<td style="text-align:left">DK/SE/09208-2002-2-194967071622</td>
-<td style="text-align:left">DK:09208-2002-2-194967071622</td>
+<td align="left">DK/SE/09208-2002-2-194967071622</td>
+<td align="left">DK:09208-2002-2-194967071622</td>
 </tr>
 <tr>
-<td style="text-align:left">UK/DK/1234567890</td>
-<td style="text-align:left">UK:NULL (Failed: target country is not SE)</td>
+<td align="left">UK/DK/1234567890</td>
+<td align="left">UK:NULL (Failed: target country is not SE)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/#12345-3456//ABC</td>
-<td style="text-align:left">DE:12345-3456-abc</td>
+<td align="left">DE/SE/#12345-3456//ABC</td>
+<td align="left">DE:12345-3456-abc</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/aErf#(EAd9)</td>
-<td style="text-align:left">DE:0aerf-ead9</td>
+<td align="left">DE/SE/aErf#(EAd9)</td>
+<td align="left">DE:0aerf-ead9</td>
 </tr>
 <tr>
-<td style="text-align:left">de/se/aErf#(E)</td>
-<td style="text-align:left">NULL (Failed: Less than 6 ID characters)</td>
+<td align="left">de/se/aErf#(E)</td>
+<td align="left">NULL (Failed: Less than 6 ID characters)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/(1952 12 14-1122)</td>
-<td style="text-align:left">DE:19521214-1122</td>
+<td align="left">DE/SE/(1952 12 14-1122)</td>
+<td align="left">DE:19521214-1122</td>
 </tr>
 <tr>
-<td style="text-align:left">19521214-1122</td>
-<td style="text-align:left">NULL (Failed: Leading 6 character format error)</td>
+<td align="left">19521214-1122</td>
+<td align="left">NULL (Failed: Leading 6 character format error)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/1234567890123456789012345678901</td>
-<td style="text-align:left">DE:3b7184c0ceaf76a9607a31e4e1f87f</td>
+<td align="left">DE/SE/1234567890123456789012345678901</td>
+<td align="left">DE:3b7184c0ceaf76a9607a31e4e1f87f</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="footnote-2-3-1"></a></p>
 <blockquote>
-<p>[1]: Birthday paradox approximation p(<em>n</em>) ≈ <em>n</em>\^2 / 2<em>m</em>, where p(<em>n</em>) is the collision probability, <em>n</em> is the number of people and <em>m</em> is the number of possible ID combinations.</p>
+<p>[1]: Birthday paradox approximation p(<em>n</em>) ≈ <em>n</em>^2 / 2<em>m</em>, where p(<em>n</em>) is the collision probability, <em>n</em> is the number of people and <em>m</em> is the number of possible ID combinations.</p>
 </blockquote>
 <p><a name="algorithm-colresist-eidas"></a></p>
-<h4 id="2.3.2.-algorithm:-colresist-eidas">2.3.2. Algorithm: colresist-eIDAS</h4>
+<h4 id="232-algorithm-colresist-eidas">2.3.2. Algorithm: colresist-eIDAS</h4>
 <p>This algorithm is identical to default-eIDAS except that the hashed
 expression of the ID in case the normalized ID exceeds 30 characters,
 has higher collision resistance by expressing the ID in radix 36 instead
@@ -309,69 +305,67 @@ <h4 id="2.3.2.-algorithm:-colresist-eidas">2.3.2. Algorithm: colresist-eIDAS</h4
 <blockquote>
 <p>Identical to <code>default-eIDAS</code> result</p>
 </blockquote>
-<p>If length of normalizedID &gt; 30 characters<strong>:</strong></p>
+<p>If length of normalizedID &gt; 30 characters**:**</p>
 <blockquote>
 <p>Return the string representation of the first 30 radix 36 digits of the SHA256 hash of the UTF-8 encoded bytes of <code>strippedID</code>.</p>
 </blockquote>
 <p><strong>Exceptions</strong>: Identical to <code>default-eIDAS</code></p>
 <p><strong>Collision resistance:</strong></p>
 <p>Expression of this ID in hashed form use 30 radix 36 symbols. This
-reduces the collision resistance among 2 users to 1 in 4.75 * 10\^46.
+reduces the collision resistance among 2 users to 1 in 4.75 * 10^46.
 The collision probability among 100 million users is reduced to
-approximately 1 in 10\^31.</p>
+approximately 1 in 10^31.</p>
 <p><strong>Examples:</strong></p>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">PersonIdentifier</th>
-<th style="text-align:left">Resulting prid</th>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">NO/SE/05068907693</td>
-<td style="text-align:left">NO:05068907693</td>
+<tbody><tr>
+<td align="left">NO/SE/05068907693</td>
+<td align="left">NO:05068907693</td>
 </tr>
 <tr>
-<td style="text-align:left">DK/SE/09208-2002-2-194967071622</td>
-<td style="text-align:left">DK:09208-2002-2-194967071622</td>
+<td align="left">DK/SE/09208-2002-2-194967071622</td>
+<td align="left">DK:09208-2002-2-194967071622</td>
 </tr>
 <tr>
-<td style="text-align:left">UK/DK/1234567890</td>
-<td style="text-align:left">UK:NULL (Failed: target country is not SE)</td>
+<td align="left">UK/DK/1234567890</td>
+<td align="left">UK:NULL (Failed: target country is not SE)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/#12345-3456//ABC</td>
-<td style="text-align:left">DE:12345-3456-abc</td>
+<td align="left">DE/SE/#12345-3456//ABC</td>
+<td align="left">DE:12345-3456-abc</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/aErf#(EAd9)</td>
-<td style="text-align:left">DE:0aerf-ead9</td>
+<td align="left">DE/SE/aErf#(EAd9)</td>
+<td align="left">DE:0aerf-ead9</td>
 </tr>
 <tr>
-<td style="text-align:left">de/se/aErf#(E)</td>
-<td style="text-align:left">NULL (Failed: Less than 6 ID characters)</td>
+<td align="left">de/se/aErf#(E)</td>
+<td align="left">NULL (Failed: Less than 6 ID characters)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/(1952 12 14-1122)</td>
-<td style="text-align:left">DE:19521214-1122</td>
+<td align="left">DE/SE/(1952 12 14-1122)</td>
+<td align="left">DE:19521214-1122</td>
 </tr>
 <tr>
-<td style="text-align:left">19521214-1122</td>
-<td style="text-align:left">NULL (Failed: Leading 6 character format error)</td>
+<td align="left">19521214-1122</td>
+<td align="left">NULL (Failed: Leading 6 character format error)</td>
 </tr>
 <tr>
-<td style="text-align:left">DE/SE/1234567890123456789012345678901</td>
-<td style="text-align:left">DE:1hc3tpoleczqu3t8jz2995k2rq7nt8</td>
+<td align="left">DE/SE/1234567890123456789012345678901</td>
+<td align="left">DE:1hc3tpoleczqu3t8jz2995k2rq7nt8</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="footnote2-3-2"></a></p>
 <blockquote>
 <p>[1]: Radix 36 express values ranging from 0 to 36 through a single character using the symbols ”0123456789abcdefghijklmnopqrstuvwxyz” in the presented order.</p>
 </blockquote>
 <p><a name="special-characters-eidas"></a></p>
-<h4 id="2.3.3.-algorithm:-special-characters-eidas">2.3.3. Algorithm: special-characters-eIDAS</h4>
+<h4 id="233-algorithm-special-characters-eidas">2.3.3. Algorithm: special-characters-eIDAS</h4>
 <p>The default-eIDAS and the colresist-eIDAS algoritms are suitable when the base identifier from the authenticating country is constructed from digits and basic case-insensitive characters. These algoritms do not work on identifiers constructed as a Base64 string of binary data, such as a hash of another identifier.</p>
 <p>The present algoritm is intended to be used where the base identifier contains case-sensitive characters and where characters other than a-z and 0-9 are used to add entropy to the identifier.</p>
 <p><strong>Name:</strong> <code>special-characters-eIDAS</code></p>
@@ -386,27 +380,25 @@ <h4 id="2.3.3.-algorithm:-special-characters-eidas">2.3.3. Algorithm: special-ch
 <p>If the following conditions occur in the process, prid generation fails:</p>
 </blockquote>
 <ol class="list">
-<li>Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
-<li><code>strippedID</code> &lt; 16 characters.</li>
+<li> Leading 6 characters of PersonIdentifier does not match regexp <code>^[A-Za-z]{2}[\/](SE|se)[\/]$</code></li>
+<li> <code>strippedID</code> &lt; 16 characters.</li>
 </ol>
 <p><strong>Collision resistance:</strong> Identical to <code>colresist-eIDAS</code>.</p>
 <p><strong>Examples:</strong></p>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">PersonIdentifier</th>
-<th style="text-align:left">Resulting prid</th>
+<th align="left">PersonIdentifier</th>
+<th align="left">Resulting prid</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">AT/SE/Zk2ME2pjxwzQOjVeFGeqSIage34=</td>
-<td style="text-align:left">AT:50bwytdle2mzexopcolmdhmhznihms</td>
+<tbody><tr>
+<td align="left">AT/SE/Zk2ME2pjxwzQOjVeFGeqSIage34=</td>
+<td align="left">AT:50bwytdle2mzexopcolmdhmhznihms</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="algorithm-selection-and-resulting-pridpersistence-value"></a></p>
-<h3 id="2.4.-algorithm-selection-and-resulting-pridpersistence-value">2.4. Algorithm Selection and Resulting pridPersistence Value</h3>
+<h3 id="24-algorithm-selection-and-resulting-pridpersistence-value">2.4. Algorithm Selection and Resulting pridPersistence Value</h3>
 <p>This section defines the current algorithm selection rules and the
 resulting pridPersistence value. These rules are processed in the
 presented order. The first rule where the present conditions matches all
@@ -416,91 +408,85 @@ <h3 id="2.4.-algorithm-selection-and-resulting-pridpersistence-value">2.4. Algor
 <table>
 <thead>
 <tr>
-<th style="text-align:left">Rule 1</th>
-<th style="text-align:left">Description</th>
+<th align="left">Rule 1</th>
+<th align="left">Description</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">Matching rule 1</td>
-<td style="text-align:left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
 </tr>
 <tr>
-<td style="text-align:left">Matching rule 2</td>
-<td style="text-align:left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
 </tr>
 <tr>
-<td style="text-align:left">Matching rule 3</td>
-<td style="text-align:left">Attributes provided by any of the countries that issue identities according to persistance class A.</td>
+<td align="left">Matching rule 3</td>
+<td align="left">Attributes provided by any of the countries that issue identities according to persistance class A.</td>
 </tr>
 <tr>
-<td style="text-align:left">Selected algorithm</td>
-<td style="text-align:left"><code>default-eIDAS</code></td>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
 </tr>
 <tr>
-<td style="text-align:left">pridPersistence value</td>
-<td style="text-align:left">A</td>
+<td align="left">pridPersistence value</td>
+<td align="left">A</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">Rule 2</th>
-<th style="text-align:left">Description</th>
+<th align="left">Rule 2</th>
+<th align="left">Description</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">Matching rule 1</td>
-<td style="text-align:left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
 </tr>
 <tr>
-<td style="text-align:left">Matching rule 2</td>
-<td style="text-align:left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
 </tr>
 <tr>
-<td style="text-align:left">Matching rule 3</td>
-<td style="text-align:left">Attributes provided by any of the countries that issue identities according to persistance class B.</td>
+<td align="left">Matching rule 3</td>
+<td align="left">Attributes provided by any of the countries that issue identities according to persistance class B.</td>
 </tr>
 <tr>
-<td style="text-align:left">Selected algorithm</td>
-<td style="text-align:left"><code>default-eIDAS</code></td>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
 </tr>
 <tr>
-<td style="text-align:left">pridPersistence value</td>
-<td style="text-align:left">B</td>
+<td align="left">pridPersistence value</td>
+<td align="left">B</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">Rule 3</th>
-<th style="text-align:left">Description</th>
+<th align="left">Rule 3</th>
+<th align="left">Description</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">Matching rule 1</td>
-<td style="text-align:left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
+<tbody><tr>
+<td align="left">Matching rule 1</td>
+<td align="left">Authenticated attributes are provided by an eIDAS node (proxy service).</td>
 </tr>
 <tr>
-<td style="text-align:left">Matching rule 2</td>
-<td style="text-align:left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
+<td align="left">Matching rule 2</td>
+<td align="left">Authenticated subject is a person and has a <code>PersonIdentifier</code> attribute.</td>
 </tr>
 <tr>
-<td style="text-align:left">Selected algorithm</td>
-<td style="text-align:left"><code>default-eIDAS</code></td>
+<td align="left">Selected algorithm</td>
+<td align="left"><code>default-eIDAS</code></td>
 </tr>
 <tr>
-<td style="text-align:left">pridPersistence value</td>
-<td style="text-align:left">C</td>
+<td align="left">pridPersistence value</td>
+<td align="left">C</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="references"></a></p>
-<h2 id="3.-references">3. References</h2>
+<h2 id="3-references">3. References</h2>
 <p><a name="rfc2119"></a>
 <strong>[RFC2119]</strong></p>
 <blockquote>
@@ -538,7 +524,7 @@ <h2 id="3.-references">3. References</h2>
 <p><a href="https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.2-FINAL.pdf">eIDAS SAML Attribute Profile, version 1.2, 21 May 2019</a>.</p>
 </blockquote>
 <p><a name="changes-between-versions"></a></p>
-<h2 id="4.-changes-between-versions">4. Changes between versions</h2>
+<h2 id="4-changes-between-versions">4. Changes between versions</h2>
 <p><strong>Changes between version 1.1 and version 1.2:</strong></p>
 <ul class="list">
 <li>The length requirement for identifier characters has been changed from 8 to 6. This applies to the default-eIDAS and colresist-eIDAS algorithms.</li>
@@ -553,104 +539,105 @@ <h2 id="4.-changes-between-versions">4. Changes between versions</h2>
 </li>
 </ul>
 <p><a name="prid-algorithm-implementations-java"></a></p>
-<h2 id="appendix-a.-prid-algorithm-implementations-(java)">Appendix A. PRID Algorithm implementations (Java)</h2>
+<h2 id="appendix-a-prid-algorithm-implementations-java">Appendix A. PRID Algorithm implementations (Java)</h2>
 <p><strong>default-eIDAS</strong></p>
-<pre class="hljs"><code>  <span class="hljs-keyword">private</span> <span class="hljs-keyword">static</span> final <span class="hljs-keyword">String</span> personIdentifierPrefixRegexp = <span class="hljs-string">"^[A-Za-z]{2}[\\/](SE|se)[\\/]"</span>;
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> static final String personIdentifierPrefixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
 
-  <span class="hljs-keyword">public</span> <span class="hljs-keyword">String</span> getPridIdentifierComponent(<span class="hljs-keyword">String</span> personIdentifier) throws PridGenerationException {
-
-    <span class="hljs-keyword">if</span> (personIdentifier == <span class="hljs-literal">null</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Missing personIdentifier"</span>);
+  public String get<span class="hljs-constructor">PridIdentifierComponent(String <span class="hljs-params">personIdentifier</span>)</span> throws PridGenerationException {
+    
+    <span class="hljs-keyword">if</span> (personIdentifier<span class="hljs-operator"> == </span>null) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>)</span>;
     }
     <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrefixRegexp)) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
     }
     <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
-    <span class="hljs-keyword">String</span> strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replaceAll(<span class="hljs-string">"\\s+"</span>, <span class="hljs-string">""</span>);
-
+    String strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+        
     <span class="hljs-comment">// Convert to lower case</span>
-    <span class="hljs-keyword">String</span> normalizedID = strippedID.toLowerCase();
-
-    <span class="hljs-comment">// Replace sequences of non ID characters to "-"</span>
-    normalizedID = normalizedID.replaceAll(<span class="hljs-string">"[^a-z0-9]+"</span>, <span class="hljs-string">"-"</span>);
-
-    <span class="hljs-comment">// Remove leading and trailing "-" </span>
-    normalizedID = normalizedID.replaceAll(<span class="hljs-string">"^-+"</span>, <span class="hljs-string">""</span>).replaceAll(<span class="hljs-string">"-+$"</span>, <span class="hljs-string">""</span>);
-    <span class="hljs-keyword">if</span> (normalizedID.replaceAll(<span class="hljs-string">"-"</span>, <span class="hljs-string">""</span>).length() &lt; <span class="hljs-number">6</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+    String normalizedID = strippedID.<span class="hljs-keyword">to</span><span class="hljs-constructor">LowerCase()</span>;
+            
+    <span class="hljs-comment">// Replace sequences of non ID characters to &quot;-&quot;</span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;[^a-z0-9]+&quot;</span>, <span class="hljs-string">&quot;-&quot;</span>)</span>;
+    
+    <span class="hljs-comment">// Remove leading and trailing &quot;-&quot; </span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;^-+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-+$&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    <span class="hljs-keyword">if</span> (normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">6</span>) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
     }
-    <span class="hljs-keyword">if</span> (normalizedID.length() &lt; <span class="hljs-number">10</span>) {
-      normalizedID = <span class="hljs-string">"0000000000"</span>.substring(normalizedID.length()) + normalizedID;
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">10</span>) {
+      normalizedID = <span class="hljs-string">&quot;0000000000&quot;</span>.substring(normalizedID.length<span class="hljs-literal">()</span>) + normalizedID;
     }
-    <span class="hljs-keyword">if</span> (normalizedID.length() &gt; <span class="hljs-number">30</span>) {
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &gt; <span class="hljs-number">30</span>) {
       <span class="hljs-keyword">try</span> {
-        MessageDigest md = MessageDigest.getInstance(<span class="hljs-string">"SHA-256"</span>);
-        byte[] digest = md.digest(strippedID.getBytes(Charset.forName(<span class="hljs-string">"UTF-8"</span>)));
-        <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-type">BigInteger</span>(<span class="hljs-number">1</span>, digest).toString(<span class="hljs-number">16</span>).substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
+        MessageDigest md = <span class="hljs-module-access"><span class="hljs-module"><span class="hljs-identifier">MessageDigest</span>.</span></span>get<span class="hljs-constructor">Instance(<span class="hljs-string">&quot;SHA-256&quot;</span>)</span>;
+        byte<span class="hljs-literal">[]</span> digest = md.digest(strippedID.get<span class="hljs-constructor">Bytes(Charset.<span class="hljs-params">forName</span>(<span class="hljs-string">&quot;UTF-8&quot;</span>)</span>));
+        return <span class="hljs-keyword">new</span> <span class="hljs-constructor">BigInteger(1, <span class="hljs-params">digest</span>)</span>.<span class="hljs-keyword">to</span><span class="hljs-constructor">String(16)</span>.substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
       }
-      <span class="hljs-keyword">catch</span> (NoSuchAlgorithmException ex) {
-        <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(e);
+      catch (NoSuchAlgorithmException ex) {
+        throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-params">e</span>)</span>;
       }
     }
-    <span class="hljs-keyword">return</span> normalizedID;
-  }</code></pre><p><strong>colresist-eIDAS</strong></p>
-<pre class="hljs"><code>  <span class="hljs-keyword">private</span> <span class="hljs-keyword">static</span> final <span class="hljs-keyword">String</span> personIdentifierPrefixRegexp = <span class="hljs-string">"^[A-Za-z]{2}[\\/](SE|se)[\\/]"</span>;
-
-  <span class="hljs-keyword">public</span> <span class="hljs-keyword">static</span> <span class="hljs-keyword">String</span> getPridIdentifierComponent(<span class="hljs-keyword">String</span> personIdentifier) throws PridGenerationException {
-    <span class="hljs-keyword">if</span> (personIdentifier == <span class="hljs-literal">null</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Missing personIdentifier"</span>);
+    return normalizedID;
+  }
+</code></pre><p><strong>colresist-eIDAS</strong></p>
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> static final String personIdentifierPrefixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
+  
+  public static String get<span class="hljs-constructor">PridIdentifierComponent(String <span class="hljs-params">personIdentifier</span>)</span> throws PridGenerationException {
+    <span class="hljs-keyword">if</span> (personIdentifier<span class="hljs-operator"> == </span>null) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>)</span>;
     }
     <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrefixRegexp)) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
     }
-
+    
     <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
-    <span class="hljs-keyword">String</span> strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replaceAll(<span class="hljs-string">"\\s+"</span>, <span class="hljs-string">""</span>);
-
+    String strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    
     <span class="hljs-comment">// Convert to lower case</span>
-    <span class="hljs-keyword">String</span> normalizedID = strippedID.toLowerCase();
-
-    <span class="hljs-comment">// Replace sequences of non ID characters to "-"</span>
-    normalizedID = normalizedID.replaceAll(<span class="hljs-string">"[^a-z0-9]+"</span>, <span class="hljs-string">"-"</span>);
-
-    <span class="hljs-comment">// Remove leading and trailing "-" </span>
-    normalizedID = normalizedID.replaceAll(<span class="hljs-string">"^-+"</span>, <span class="hljs-string">""</span>).replaceAll(<span class="hljs-string">"-+$"</span>, <span class="hljs-string">""</span>);
-    <span class="hljs-keyword">if</span> (normalizedID.replaceAll(<span class="hljs-string">"-"</span>, <span class="hljs-string">""</span>).length() &lt; <span class="hljs-number">6</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+    String normalizedID = strippedID.<span class="hljs-keyword">to</span><span class="hljs-constructor">LowerCase()</span>;
+    
+    <span class="hljs-comment">// Replace sequences of non ID characters to &quot;-&quot;</span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;[^a-z0-9]+&quot;</span>, <span class="hljs-string">&quot;-&quot;</span>)</span>;
+    
+    <span class="hljs-comment">// Remove leading and trailing &quot;-&quot; </span>
+    normalizedID = normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;^-+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-+$&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>;
+    <span class="hljs-keyword">if</span> (normalizedID.replace<span class="hljs-constructor">All(<span class="hljs-string">&quot;-&quot;</span>, <span class="hljs-string">&quot;&quot;</span>)</span>.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">6</span>) {
+      throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-string">&quot;Invalid ID format&quot;</span>)</span>;
     }
-    <span class="hljs-keyword">if</span> (normalizedID.length() &lt; <span class="hljs-number">10</span>) {
-      normalizedID = <span class="hljs-string">"0000000000"</span>.substring(normalizedID.length()) + normalizedID;
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &lt; <span class="hljs-number">10</span>) {
+      normalizedID = <span class="hljs-string">&quot;0000000000&quot;</span>.substring(normalizedID.length<span class="hljs-literal">()</span>) + normalizedID;
     }
-    <span class="hljs-keyword">if</span> (normalizedID.length() &gt; <span class="hljs-number">30</span>) {
+    <span class="hljs-keyword">if</span> (normalizedID.length<span class="hljs-literal">()</span> &gt; <span class="hljs-number">30</span>) {
       <span class="hljs-keyword">try</span> {
-        MessageDigest md = MessageDigest.getInstance(<span class="hljs-string">"SHA-256"</span>);
-        byte[] digest = md.digest(strippedID.getBytes(Charset.forName(<span class="hljs-string">"UTF-8"</span>)));
-        <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-type">BigInteger</span>(<span class="hljs-number">1</span>, digest).toString(<span class="hljs-number">36</span>).substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
+        MessageDigest md = <span class="hljs-module-access"><span class="hljs-module"><span class="hljs-identifier">MessageDigest</span>.</span></span>get<span class="hljs-constructor">Instance(<span class="hljs-string">&quot;SHA-256&quot;</span>)</span>;
+        byte<span class="hljs-literal">[]</span> digest = md.digest(strippedID.get<span class="hljs-constructor">Bytes(Charset.<span class="hljs-params">forName</span>(<span class="hljs-string">&quot;UTF-8&quot;</span>)</span>));
+        return <span class="hljs-keyword">new</span> <span class="hljs-constructor">BigInteger(1, <span class="hljs-params">digest</span>)</span>.<span class="hljs-keyword">to</span><span class="hljs-constructor">String(36)</span>.substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
       } 
-      <span class="hljs-keyword">catch</span> (NoSuchAlgorithmException ex) {
-        <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(e);
+      catch (NoSuchAlgorithmException ex) {
+        throw <span class="hljs-keyword">new</span> <span class="hljs-constructor">PridGenerationException(<span class="hljs-params">e</span>)</span>;
       }
     }
-    <span class="hljs-keyword">return</span> normalizedID;
+    return normalizedID;
   }</code></pre><p><strong>special-characters-eIDAS</strong></p>
-<pre class="hljs"><code>  <span class="hljs-keyword">private</span> <span class="hljs-keyword">static</span> final <span class="hljs-keyword">String</span> personIdentifierPrifixRegexp = <span class="hljs-string">"^[A-Za-z]{2}[\\/](SE|se)[\\/]"</span>;
+<pre class="hljs"><code>  <span class="hljs-keyword">private</span> <span class="hljs-keyword">static</span> final <span class="hljs-keyword">String</span> personIdentifierPrifixRegexp = <span class="hljs-string">&quot;^[A-Za-z]{2}[\\/](SE|se)[\\/]&quot;</span>;
 
   <span class="hljs-keyword">public</span> <span class="hljs-keyword">String</span> getPridIdentifierComponent(<span class="hljs-keyword">String</span> personIdentifier) throws PridGenerationException {
     <span class="hljs-keyword">if</span> (personIdentifier == <span class="hljs-literal">null</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Missing personIdentifier"</span>);
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Missing personIdentifier&quot;</span>);
     }
     <span class="hljs-keyword">if</span> (!personIdentifier.substring(<span class="hljs-number">0</span>, <span class="hljs-number">6</span>).matches(personIdentifierPrifixRegexp)) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Invalid ID format&quot;</span>);
     }
-
+    
     <span class="hljs-comment">// Get ID component without whitespace and non-printable characters</span>
-    <span class="hljs-keyword">String</span> strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replaceAll(<span class="hljs-string">"\\s+"</span>, <span class="hljs-string">""</span>);
+    <span class="hljs-keyword">String</span> strippedID = personIdentifier.substring(<span class="hljs-number">6</span>).replaceAll(<span class="hljs-string">&quot;\\s+&quot;</span>, <span class="hljs-string">&quot;&quot;</span>);
     <span class="hljs-keyword">if</span> (strippedID.length() &lt; <span class="hljs-number">16</span>) {
-      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">"Invalid ID format"</span>);
+      <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> <span class="hljs-type">PridGenerationException</span>(<span class="hljs-string">&quot;Invalid ID format&quot;</span>);
     }
     <span class="hljs-keyword">try</span> {
-      MessageDigest md = MessageDigest.getInstance(<span class="hljs-string">"SHA-256"</span>);
-      byte[] digest = md.digest(strippedID.getBytes(Charset.forName(<span class="hljs-string">"UTF-8"</span>)));
+      MessageDigest md = MessageDigest.getInstance(<span class="hljs-string">&quot;SHA-256&quot;</span>);
+      byte[] digest = md.digest(strippedID.getBytes(Charset.forName(<span class="hljs-string">&quot;UTF-8&quot;</span>)));
       <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-type">BigInteger</span>(<span class="hljs-number">1</span>, digest).toString(<span class="hljs-number">36</span>).substring(<span class="hljs-number">0</span>, <span class="hljs-number">30</span>);
     }
     <span class="hljs-keyword">catch</span> (NoSuchAlgorithmException ex) {
diff --git a/docs/november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html b/docs/november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
index bdc3df8..6ea242c 100644
--- a/docs/november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
+++ b/docs/november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
@@ -19,11 +19,11 @@
 </p>
 
 <h1 id="implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h1>
-<h3 id="version-1.3---2021-11-11">Version 1.3 - 2021-11-11</h3>
+<h3 id="version-14---2024-12-04">Version 1.4 - 2024-12-04</h3>
 <p>Registration number: <strong>2019-316</strong></p>
 <hr>
 <p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2021. All Rights Reserved.
+Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
 </p>
 
 <h2 id="table-of-contents">Table of Contents</h2>
@@ -43,17 +43,15 @@ <h2 id="table-of-contents">Table of Contents</h2>
 <li><p><a href="#identity-provider-user-interface"><strong>Identity Provider User Interface</strong></a></p>
 <p> 3.1. <a href="#general-requirements">General Requirements</a></p>
 <p> 3.2. <a href="#automatic-start-of-bankid-client">Automatic Start of the BankID Client</a></p>
-<p> 3.3. <a href="#mobile-bankid-on-another-device">Mobile BankID on another Device</a></p>
-<p> 3.3.1. <a href="#user-experience-recommendations">User Experience Recommendations</a></p>
-<p> 3.4. <a href="#cancelling-an-operation">Cancelling an Operation</a></p>
+<p> 3.3. <a href="#cancelling-an-operation">Cancelling an Operation</a></p>
 </li>
 <li><p><a href="#authentication-requests"><strong>Authentication Requests</strong></a></p>
 <p> 4.1. <a href="#binding-and-security-requirements">Binding and Security Requirements</a></p>
-<p> 4.2. <a href="#authentication-for-signature">Authentication for Signature</a></p>
-<p> 4.2.1. <a href="#input-to-bankid-signing">Input to BankID Signing</a></p>
-<p> 4.2.1.1. <a href="#uservisibledata">userVisibleData - Signature Message</a></p>
-<p> 4.2.1.2. <a href="#usernonvisibledata">userNonVisibleData</a></p>
-<p> 4.2.2. <a href="#mobile-bankid-and-the-personnumber-attribute">Mobile BankID and the personNumber attribute</a></p>
+<p> 4.2. <a href="#handling-of-principal-selection">Handling of Principal Selection</a></p>
+<p> 4.3. <a href="#authentication-for-signature">Authentication for Signature</a></p>
+<p> 4.3.1. <a href="#input-to-bankid-signing">Input to BankID Signing</a></p>
+<p> 4.3.1.1. <a href="#uservisibledata">userVisibleData - Signature Message</a></p>
+<p> 4.3.1.2. <a href="#usernonvisibledata">userNonVisibleData</a></p>
 </li>
 <li><p><a href="#authentication-responses"><strong>Authentication Responses</strong></a></p>
 <p> 5.1. <a href="#attribute-release-rules">Attribute Release Rules</a></p>
@@ -71,14 +69,12 @@ <h2 id="table-of-contents">Table of Contents</h2>
 </ol>
 <hr>
 <p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>This profile defines how a SAML Identity Provider that offers authentication using the Swedish BankID technology should implement its services to be compliant with the Swedish eID Framework. It extends the &quot;Deployment Profile for the Swedish eID Framework&quot;, 
-[<a href="#eid-profile">EidProfile</a>], with requirements and recommendations for Identity Providers offering BankID authentication and signature services.</p>
-<p>The BankID interface for authentication and signature, the Relying Party Interface, is described in the &quot;BankID Relying Party Guidelines&quot;, [<a href="#bankid_spec">BankID_Spec</a>], specification. This specification MUST be fully implemented and supported by BankID Identity Providers compliant
-with the Swedish eID Framework specifications.</p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>This profile defines how a SAML Identity Provider that offers authentication using the Swedish BankID technology should implement its services to be compliant with the Swedish eID Framework. It extends the &quot;Deployment Profile for the Swedish eID Framework&quot;,  [<a href="#sc-saml-profile">SC.SAML.Profile</a>], with requirements and recommendations for Identity Providers offering BankID authentication and signature services.</p>
+<p>The BankID interface for authentication and signature, the Relying Party Interface, is described at <a href="https://developers.bankid.com">https://developers.bankid.com</a>. This specification MUST be fully implemented and supported by BankID Identity Providers compliant with the Swedish eID Framework specifications.</p>
 <p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
+<p>The keywords &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
 &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
 document are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
 <p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
@@ -89,27 +85,27 @@ <h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
 interoperate without additional negotiation, and should be undertaken
 with caution.</p>
 <p><a name="references-to-saml-20-standards-and-profiles"></a></p>
-<h3 id="1.2.-references-to-saml-2.0-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
+<h3 id="12-references-to-saml-20-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
 <p>When referring to elements from the SAML 2.0 core specification [<a href="#saml2core">SAML2Core</a>],
 the following syntax is used:</p>
 <ul class="list">
 <li><p><code>&lt;saml2p:Element&gt;</code> – for elements from the SAML 2.0 Protocol
-namespace.</p>
+  namespace.</p>
 </li>
 <li><p><code>&lt;saml2:Element&gt;</code> – for elements from the SAML 2.0 Assertion
-namespace.</p>
+  namespace.</p>
 </li>
 </ul>
 <p>When referring to elements from the SAML 2.0 metadata specifications,
 the following syntax is used:</p>
 <ul class="list">
-<li><p><code>&lt;md:Element&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
+<li><p>  <code>&lt;md:Element&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
 </li>
-<li><p><code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
+<li><p>  <code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
 </li>
 </ul>
 <p><a name="bankid-methods-and-applications"></a></p>
-<h3 id="1.3.-bankid-methods-and-applications">1.3. BankID Methods and Applications</h3>
+<h3 id="13-bankid-methods-and-applications">1.3. BankID Methods and Applications</h3>
 <p>There are three types of BankID:</p>
 <ul class="list">
 <li>Mobile BankID - End users use the &quot;BankID app&quot; on their mobile devices to authenticate or perform a signature. In these cases the user certificate is stored in the app and protected by a personal code.</li>
@@ -118,37 +114,35 @@ <h3 id="1.3.-bankid-methods-and-applications">1.3. BankID Methods and Applicatio
 </ul>
 <p>The three above methods are all &quot;BankID&quot;, but historically, relying parties have made a difference between &quot;Mobile BankID&quot; and &quot;BankID&quot; (the original desktop version).</p>
 <p><a name="representation-as-identity-providers"></a></p>
-<h4 id="1.3.1.-representation-as-identity-providers">1.3.1. Representation as Identity Providers</h4>
+<h4 id="131-representation-as-identity-providers">1.3.1. Representation as Identity Providers</h4>
 <p>An actor offering BankID services can choose to use <strong>one</strong> BankID Identity Provider supporting all different BankID methods, or use <strong>several</strong> Identity Provider instances, one for each BankID method. </p>
 <p>Services that support all methods within one Identity Provider instance usually displays a question to the user before authentication starts, where the user chooses between &quot;Using BankID on this device or another device&quot;. In an environment where a discovery service (or similar) is being used, this means that the user has to make two choices before the actual authentication process starts; first at the discovery service where the user selects &quot;BankID&quot; and then at the BankID Identity Provider where the user selects the type of BankID authentication to use.</p>
 <p>It is RECOMMENDED that BankID services are split into separate Identity Providers for each supported BankID method. The reasons for this are the above argument about discovery, but also the fact that a Service Provider should be able to select which type of authentication that is required (for example, Mobile BankID may be accepted but not BankID on file). </p>
 <p><a name="recommended-limitations"></a></p>
-<h4 id="1.3.2.-recommended-limitations">1.3.2. Recommended Limitations</h4>
+<h4 id="132-recommended-limitations">1.3.2. Recommended Limitations</h4>
 <p>The table below states the RECOMMENDED support and behaviour when support for BankID is implemented using separate Identity Providers (as recommended in section <a href="#representation-as-identity-providers">1.3.1</a> above). </p>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">Identity Provider</th>
-<th style="text-align:left">Desktop</th>
-<th style="text-align:left">Mobile Phone</th>
-<th style="text-align:left">Tablet</th>
+<th align="left">Identity Provider</th>
+<th align="left">Desktop</th>
+<th align="left">Mobile Phone</th>
+<th align="left">Tablet</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left">Mobile BankID</td>
-<td style="text-align:left">Start BankID on other device<sup>1</sup> (mobile phone or tablet).</td>
-<td style="text-align:left">Start BankID on the same device<sup>2</sup>.</td>
-<td style="text-align:left">Prompt the user to ask whether to start BankID on the tablet or on another device<sup>3</sup> (mobile phone).</td>
+<tbody><tr>
+<td align="left">Mobile BankID</td>
+<td align="left">Start BankID on other device<sup>1</sup> (mobile phone or tablet).</td>
+<td align="left">Start BankID on the same device<sup>2</sup>.</td>
+<td align="left">Prompt the user to ask whether to start BankID on the tablet or on another device<sup>3</sup> (mobile phone).</td>
 </tr>
 <tr>
-<td style="text-align:left">BankID on file (<em>or on card</em>)</td>
-<td style="text-align:left">Start BankID on the same device<sup>4</sup>.</td>
-<td style="text-align:left">Not supported<sup>5</sup>.</td>
-<td style="text-align:left">Not supported<sup>5</sup>.</td>
+<td align="left">BankID on file (<em>or on card</em>)</td>
+<td align="left">Start BankID on the same device<sup>4</sup>.</td>
+<td align="left">Not supported<sup>5</sup>.</td>
+<td align="left">Not supported<sup>5</sup>.</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <ol class="list">
 <li>The user initiates a BankID operation from his or hers desktop computer and selects to use Mobile BankID. In this case the Mobile BankID app is started on another device (since Mobile BankID does not exist on desktop computers).</li>
 <li>The user initiates a BankID operation from his or hers mobile phone and selects to use Mobile BankID. In this case the BankID app is started on the same device. It is highly unlikely that a user uses one mobile phone to visit a service and wants to use his or hers BankID on another device.</li>
@@ -159,8 +153,8 @@ <h4 id="1.3.2.-recommended-limitations">1.3.2. Recommended Limitations</h4>
 <p>Note: Items 4 and 5 above also apply to BankID on card. A service MAY choose to implement BankID on file and BankID on card as separate Identity Providers or as one Identity Provider instance.</p>
 <p>For Identity Providers implementing BankID support in <strong>one</strong> Identity Provider instance it is RECOMMENDED to make the assumption that the BankID app should be started on the same device if the user connects via a mobile phone. </p>
 <p><a name="relying-party-configuration"></a></p>
-<h3 id="1.4.-relying-party-configuration">1.4. Relying Party Configuration</h3>
-<p>When a Relying Party uses the BankID Relying Party API directly in order to implement BankID services, it has a set of configuration settings to choose from (see section 14.5 of [<a href="#bankid_spec">BankID_Spec</a>]). Examples are:</p>
+<h3 id="14-relying-party-configuration">1.4. Relying Party Configuration</h3>
+<p>When a Relying Party uses the BankID Relying Party API directly in order to implement BankID services, it has a set of configuration settings to choose from (see <code>requirements</code> object under the <a href="https://developers.bankid.com/api-references/auth--sign/auth">Auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">Sign API</a>). Examples are:</p>
 <ul class="list">
 <li><p>Should fingerprints be allowed instead of the user entering his or hers security code?</p>
 </li>
@@ -169,187 +163,121 @@ <h3 id="1.4.-relying-party-configuration">1.4. Relying Party Configuration</h3>
 <li><p>Smart card reader preferences.</p>
 </li>
 </ul>
-<p>However, the services of a BankID Identity Provider are used by several parties within the federation and it is thus harder to maintain a per Service Provider configuration. Therefore, a BankID Identity Provider compliant with this profile SHOULD use the same configuration defaults as stated in section 14.5 of [<a href="#bankid_spec">BankID_Spec</a>]).</p>
+<p>However, the services of a BankID Identity Provider are used by several parties within the federation, and it is thus harder to maintain a per-Service Provider configuration. Therefore, a BankID Identity Provider compliant with this profile SHOULD use the same configuration defaults as stated in <a href="https://developers.bankid.com/api-references/auth--sign/auth">Auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">Sign API</a>.</p>
 <blockquote>
-<p><strong>Note:</strong> It is of course allowed for a BankID Identity Provider to maintain specific Service Provider configurations, but this is outside of the scope for this profile, and there will be no specification support to accomplish this.</p>
-</blockquote>
-<p>Besides the above Relying Party configurations, the BankID API offers two different ways to initiate a BankID operation for the cases where the user agent and the BankID app is not on the same device.</p>
-<ul class="list">
-<li><p>A QR code is displayed in the UI and the user is prompted to scan this code using his or hers mobile device (see section 4 of [<a href="#bankid_spec">BankID_Spec</a>]).</p>
-</li>
-<li><p>The user is prompted for his or hers personal number.</p>
-</li>
-</ul>
-<p>The QR code functionality is a relatively new feature that was introduced to provide protection from fraudsters that remotely attempts to persuade people to authenticate or sign using their mobile BankID:s. By prompting the user to scan a QR code the user agent and mobile device are tied to the same physical location, and these kinds of frauds are eliminated.</p>
-<p>Due to large number of BankID users and the fear of changing a well established pattern, many BankID Relying Parties have not yet implemented the use of QR codes. It is a consideration of ease of use versus higher security, and different service providers may have different opinion regarding the feature.</p>
-<p>A Service Provider making use of a BankID Identity Provider has the possibility to explicitly
-request that QR codes, instead of user ID prompting, is used by the Identity Provider to
-initiate BankID operations. This is performed by declaring the 
-<code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category
-(see section 6.1 of [<a href="#eidentcat">EidEntCat</a>]) in the Service Provider metadata.</p>
-<p>A BankID Identity Provider compliant with this profile SHOULD support the use of QR codes to
-initialize BankID operations. </p>
-<p>BankID Identity Providers that support the QR code feature MUST declare the 
-<code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity
-category in its metadata and MUST check the presence of this entity category from a 
-requesting Service Provider&#39;s metadata when processing a request, and MUST prompt the 
-user to scan a QR code instead of asking for the personal identity number if the entity 
-category is present.</p>
-<blockquote>
-<p>See <a href="#metadata">section 6</a>, &quot;<a href="#metadata">Metadata</a>&quot;, for details how to declare the secure-authenticator-binding entity category.</p>
+<p><strong>Note:</strong> It is of course allowed for a BankID Identity Provider to maintain specific Service Provider configurations, but this is outside the scope for this profile, and there will be no specification support to accomplish this.</p>
 </blockquote>
 <p><a name="attributes"></a></p>
-<h2 id="2.-attributes">2. Attributes</h2>
-<p>An BankID Identity Provider use the BankID Relying Party API, as described in [<a href="#bankid_spec">BankID_Spec</a>], to communicate with the BankID-server when providing its services to end users. When a BankID-operation has completed successfully, the Identity Provider (the BankID Relying Party) invokes the Collect-method (<code>/rp/v5/collect</code>) to obtain the result from the operation.</p>
-<p>The table <a href="#attribute-transformation">below</a> contains attribute transformation mappings between attributes from a Collect-method response as described in section 14.2.5 of [<a href="#bankid_spec">BankID_Spec</a>] and attributes defined within the Swedish eID Framework as defined in [<a href="#eid-attributes">EidAttributes</a>].</p>
+<h2 id="2-attributes">2. Attributes</h2>
+<p>An BankID Identity Provider use the BankID Relying Party API, as described in <a href="https://developers.bankid.com/api-references/auth--sign/overview">BankID API</a>, to communicate with the BankID-server when providing its services to end users. When a BankID-operation has completed successfully, the Identity Provider (the BankID Relying Party) invokes the Collect-method (<code>/collect</code>) to obtain the result from the operation.</p>
+<p>The table <a href="#attribute-transformation">below</a> contains attribute transformation mappings between attributes from a Collect-method response as described in <a href="https://developers.bankid.com/api-references/auth--sign/collect">/collect</a> and attributes defined within the Sweden Connect Framework as defined in [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>].</p>
 <p>An Identity Provider should not necessarily release all transformed attributes received from the BankID-server to the Service Provider. See further section <a href="#attribute-release-rules">5.1</a>, &quot;<a href="#attribute-release-rules">Attribute Release Rules</a>&quot;.</p>
 <p><a name="attribute-transformation"></a></p>
-<h3 id="2.1.-attribute-transformation">2.1. Attribute Transformation</h3>
+<h3 id="21-attribute-transformation">2.1. Attribute Transformation</h3>
 <table>
 <thead>
 <tr>
-<th style="text-align:left">BankID attribute</th>
-<th style="text-align:left">SAML Attribute</th>
-<th style="text-align:left">Description</th>
+<th align="left">BankID attribute</th>
+<th align="left">SAML Attribute</th>
+<th align="left">Description</th>
 </tr>
 </thead>
-<tbody>
-<tr>
-<td style="text-align:left"><code>orderRef</code></td>
-<td style="text-align:left">transactionIdentifier<br /><code>urn:oid:1.2.752.201.3.2</code></td>
-<td style="text-align:left">The BankID order reference received from a BankID Auth (<code>/rp/v5/auth</code>) or Sign (<code>rp/v5/sign</code>) method invocation. This parameter is supplied as an input parameter to the Collect-call and is the unique transaction identifier for the BankID-operation.</td>
+<tbody><tr>
+<td align="left"><code>orderRef</code></td>
+<td align="left">transactionIdentifier<br /><code>urn:oid:1.2.752.201.3.2</code></td>
+<td align="left">The BankID order reference received from a BankID Auth (<code>/rp/v5/auth</code>) or Sign (<code>rp/v5/sign</code>) method invocation. This parameter is supplied as an input parameter to the Collect-call and is the unique transaction identifier for the BankID-operation.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>user.personalNumber</code></td>
-<td style="text-align:left">personalIdentityNumber<br /><code>urn:oid:1.2.752.29.4.13</code></td>
-<td style="text-align:left">Swedish ”personnummer”. 12 digits without hyphen.</td>
+<td align="left"><code>completionData.</code><br /><code>user.personalNumber</code></td>
+<td align="left">personalIdentityNumber<br /><code>urn:oid:1.2.752.29.4.13</code></td>
+<td align="left">Swedish ”personnummer”. 12 digits without hyphen.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>user.givenName</code></td>
-<td style="text-align:left">givenName<br /><code>urn:oid:2.5.4.42</code></td>
-<td style="text-align:left">User&#39;s given name.</td>
+<td align="left"><code>completionData.</code><br /><code>user.givenName</code></td>
+<td align="left">givenName<br /><code>urn:oid:2.5.4.42</code></td>
+<td align="left">User&#39;s given name.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>user.surname</code></td>
-<td style="text-align:left">sn<br /><code>urn:oid:2.5.4.4</code></td>
-<td style="text-align:left">User&#39;s surname.</td>
+<td align="left"><code>completionData.</code><br /><code>user.surname</code></td>
+<td align="left">sn<br /><code>urn:oid:2.5.4.4</code></td>
+<td align="left">User&#39;s surname.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>user.name</code></td>
-<td style="text-align:left">displayName<br /><code>urn:oid:2.16.840.1.113730.3.1.241</code></td>
-<td style="text-align:left">User&#39;s given name and surname.</td>
+<td align="left"><code>completionData.</code><br /><code>user.name</code></td>
+<td align="left">displayName<br /><code>urn:oid:2.16.840.1.113730.3.1.241</code></td>
+<td align="left">User&#39;s given name and surname.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>cert.notBefore</code></td>
-<td style="text-align:left"><em>bankidNotBefore</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
-<td style="text-align:left">Start of validity of user&#39;s BankID.<br />No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidNotBefore</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+<td align="left"><code>completionData.</code><br /><code>device.ipAddress</code></td>
+<td align="left"><em>bankidUserAgentAddress</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">The IP-address of the user agent presented to the BankID server. In cases where a user uses BankID &quot;on another device&quot; this address may not be the same as the web user agent. No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidUserAgentAddress</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>cert.notAfter</code></td>
-<td style="text-align:left"><em>bankidNotAfter</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
-<td style="text-align:left">End of validity of user&#39;s BankID.<br />No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidNotAfter</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+<td align="left"><code>completionData.</code><br /><code>device.uhi</code></td>
+<td align="left"><em>bankidUhi</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">Unique hardware identifier for the user&#39;s device. No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidUhi</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>device.ipAddress</code></td>
-<td style="text-align:left"><em>bankidUserAgentAddress</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
-<td style="text-align:left">The IP-address of the user agent presented to the BankID server. In cases where a user uses BankID &quot;on another device&quot; this address may not be the same as the web user agent. No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidUserAgentAddress</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
+<td align="left"><code>completionData.</code><br /><code>bankIdIssueDate</code></td>
+<td align="left"><em>bankidIssueDate</em> key in authContextParams<br /><code>urn:oid:1.2.752.201.3.3</code></td>
+<td align="left">The date the BankID was issued to the user.<br />No direct attribute mapping exists, but may be represented as key-value pair in authContextParams, where the key is <em>bankidIssueDate</em>, see <a href="#the-authcontextparams-attribute">2.1.1</a> below.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>signature</code></td>
-<td style="text-align:left">userSignature<br /><code>urn:oid:1.2.752.201.3.11</code></td>
-<td style="text-align:left">The signature applied by the user as part of the authentication/signature process.</td>
+<td align="left"><code>completionData.</code><br /><code>signature</code></td>
+<td align="left">userSignature<br /><code>urn:oid:1.2.752.201.3.11</code></td>
+<td align="left">The signature applied by the user as part of the authentication/signature process.</td>
 </tr>
 <tr>
-<td style="text-align:left"><code>completionData.</code><br /><code>ocspResponse</code></td>
-<td style="text-align:left">authServerSignature<br /><code>urn:oid:1.2.752.201.3.13</code></td>
-<td style="text-align:left">The OCSP response signed by the BankID issuer that proves that the user BankID was checked for revocation.</td>
+<td align="left"><code>completionData.</code><br /><code>ocspResponse</code></td>
+<td align="left">authServerSignature<br /><code>urn:oid:1.2.752.201.3.13</code></td>
+<td align="left">The OCSP response signed by the BankID issuer that proves that the user BankID was checked for revocation.</td>
 </tr>
-</tbody>
-</table>
+</tbody></table>
 <p><a name="the-authcontextparams-attribute"></a></p>
-<h4 id="2.1.1.-the-authcontextparams-attribute">2.1.1. The authContextParams Attribute</h4>
-<p>The <code>authContextParams</code> attribute, see section 3.2.1 of [<a href="#eid-attributes">EidAttributes</a>], is a general purpose attribute to be used when non-standardized authentication data is to be transfered in a SAML assertion. </p>
-<p>The attribute is used by attribute providers to release data from an authentication process that has no attribute definition of its own. Thus, should the BankID attributes <code>completionData.cert.notBefore</code>, <code>completionData.cert.notAfter</code> and <code>completionData.device.ipAddress</code> be transformed and included into an assertion, they would have to be placed as key-value pairs of the <code>authContextParams</code> attribute as the example below.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">xmlns:xsi</span>=<span class="hljs-string">"http://www.w3.org/2001/XMLSchema-instance"</span>    
-                           <span class="hljs-attr">FriendlyName</span>=<span class="hljs-string">"authContextParams"</span>
-                           <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.3"</span>
-                           <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xs:string"</span>&gt;</span>
-    bankidNotBefore=2016-05-30T09%3A30%3A10Z;bankidNotAfter=2018-05-30T09%3A30%3A10Z;bankidUserAgentAddress=85.229.202.232
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span></code></pre><p>The example above represents the following BankID attributes and values:</p>
-<ul class="list">
-<li><code>completionData.cert.notBefore</code> = 2016-05-30T09-30-10Z</li>
-<li><code>completionData.cert.notAfter</code> = 2018-05-30T09-30-10Z</li>
-<li><code>completionData.device.ipAddress</code> = 85.229.202.232</li>
-</ul>
-<blockquote>
-<p>The format for the notBefore and notAfter attributes should be the representation as given by the XML type <code>xs:dateTime</code>.</p>
-</blockquote>
-<p><a name="identity-provider-user-interface"></a></p>
-<h2 id="3.-identity-provider-user-interface">3. Identity Provider User Interface</h2>
-<p>This profile does not state any requirements on how the user interface for an Identity Provider implementing BankID services should be implemented other than the statements listed in the sub sections below.</p>
+<h4 id="211-the-authcontextparams-attribute">2.1.1. The authContextParams Attribute</h4>
+<p>The <code>authContextParams</code> attribute, see section 3.2.1 of [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>], is a general purpose attribute to be used when non-standardized authentication data is to be transfered in a SAML assertion. </p>
+<p>The attribute is used by attribute providers to release data from an authentication process that has no attribute definition of its own. Thus, should the BankID attributes <code>completionData.bankIdIssueDate</code>, <code>completionData.device.ipAddress</code> and <code>completionData.device.uhi</code> be transformed and included into an assertion, they would have to be placed as key-value pairs of the <code>authContextParams</code> attribute as the example below.</p>
+<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute xmlns:xsi=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>    
+                           FriendlyName=<span class="hljs-string">&quot;authContextParams&quot;</span>
+                           Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.3&quot;</span>
+                           NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
+  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
+    <span class="hljs-attribute">bankidIssueDate</span>=<span class="hljs-number">2024</span>-<span class="hljs-number">05</span>-<span class="hljs-number">30</span>T<span class="hljs-number">09</span>%<span class="hljs-number">3</span>A<span class="hljs-number">30</span>%<span class="hljs-number">3</span>A<span class="hljs-number">10</span>Z;bankidUserAgentAddress=<span class="hljs-number">85.229.202.232</span>;bankidUhi=RTREUI<span class="hljs-number">8</span>
+  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
+<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p><a name="identity-provider-user-interface"></a></p>
+<h2 id="3-identity-provider-user-interface">3. Identity Provider User Interface</h2>
+<p>This profile does not state any requirements on how the user interface for an Identity Provider implementing BankID services should be implemented other than the statements listed in the subsections below.</p>
 <p><a name="general-requirements"></a></p>
-<h3 id="3.1.-general-requirements">3.1. General Requirements</h3>
-<p>The user interface for a BankID Identity Provider SHOULD use the recommended user and error messages as defined in sections 6, &quot;Recommended User Messages&quot;, and 11, &quot;Recommended Terminology&quot;, of [<a href="#bankid_spec">BankID_Spec</a>].</p>
+<h3 id="31-general-requirements">3.1. General Requirements</h3>
+<p>The user interface for a BankID Identity Provider SHOULD use the recommended user and error messages as defined in sections 5, &quot;Recommended User Messages&quot;, and BankID&#39;s <a href="https://developers.bankid.com/resources/user-messages">Recommended user messages</a> resource.</p>
 <p>The user interface for a BankID Identity Provider MUST display information about the Service Provider that sent the request. It is RECOMMENDED that this information is obtained from the <code>&lt;mdui:UIInfo&gt;</code> element from the Service Provider&#39;s metadata entry.</p>
 <p>It MUST be clear to the user whether an authentication or a signature process is ongoing. </p>
-<p>When an error occurs during an authentication or signature operation, the Identity Provider MUST display an error message that can be easily understood by the end user, and offer the possibility to acknowledge the error so that an error response may be posted back to the requesting Service Provider (as specified in section 6.4, &quot;Error Responses&quot;, of [<a href="#eid-profile">EidProfile</a>]).</p>
+<p>It is RECOMMENDED that an Identity Provider compliant with this profile supports the User Message authentication request extension, as defined in [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>]. </p>
+<p>If the Identity Provider supports this extension, the <code>userVisibleData</code> field of the BankID <a href="https://developers.bankid.com/api-references/auth--sign/auth">/auth</a> and <a href="https://developers.bankid.com/api-references/auth--sign/sign">/sign</a> endpoints, MUST be assigned the value received in the <code>UserMessage</code> extension. </p>
+<p>When an error occurs during an authentication or signature operation, the Identity Provider MUST display an error message that can be easily understood by the end user, and offer the possibility to acknowledge the error so that an error response may be posted back to the requesting Service Provider (as specified in section 6.4, &quot;Error Responses&quot;, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]).</p>
 <p><a name="automatic-start-of-bankid-client"></a></p>
-<h3 id="3.2.-automatic-start-of-the-bankid-client">3.2. Automatic Start of the BankID Client</h3>
-<p>When an operation is initiated where the BankID client (app or desktop program) is on the same device as the user agent (web browser) the Identity Provider SHOULD attempt to &quot;auto start&quot; the BankID client as described in [<a href="#bankid_spec">BankID_Spec</a>].  </p>
-<p>For the above cases where the BankID client is automatically started from the Identity Provider, the Identity Provider user interface SHOULD NOT ask for the user&#39;s personal identity number. This information is available in the &quot;BankID app&quot; or &quot;BankID Security Application&quot;.</p>
-<p>Auto starting the BankID app from a mobile device requires the built-in web browser to be used to guarantee full support, see section 3.1 of [<a href="#bankid_spec">BankID_Spec</a>]. If the Identity Provider detects that the user is not using the platform&#39;s default browser it SHOULD prompt for the personal identity number and ask the user to manually start the BankID app (and switch back to the browser after the BankID operation).</p>
-<blockquote>
-<p><strong>Note:</strong> As an alternative to the above requirement the Identity Provider may display a button with an autostart link that starts the BankID app when clicked. The personal identity number will not be needed and the user will not have to start the app manually. </p>
-<p>However, on iOS this will not work if an embedded browser is running within an app, since apps that are started by apps need to be whitelisted. Another thing to take into account is that the user still has to switch back from the BankID app to the browser, and that may not be obvious for the user (since the app was started automatically). </p>
-<p>The recommendation is to abstain from using autostart links/buttons.</p>
-</blockquote>
-<p><a name="mobile-bankid-on-another-device"></a></p>
-<h3 id="3.3.-mobile-bankid-on-another-device">3.3. Mobile BankID on another Device</h3>
-<p>If the user agent (web browser) and the BankID app is not on the same device, a BankID Identity 
-Provider that supports the BankID QR code feature MUST check for the presence of the 
-<code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category
-in a requesting Service Provider&#39;s metadata entry. If the Service Provider has declared this entity category, the BankID Identity Provider MUST display a generated QR code for the user and 
-MUST NOT prompt the user for the personal identity number.</p>
-<blockquote>
-<p>Note: If the <code>secure-authenticator-binding</code> entity category is present in the Service Provider 
-metadata entry <strong>and</strong> a <code>&lt;psc:PrincipalSelection&gt;</code> extension containing a personal identity number 
-is included in the authentication request from the Service Provider, the BankID Identity Provider 
-SHOULD include this number in the BankID operation (<code>auth</code> or <code>sign</code>) along with the BankID
-requirement parameter <code>autoStartTokenRequired=true</code> when initializing the BankID operation 
-(see chapter 4 in [<a href="#bankid_spec">BankID_Spec</a>]). A generated QR code MUST still be displayed 
-by the BankID Identity Provider, but by providing the personal identity number in the initializing BankID call the session will be bound not only to the BankID app that is used to scan the QR code but also to a specific user. If a user with a different personal identity number scans the QR code the operation will fail.</p>
-</blockquote>
-<p>If the <code>secure-authenticator-binding</code> entity category is not declared by the requesting Service
-Provider, the Identity Provider needs to prompt the user for his or hers personal identity number (personnummer) in order to initiate a BankID operation. </p>
-<p>Before prompting the user the Identity Provider SHOULD check if the current authentication request contains a <code>&lt;psc:PrincipalSelection&gt;</code> extension holding a personal identity number attribute value. </p>
-<p>If the personal identity number is present in the <code>&lt;psc:PrincipalSelection&gt;</code> extension and the current operation is an &quot;authentication for signature&quot; operation (see <a href="#authentication-for-signature">section 4.2 below</a>), the Identity Provider MUST NOT prompt the user for the personal identity number, but use the value received in the request to initiate the signature operation.</p>
-<p>If the current operation is an &quot;ordinary&quot; authentication and the personal identity number is received in the request, the Identity Provider MAY use this value to pre-fill the personal identity number in the prompt dialogue to make the user experience smooth, but it SHOULD NOT use it to initiate the BankID operation without user interaction. </p>
-<blockquote>
-<p>Note: Until the <code>&lt;psc:PrincipalSelection&gt;</code> extension is widely used the Identity Provider MAY save the personal identity number in the user&#39;s web browser session storage (in a session cookie or more preferably using the HTML5 sessionStorage object). That way the Identity Provider can avoid prompting the user for the personal identity number for signature operations even if the requesting Signature Service does not support the <code>&lt;psc:PrincipalSelection&gt;</code> extension.</p>
-</blockquote>
-<p>See also section <a href="#mobile-bankid-and-the-personnumber-attribute">4.2.2</a>, &quot;<a href="#mobile-bankid-and-the-personnumber-attribute">Mobile BankID and the personNumber attribute</a>&quot;.</p>
-<p><a name="user-experience-recommendations"></a></p>
-<h4 id="3.3.1.-user-experience-recommendations">3.3.1. User Experience Recommendations</h4>
-<p>In a scenario where the user first logs in to a service, and later performs a signature, care should be taken to the user experience versus security. The user will probably think is disturbing to have to scan a QR code for every signature he or she performs within the logged in session. If the service can protect against the remote fraudster threat by using QR code for login, and if the <code>&lt;psc:PrincipalSelection&gt;</code> extension preventing personal identity number prompting is used for subsequent signatures, we probably have found the safest and most user friendly process. </p>
-<p>This could be accomplished by declaring the <code>secure-authenticator-binding</code> entity category for the Service Provider responsible of user login, but not declaring it for the service&#39;s Signature Service. Instead the Signature Service makes sure to always include the <code>&lt;psc:PrincipalSelection&gt;</code> extension in authentication requests sent.</p>
-<p>Note: An Identity Provider processing a request from a signature service can derive the QR versus prompting for personal identity number setting for the corresponding &quot;login service&quot; if the <code>RequesterID</code> element is present in the authentication request. This element holds the entityID for the login service that initiated the signature operation.</p>
+<h3 id="32-automatic-start-of-the-bankid-client">3.2. Automatic Start of the BankID Client</h3>
+<p>When an operation is initiated where the BankID client (app or desktop program) is on the same device as the user agent (web browser) the Identity Provider SHOULD attempt to &quot;auto start&quot; the BankID client as described in the <a href="https://developers.bankid.com/getting-started/use-cases">BankID guide</a>.  </p>
+<p>Auto starting the BankID app from a mobile device requires the built-in web browser to be used to guarantee support. If the Identity Provider detects that the user is not using the platform&#39;s default browser it MAY ask the user to manually start the BankID app (and switch back to the browser after the BankID operation).</p>
 <p><a name="cancelling-an-operation"></a></p>
-<h3 id="3.4.-cancelling-an-operation">3.4. Cancelling an Operation</h3>
+<h3 id="33-cancelling-an-operation">3.3. Cancelling an Operation</h3>
 <p>A BankID Identity Provider MUST include a Cancel-button in the user interface enabling the possibility for the user to cancel the BankID operation. </p>
-<p>If the use clicks the Cancel-button after a BankID-operation has been started<sup>1</sup> the Identity Provider MUST invoke the BankID-operation <code>/rp/v5/cancel</code>. Failure to do so may lead to a dangling BankID session that needs to time out before the user can use BankID again.</p>
+<p>If the use clicks the Cancel-button after a BankID-operation has been started<sup>1</sup> the Identity Provider MUST invoke the BankID-operation <code>/cancel</code>. Failure to do so may lead to a dangling BankID session that needs to time out before the user can use BankID again.</p>
 <blockquote>
-<p>[1]: Meaning that <code>/rp/v5/auth</code> or <code>/rp/v5/sign</code> has been called for the transaction.</p>
+<p>[1]: Meaning that <code>/auth</code> or <code>/sign</code> has been called for the transaction.</p>
 </blockquote>
 <p><a name="authentication-requests"></a></p>
-<h2 id="4.-authentication-requests">4. Authentication Requests</h2>
+<h2 id="4-authentication-requests">4. Authentication Requests</h2>
 <p><a name="binding-and-security-requirements"></a></p>
-<h3 id="4.1.-binding-and-security-requirements">4.1. Binding and Security Requirements</h3>
+<h3 id="41-binding-and-security-requirements">4.1. Binding and Security Requirements</h3>
 <p>An Identity Provider conformant with this profile MUST require <code>&lt;saml2p:AuthnRequest&gt;</code> messages to be signed (by indicating this in its metadata, see section <a href="#metadata">6</a>, &quot;<a href="#metadata">Metadata</a>&quot;). Thus, the Identity Provider MUST not accept messages that are not signed, or where the verification of the signature fails. In these cases the Identity Provider MUST respond with an error.</p>
+<p><a name="handling-of-principal-selection"></a></p>
+<h3 id="42-handling-of-principal-selection">4.2. Handling of Principal Selection</h3>
+<p>An Identity Provider that has declared support for the <code>&lt;psc:PrincipalSelection&gt;</code> extension (see section <a href="#metadata">6</a>) MUST assign the <code>requirement.personalNumber</code> field of <a href="https://developers.bankid.com/api-references/auth--sign/auth">/auth</a> or <a href="https://developers.bankid.com/api-references/auth--sign/sign">/sign</a> if a Swedish personal identity number is received in the <code>&lt;psc:PrincipalSelection&gt;</code> extension.</p>
+<p>See [<a href="#sc-saml-principal">SC.SAML.Principal</a>] for further requirements concerning the principal selection extension.</p>
 <p><a name="authentication-for-signature"></a></p>
-<h3 id="4.2.-authentication-for-signature">4.2. Authentication for Signature</h3>
-<p>An Identity Provider conforming to the Swedish eID Framework is obliged to handle requests received from Signature Services as described in section 7, “Authentication for Signature”, of [<a href="#eid-profile">EidProfile</a>]. This section further specifies how a BankID Identity Provider should support “authentication for signature”.</p>
+<h3 id="43-authentication-for-signature">4.3. Authentication for Signature</h3>
+<p>An Identity Provider conforming to the Sweden Connect Framework is obliged to handle requests received from Signature Services as described in section 7, “Authentication for Signature”, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. This section further specifies how a BankID Identity Provider should support “authentication for signature”.</p>
 <p>A BankID Identity Provider that receives an <code>&lt;saml2p:AuthnRequest&gt;</code> message from a Signature Service MUST initiate a BankID <strong>signature</strong> operation. It MUST NOT initiate a BankID authentication operation for several reasons: </p>
 <ul class="list">
 <li>the user interface in the BankID client (app or Desktop program) during authentication indicates that the user is logging on (and not signing which is the case when a request from a Signature Service is being processed), </li>
@@ -357,41 +285,30 @@ <h3 id="4.2.-authentication-for-signature">4.2. Authentication for Signature</h3
 <li>and most importantly, BankID is PKI-based and has support for signing using a non-repudiation key, so there is no reason not to use this function.</li>
 </ul>
 <p>The BankID client (app or desktop program) comprises a text box in which the signature message is displayed for the user. A BankID Identity Provider MUST NOT display the signature message in any other way than in this text box. How the signature message is assigned is specified below.</p>
-<p>If the BankID Identity Provider prompts the user for his or hers personal identity number in order to initialize
-the BankID signature operation, the Identity Provider MUST honour the requirement that ensures that a sign message is only displayed to the intended principal, see section 7.2.1 in [<a href="#eid-profile">EidProfile</a>].</p>
 <p><a name="input-to-bankid-signing"></a></p>
-<h4 id="4.2.1.-input-to-bankid-signing">4.2.1. Input to BankID Signing</h4>
+<h4 id="431-input-to-bankid-signing">4.3.1. Input to BankID Signing</h4>
 <p>An Identity Provider that processes an <code>&lt;saml2p:AuthnRequest&gt;</code> from a Signature Service is not given the actual data that is being signed by the user via the Signature Service. However, in order to invoke the BankID signature function, the Identity Provider must supply the BankID-server with data to be signed. This section specifies the input to the BankID signature operation.</p>
-<p>The &quot;To-be-signed&quot; data that is passed as input the the BankID Sign-method (<code>/rp/v5/sign</code>) is a combination of the data from the <code>userVisibleData</code> and <code>userNonVisibleData</code> parameters (section 14.1.2 of [<a href="#bankid_spec">BankID_Spec</a>]).</p>
+<p>The &quot;To-be-signed&quot; data that is passed as input the BankID Sign-method (<code>/sign</code>) is a combination of the data from the <code>userVisibleData</code> and <code>userNonVisibleData</code> parameters (<a href="https://developers.bankid.com/api-references/auth--sign/sign">https://developers.bankid.com/api-references/auth--sign/sign</a>).</p>
 <p><a name="uservisibledata"></a></p>
-<h5 id="4.2.1.1.-uservisibledata---signature-message">4.2.1.1. userVisibleData - Signature Message</h5>
-<p>The Sign-method parameter <code>userVisibleData</code> holds data that will be signed by the user but it is also displayed in the BankID application text box.</p>
+<h5 id="4311-uservisibledata---signature-message">4.3.1.1. userVisibleData - Signature Message</h5>
+<p>The Sign-method parameter <code>userVisibleData</code> holds data that will be signed by the user, but it is also displayed in the BankID application text box.</p>
 <p>If the <code>&lt;saml2p:AuthnRequest&gt;</code> message contains a <code>SignMessage</code> extension, the contents of this message MUST be assigned to the <code>userVisibleData</code> parameter (after necessary encoding).</p>
-<p>A BankID Identity Provider MUST support <code>SignMessage</code> elements having their <code>MimeType</code> attribute set to <code>text</code>, and SHOULD support
-Markdown (<code>text/markdown</code>) according to <a href="#bankid-md">BankID - Guidelines for Formatted Text</a>, [<a href="#bankid-md">BankID_MD</a>], and section 14.1.2 of [<a href="#bankid_spec">BankID_Spec</a>]. For other values (<code>text/html</code>), the Identity Provider MUST respond with an error.</p>
+<p>A BankID Identity Provider MUST support <code>SignMessage</code> elements having their <code>MimeType</code> attribute set to <code>text</code>, and SHOULD support Markdown (<code>text/markdown</code>) according to <a href="#bankid-md">BankID - Guidelines for Formatted Text</a>, [<a href="#bankid-md">BankID.MD</a>]. For other values (<code>text/html</code>), the Identity Provider MUST respond with an error.</p>
 <p>If the <code>&lt;saml2p:AuthnRequest&gt;</code> message does not contain a <code>SignMessage</code> extension, the Identity Provider MUST assign a sensible default signature message to the <code>userVisibleData</code> parameter. How this message is constructed is the responsibility of the Identity Provider, but it must be obvious for the user who is the requesting party, i.e., the Service Provider that has ordered the signature operation<sup>2</sup>.</p>
 <blockquote>
 <p>[1]: If the <code>MimeType</code> attribute is not set, <code>text</code> is the default value.</p>
-<p>[2]: For this purpose, the <code>&lt;mdui:DisplayName&gt;</code> element of the Signature Service’s metadata entry, is a good and generic choice.  </p>
+<p>[2]: For this purpose, the <code>&lt;mdui:DisplayName&gt;</code> element of the Signature Service’s metadata entry, is a good and generic choice.</p>
 </blockquote>
 <p><a name="usernonvisibledata"></a></p>
-<h5 id="4.2.1.2.-usernonvisibledata">4.2.1.2. userNonVisibleData</h5>
+<h5 id="4312-usernonvisibledata">4.3.1.2. userNonVisibleData</h5>
 <p>In order to produce a BankID signature that contains a binding to the <code>&lt;saml2p:AuthnRequest&gt;</code> message that initiated this signature, a BankID Identity Provider compliant to this profile MUST assign the  <code>userNonVisibleData</code> parameter with data that uniquely binds the signature to the <code>&lt;saml2p:AuthnRequest&gt;</code> message.</p>
 <p>It is RECOMMENDED that the following function is used to produce this unique binding:</p>
-<pre class="hljs"><code>Base64Encode(<span class="hljs-string">"entityID="</span> + URLEncode(<span class="hljs-name">&lt;entityID</span> of SP&gt;) + <span class="hljs-string">";"</span> + <span class="hljs-string">"authnRequestID="</span> + URLEncode(<span class="hljs-name">&lt;ID</span> of AuthnRequest&gt;))</code></pre><p><a name="mobile-bankid-and-the-personnumber-attribute"></a></p>
-<h4 id="4.2.2.-mobile-bankid-and-the-personnumber-attribute">4.2.2. Mobile BankID and the personNumber attribute</h4>
-<p>When Mobile BankID is being used to sign data and the user has initiated the signature operation against the Signature Service from another device (desktop och tablet), and the BankID QR code functionality is not being used, the <code>personNumber</code> parameter must be assigned in the BankID Sign-call.</p>
-<p>Preferably this information was received in the <code>&lt;psc:PrincipalSelection&gt;</code> of the <code>&lt;saml2p:AuthnRequest&gt;</code> as described in section <a href="#mobile-bankid-on-another-device">3.3</a>, &quot;<a href="#mobile-bankid-on-another-device">Mobile BankID on another Device</a>&quot;. </p>
-<p>Identity Providers wanting to support Signature Services that do not include the <code>&lt;psc:PrincipalSelection&gt;</code> extension MAY store the personal identity number in the user&#39;s web browser session storage during authentication, and use it during signature<sup>1</sup>, see section <a href="#mobile-bankid-on-another-device">3.3</a> above.</p>
-<blockquote>
-<p>[1]: Almost all use cases where a user signs data is preceded by a login (authentication).</p>
-</blockquote>
-<p><a name="authentication-responses"></a></p>
-<h2 id="5.-authentication-responses">5. Authentication Responses</h2>
+<pre class="hljs"><code><span class="hljs-constructor">Base64Encode(<span class="hljs-string">&quot;entityID=&quot;</span> + URLEncode(&lt;<span class="hljs-params">entityID</span> <span class="hljs-params">of</span> SP&gt;)</span> + <span class="hljs-string">&quot;;&quot;</span> + <span class="hljs-string">&quot;authnRequestID=&quot;</span> + <span class="hljs-constructor">URLEncode(&lt;ID <span class="hljs-params">of</span> AuthnRequest&gt;)</span>)</code></pre><p><a name="authentication-responses"></a></p>
+<h2 id="5-authentication-responses">5. Authentication Responses</h2>
 <p><a name="attribute-release-rules"></a></p>
-<h3 id="5.1.-attribute-release-rules">5.1. Attribute Release Rules</h3>
-<p>Section <a href="#attribute-transformation">2.1</a>, &quot;<a href="#attribute-transformation">Attribute Transformation</a>&quot;, specifies how BankID attributes should be transformed into SAML attributes defined in [<a href="#eid-attributes">EidAttributes</a>]. However, it does not specify the attribute release rules stating which attributes that are to be released based on a particular request.</p>
-<p>A BankID Identity Provider compliant to the Swedish eID Framework MUST honor the attribute release rules specified in section 6.2.1, &quot;Attribute Release Rules&quot;, of [<a href="#eid-profile">EidProfile</a>]. This section further extends these rules with the following:</p>
+<h3 id="51-attribute-release-rules">5.1. Attribute Release Rules</h3>
+<p>Section <a href="#attribute-transformation">2.1</a>, &quot;<a href="#attribute-transformation">Attribute Transformation</a>&quot;, specifies how BankID attributes should be transformed into SAML attributes defined in [<a href="#sc-saml-attrs">SC.SAML.Attrs</a>]. However, it does not specify the attribute release rules stating which attributes that are to be released based on a particular request.</p>
+<p>A BankID Identity Provider compliant to the Swedish eID Framework MUST honor the attribute release rules specified in section 6.2.1, &quot;Attribute Release Rules&quot;, of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. This section further extends these rules with the following:</p>
 <ul class="list">
 <li>A BankID Identity Provider SHOULD include the <code>transactionIdentifier</code>-attribute (a mapping of the BankID <code>orderRef</code>-attribute) in the <code>&lt;saml2:AttributeStatement&gt;</code> element independently of which attribute set that is requested. This attribute links the BankID operation to the assertion.</li>
 <li>It is RECOMMENDED that a BankID Identity Provider includes the <code>userSignature</code>-attribute (containing the BankID signature) in the <code>&lt;saml2:AttributeStatement&gt;</code> element when a BankID signature operation has been performed.</li>
@@ -399,10 +316,12 @@ <h3 id="5.1.-attribute-release-rules">5.1. Attribute Release Rules</h3>
 </ul>
 <blockquote>
 <p>[1]: A Service Provider explicitly requests attributes by declaring them as requested attributes in the <code>&lt;md:AttributeConsumingService&gt;</code> element of the Service Provider&#39;s metadata entry. See section <a href="#service-providers">6.1</a>.</p>
+</blockquote>
+<blockquote>
 <p>[2]: Based on the service entity categories that a Service Provider has declared in its metadata, an Identity Provider derives which attribute sets to apply during attribute release.</p>
 </blockquote>
 <p><a name="error-responses"></a></p>
-<h3 id="5.2.-error-responses">5.2. Error Responses</h3>
+<h3 id="52-error-responses">5.2. Error Responses</h3>
 <p>A BankID Identity Provider MUST map errors received from the underlying BankID-server into SAML error response messages where the top level status code is either:</p>
 <ul class="list">
 <li><code>urn:oasis:names:tc:SAML:2.0:status:Requester</code> - for errors that are due to authentication or signature failures or faults due to an error on the part of the Service Provider,</li>
@@ -413,65 +332,55 @@ <h3 id="5.2.-error-responses">5.2. Error Responses</h3>
 <p>If the user cancels a BankID operation, either by clicking the Cancel-button in the Identity Provider user interface or the Cancel-button in the BankID app/Security Application, the Identity Provider SHOULD respond with a <code>&lt;saml2p:Response&gt;</code> message where the second level status code is <code>http://id.elegnamnden.se/status/1.0/cancel</code>.</p>
 <p>In cases where the Identity Provider receives the BankID error code <code>ALREADY_IN_PROGRESS</code> in response to an Auth- or Sign-call the Identity Provider MAY display a warning to the user that someone may have initiated a BankID operation using their personal identity number<sup>1</sup>. If this warning is displayed, it is RECOMMENDED that the second level status code <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> is included in the error response message posted back to the Service Provider.</p>
 <blockquote>
-<p>[1]: There have been reports where fraudsters remotely try to convince people of using their Mobile BankID to log in to a service. In these cases, the fraudster initiates a BankID authentication prior to the person he tries to trick into logging in to the service, and is waiting for the user to enter his or hers personal code, thus authenticating the fraudsters session. </p>
+<p>[1]: There have been reports where fraudsters remotely try to convince people of using their Mobile BankID to log in to a service. In these cases, the fraudster initiates a BankID authentication prior to the person he tries to trick into logging in to the service, and is waiting for the user to enter his or hers personal code, thus authenticating the fraudster&#39;s session. </p>
 </blockquote>
 <p><a name="metadata"></a></p>
-<h2 id="6.-metadata">6. Metadata</h2>
-<p>This section extends section 2 of [<a href="#eid-profile">EidProfile</a>] with requirements specific for BankID.</p>
+<h2 id="6-metadata">6. Metadata</h2>
+<p>This section extends section 2 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>] with requirements specific for BankID.</p>
 <p><a name="service-providers"></a></p>
-<h3 id="6.1.-service-providers">6.1. Service Providers</h3>
+<h3 id="61-service-providers">6.1. Service Providers</h3>
 <p>As stated in section <a href="#attribute-release-rules">5.1</a>, &quot;<a href="#attribute-release-rules">Attribute Release Rules</a>&quot;, a Service Provider may request additional attributes, other than those implicitly requested via the use of service entity categories, by declaring requested attributes under the <code>&lt;md:AttributeConsumingService&gt;</code> element.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:AttributeConsumingService</span> <span class="hljs-attr">index</span>=<span class="hljs-string">"0"</span> <span class="hljs-attr">isDefault</span>=<span class="hljs-string">"true"</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">"http://www.w3.org/XML/1998/namespace"</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">"sv"</span>&gt;</span>E-myndigheten<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">"http://www.w3.org/XML/1998/namespace"</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">"en"</span>&gt;</span>The e-Authority<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
+<pre class="hljs"><code>&lt;<span class="hljs-built_in">md</span>:AttributeConsumingService index=<span class="hljs-string">&quot;0&quot;</span> isDefault=<span class="hljs-string">&quot;true&quot;</span> xmlns:<span class="hljs-built_in">md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>&gt;
+  &lt;<span class="hljs-built_in">md</span>:ServiceName xmlns:xml=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> xml:lang=<span class="hljs-string">&quot;sv&quot;</span>&gt;E<span class="hljs-literal">-myndigheten</span>&lt;/<span class="hljs-built_in">md</span>:ServiceName&gt;
+  &lt;<span class="hljs-built_in">md</span>:ServiceName xmlns:xml=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> xml:lang=<span class="hljs-string">&quot;en&quot;</span>&gt;The e<span class="hljs-literal">-Authority</span>&lt;/<span class="hljs-built_in">md</span>:ServiceName&gt;
   ...
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:RequestedAttribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.2"</span> <span class="hljs-attr">isRequired</span>=<span class="hljs-string">"false"</span>/&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:RequestedAttribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.13"</span> <span class="hljs-attr">isRequired</span>=<span class="hljs-string">"false"</span>/&gt;</span>      
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:AttributeConsumingService</span>&gt;</span></code></pre><p><em>Example of how a Service Provider declares that it wishes to receive the transactionIdentifier and authServerSignature attributes in assertions.</em></p>
+  &lt;<span class="hljs-built_in">md</span>:RequestedAttribute Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.2&quot;</span> isRequired=<span class="hljs-string">&quot;false&quot;</span>/&gt;
+  &lt;<span class="hljs-built_in">md</span>:RequestedAttribute Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.13&quot;</span> isRequired=<span class="hljs-string">&quot;false&quot;</span>/&gt;      
+&lt;/<span class="hljs-built_in">md</span>:AttributeConsumingService&gt;</code></pre><p><em>Example of how a Service Provider declares that it wishes to receive the transactionIdentifier and authServerSignature attributes in assertions.</em></p>
 <p>A Service Provider requesting an attribute that is not supported by all Identity Providers that it may communicate with MUST NOT set the <code>isRequired</code> attribute of the <code>&lt;md:RequestedAttribute&gt;</code> element to <code>true</code>.</p>
 <p>It is RECOMMENDED that Service Providers communicating with BankID Identity Providers include the <code>transactionIdentifier</code> attribute as a requested attribute.</p>
-<p>As described in section <a href="#relying-party-configuration">1.4</a>, &quot;<a href="&quot;#relying-party-configuration&quot;">Relying Party Configuration</a>, a Service Provider may declare an entity category telling the BankID Identity Provider that it wishes QR codes to be used instead of prompting for the user personal identity number.</p>
-<pre class="hljs"><code>&lt;mdattr:EntityAttributes xmln<span class="hljs-variable">s:mdattr</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:attribute"</span>&gt;
-  &lt;sam<span class="hljs-variable">l:Attribute</span> Name=<span class="hljs-string">"http://macedir.org/entity-category"</span> 
-                  NameFormat=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>&gt;
-    &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span>&gt;
-      http://id.swedenconnect.<span class="hljs-keyword">se</span>/general-<span class="hljs-keyword">ec</span>/<span class="hljs-number">1.0</span>/secure-authenticator-binding
-    &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;
-    ...
-  &lt;/sam<span class="hljs-variable">l:Attribute</span>&gt;
-&lt;/mdattr:EntityAttributes&gt;</code></pre><p><em>Example of how a Service Provider declares the secure authenticator binding entity category. This means, for a BankID Identity Provider, that QR codes should be used to initiate BankID operations.</em></p>
 <p><a name="identity-providers"></a></p>
-<h3 id="6.2.-identity-providers">6.2. Identity Providers</h3>
+<h3 id="62-identity-providers">6.2. Identity Providers</h3>
 <p>A BankID Identity Provider MUST require authentication request messages to be signed. This is indicated by assigning the <code>WantAuthnRequestsSigned</code> attribute of the <code>&lt;md:IDPSSPDescriptor&gt;</code> element to a value of <code>true</code>. </p>
-<p>A BankID Identity Provider SHOULD declare the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element containing the attribute name for personalIdentityNumber (<code>urn:oid:1.2.752.29.4.13</code>) and include it in its metadata entry as described in section 2.1.3 of [<a href="#eid-profile">EidProfile</a>]. </p>
+<p>A BankID Identity Provider SHOULD declare the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element containing the attribute name for personalIdentityNumber (<code>urn:oid:1.2.752.29.4.13</code>) and include it in its metadata entry as described in section 2.1.3 of [<a href="#sc-saml-profile">SC.SAML.Profile</a>]. </p>
 <p>Using this extension the Identity Provider announces that the requestor should send the personal identity number in the authentication request if this is known to the requestor. In this way, the Identity Provider does not have to prompt the user for the personal identity number for the use cases where this is required.</p>
 <pre class="hljs"><code>...
-<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">"true"</span>
-     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:protocol"</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">&quot;true&quot;</span>
+     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:protocol&quot;</span>&gt;</span>
   <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:ui"</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:ui&quot;</span>&gt;</span>
       ...
     <span class="hljs-tag">&lt;/<span class="hljs-name">mdui:UIInfo</span>&gt;</span>
     <span class="hljs-tag">&lt;<span class="hljs-name">psc:RequestedPrincipalSelection</span> 
-         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.29.4.13"</span> /&gt;</span>
+         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span> /&gt;</span>
     <span class="hljs-tag">&lt;/<span class="hljs-name">psc:RequestedPrincipalSelection</span>&gt;</span>
   <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">"signing"</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;signing&quot;</span>&gt;</span>
     ...</code></pre><p><em>Example of how the Identity Provider declares the <code>RequestedPrincipalSelection</code> extension in its metadata.</em></p>
-<p>A BankID Identity Provider supporting the BankID QR code feature MUST declare this in its metadata using
-the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category.</p>
+<p>Also, since a BankID Identity Provider MUST support the display of BankID QR codes, it MUST declare this in its metadata using the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category. See [<a href="#sc-saml-entcat">SC.SAML.EntCat</a>].</p>
+<p>It is RECOMMENDED that the BankID Identity Provider supports the <code>&lt;umsg:UserMessage&gt;</code> authentication request extension as defined in [<a href="#sc-saml-umsg">SC.SAML.UMsg</a>]. Support for this extension is declared by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category. See [<a href="#sc-saml-entcat">SC.SAML.EntCat</a>].</p>
 <p><a name="signature-services"></a></p>
-<h3 id="6.3.-signature-services">6.3. Signature Services</h3>
+<h3 id="63-signature-services">6.3. Signature Services</h3>
 <p>It is RECOMMENDED that a Signature Service explicitly requires release of the <code>userSignature</code> attribute (<code>urn:oid:1.2.752.201.3.11</code>) in assertions. The reason for this is that the BankID-signature may then be part of the assertion that is included in the resulting signature created by the Signature Service giving a non-repudiation proof of the BankID signature process.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:AttributeConsumingService</span> <span class="hljs-attr">index</span>=<span class="hljs-string">"0"</span> <span class="hljs-attr">isDefault</span>=<span class="hljs-string">"true"</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">"http://www.w3.org/XML/1998/namespace"</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">"sv"</span>&gt;</span>E-myndighetens underskriftstjänst<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">"http://www.w3.org/XML/1998/namespace"</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">"en"</span>&gt;</span>The e-Authority's Signing Service<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
+<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:AttributeConsumingService</span> <span class="hljs-attr">index</span>=<span class="hljs-string">&quot;0&quot;</span> <span class="hljs-attr">isDefault</span>=<span class="hljs-string">&quot;true&quot;</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&quot;sv&quot;</span>&gt;</span>E-myndighetens underskriftstjänst<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:ServiceName</span> <span class="hljs-attr">xmlns:xml</span>=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> <span class="hljs-attr">xml:lang</span>=<span class="hljs-string">&quot;en&quot;</span>&gt;</span>The e-Authority&#x27;s Signing Service<span class="hljs-tag">&lt;/<span class="hljs-name">md:ServiceName</span>&gt;</span>
   ...
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:RequestedAttribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.11"</span> <span class="hljs-attr">isRequired</span>=<span class="hljs-string">"false"</span>/&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:RequestedAttribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.11&quot;</span> <span class="hljs-attr">isRequired</span>=<span class="hljs-string">&quot;false&quot;</span>/&gt;</span>
 <span class="hljs-tag">&lt;/<span class="hljs-name">md:AttributeConsumingService</span>&gt;</span></code></pre><p><em>Example of how the userSignature attribute is explicitly required.</em></p>
 <p><a name="references"></a></p>
-<h2 id="7.-references">7. References</h2>
+<h2 id="7-references">7. References</h2>
 <p><a name="rfc2119"></a>
 <strong>[RFC2119]</strong></p>
 <blockquote>
@@ -499,39 +408,53 @@ <h2 id="7.-references">7. References</h2>
 Entity Attributes Version 1.0, August
 2009</a>.</p>
 </blockquote>
-<p><a name="bankid-spec"></a>
-<strong>[BankID_Spec]</strong></p>
-<blockquote>
-<p><a href="https://www.bankid.com/assets/bankid/rp/bankid-relying-party-guidelines-v3.6.pdf">BankID Relying Party Guidelines, version 3.6</a>.</p>
-<p>Check <a href="https://www.bankid.com/utvecklare/guider">https://www.bankid.com/utvecklare/guider</a> for the latest version.</p>
-</blockquote>
 <p><a name="bankid-md"></a>
-<strong>[BankID_MD]</strong></p>
+<strong>[BankID.MD]</strong></p>
 <blockquote>
 <p><a href="https://www.bankid.com/utvecklare/guider/formatera-text">BankID - Guidelines for Formatting Text</a>.</p>
 </blockquote>
-<p><a name="eid-profile"></a>
-<strong>[EidProfile]</strong></p>
+<p><a name="sc-saml-profile"></a>
+<strong>[SC.SAML.Profile]</strong></p>
 <blockquote>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
 </blockquote>
-<p><a name="eid-attributes"></a>
-<strong>[EidAttributes]</strong></p>
+<p><a name="sc-saml-attrs"></a>
+<strong>[SC.SAML.Attrs]</strong></p>
 <blockquote>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
 </blockquote>
-<p><a name="eidentcat"></a>
-<strong>[EidEntCat]</strong></p>
+<p><a name="sc-saml-entcat"></a>
+<strong>[SC.SAML.EntCat]</strong></p>
 <blockquote>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
 </blockquote>
-<p><a name="principalsel"></a>
-<strong>[PrincipalSel]</strong></p>
+<p><a name="sc-saml-principal"></a>
+<strong>[SC.SAML.Principal]</strong></p>
 <blockquote>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="8.-changes-between-versions">8. Changes between versions</h2>
 </blockquote>
+<p><a name="sc-saml-umsg"></a>
+<strong>[SC.SAML.UMsg]</strong></p>
+<blockquote>
+<p><a href="https://docs.swedenconnect.se/technical-framework/latest/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
+</blockquote>
+<p><a name="changes-between-versions"></a></p>
+<h2 id="8-changes-between-versions">8. Changes between versions</h2>
+<p><strong>Changes between version 1.3 and 1.4</strong></p>
+<ul class="list">
+<li><p>New references to BankID resources are used, since BankID has abandoned its &quot;Relying Party Guidelines&quot;-document.</p>
+</li>
+<li><p>The discussions concerning QR-codes vs. prompting for personal ID number has been removed, since QR-code now is mandatory for the use case where the user agent and mobile phone are on different devices.</p>
+</li>
+<li><p>Section 2.1, &quot;Attribute Transformation&quot;, was updated to reflect changes in the BankID API.</p>
+</li>
+<li><p>A recommendation to support the &quot;User Message Extension&quot; was added to section 3, &quot;Identity Provider User Interface&quot;.</p>
+</li>
+<li><p>Section 3.3, &quot;Mobile BankID on another Device&quot;, was removed since personal identity number prompting is no longer allowed.</p>
+</li>
+<li><p>Section 4.2, &quot;Handling of Principal Selection&quot;, was introduced.</p>
+</li>
+</ul>
 <p><strong>Changes between version 1.2 and 1.3:</strong></p>
 <ul class="list">
 <li>Section 4.2.1.1, &quot;userVisibleData - Signature Message&quot;, was updated with information about the usage of Markdown in visible sign data.</li>
diff --git a/docs/november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html b/docs/november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
index 03b014b..887e865 100644
--- a/docs/november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
+++ b/docs/november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
@@ -19,7 +19,7 @@
 </p>
 
 <h1 id="principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</h1>
-<h3 id="version-1.0---2020-01-17">Version 1.0 - 2020-01-17</h3>
+<h3 id="version-10---2020-01-17">Version 1.0 - 2020-01-17</h3>
 <p>Registration number: <strong>2019-318</strong></p>
 <hr>
 <p class="copyright-statement">
@@ -50,55 +50,55 @@ <h2 id="table-of-contents">Table of Contents</h2>
 </li>
 </ol>
 <p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
+<h2 id="1-introduction">1. Introduction</h2>
 <p>When a Service Provider requests authentication of a user (principal), the Service Provider may have prior knowledge about the user to be authenticated, for example, when re-authenticating an already authenticated user, or when a user authenticates to a signature service where the user signs a document in a context where he or she already has been authenticated.</p>
 <p>This specification defines the <code>&lt;psc:PrincipalSelection&gt;</code> element that may be included in the <code>&lt;saml2p:Extensions&gt;</code> element of a SAML <code>&lt;saml2p:AuthnRequest&gt;</code> where the requesting Service Provider can specify matching criteria that may be used by the Identity Provider to select the particular user that should be authenticated.</p>
 <p>The specification also defines the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> element that should be used by Identity Providers that may need information about a known user in order to avoid prompting for the user ID<sup>1</sup>. The element should be included as an extension in the Identity Provider metadata under the <code>&lt;md:IDPSSODescriptor&gt;</code> element.</p>
 <p>Even though the main purpose of the <code>&lt;psc:PrincipalSelection&gt;</code> extension is to aid the Identity Provider
-in selecting a particular subject for the authentication, an Identity Provider MAY also compare the match
-values present in the extension with the resulting attributes from the user authentication, and in case of a
+in selecting a particular subject for the authentication, an Identity Provider MAY also compare the match 
+values present in the extension with the resulting attributes from the user authentication, and in case of a 
 mismatch, respond with an error. In these cases the second-level SAML status code MUST be set to
 <code>urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal</code> [<a href="#saml2core">SAML2Core</a>].</p>
 <blockquote>
 <p>[1]: The typical use case is when a user once has authenticated for a service and provided his or hers user ID to the Identity Provider, and is about to perform a signature. If the Identity Provider prompts the user for the user ID once again the user experience is poor and the Service Provider will receive customer complaints.</p>
 </blockquote>
 <p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
+<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
 <p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
 <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
 <strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
 [<a href="#rfc2119">RFC2119</a>].</p>
 <p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
 <p><a name="xml-namespace-references"></a></p>
-<h3 id="1.2.-xml-namespace-references">1.2. XML Namespace References</h3>
+<h3 id="12-xml-namespace-references">1.2. XML Namespace References</h3>
 <p>The prefix <strong>psc:</strong> stands for the Principal Selection Criteria XML schema namespace <code>http://id.swedenconnect.se/authn/1.0/principal-selection/ns</code>. </p>
 <p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
 <p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
 <p>The prefix <strong>md:</strong> stands for the OASIS SAML 2 Metadata schema namespace <code>urn:oasis:names:tc:SAML:2.0:metadata</code>.</p>
 <p><a name="structure"></a></p>
-<h3 id="1.3.-structure">1.3. Structure</h3>
+<h3 id="13-structure">1.3. Structure</h3>
 <p>This specification uses the following typographical conventions in text:
 <code>&lt;LocalElement&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
 <code>OtherCode</code>.</p>
 <p><a name="data-elements"></a></p>
-<h2 id="2.-data-elements">2. Data elements</h2>
+<h2 id="2-data-elements">2. Data elements</h2>
 <p>This specification defines the element <code>&lt;PrincipalSelection&gt;</code> to be included in the <code>&lt;Extensions&gt;</code> element of an <code>AuthnRequest</code>. </p>
 <p>This element MAY be used by an Identity Provider to select the subject to authenticate. </p>
 <p><a name="principalselection"></a></p>
-<h3 id="2.1.-principalselection">2.1. PrincipalSelection</h3>
+<h3 id="21-principalselection">2.1. PrincipalSelection</h3>
 <p>The Principal Selection Criteria is provided in a <code>&lt;PrincipalSelection&gt;</code> element. The element has the following elements and attributes:</p>
 <p><code>&lt;MatchValue&gt;</code> [One or more]</p>
 <blockquote>
 <p>This element holds values that MAY be used by the Identity Provider to match against a principal to be authenticated.</p>
 </blockquote>
 <p>The following schema fragment defines the <code>&lt;PrincipalSelection&gt;</code> element:</p>
-<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"PrincipalSelection"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:PrincipalSelectionType"</span>/&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"PrincipalSelectionType"</span>&gt;
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;PrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span>/&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PrincipalSelectionType&quot;</span>&gt;
   &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> maxOccurs=<span class="hljs-string">"unbounded"</span> name=<span class="hljs-string">"MatchValue"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:MatchValueType"</span> minOccurs=<span class="hljs-string">"1"</span>/&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> name=<span class="hljs-string">&quot;MatchValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:MatchValueType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span>/&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
 &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="matchvalue"></a></p>
-<h4 id="2.1.1-matchvalue">2.1.1 MatchValue</h4>
+<h4 id="211-matchvalue">2.1.1 MatchValue</h4>
 <p>The <code>&lt;MatchValue&gt;</code> element contains a string value to be matched against the selected principal. This element has the following attributes which determines the meaning of the match value:</p>
 <p><code>Name</code> [Required]</p>
 <blockquote>
@@ -113,101 +113,101 @@ <h4 id="2.1.1-matchvalue">2.1.1 MatchValue</h4>
 <p>Extension point for any attribute in accordance with local conventions and future specifications.</p>
 </blockquote>
 <p>The following schema fragment defines the <code>&lt;MatchValueType&gt;</code> complex type:</p>
-<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"MatchValueType"</span>&gt;
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MatchValueType&quot;</span>&gt;
   &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"NameFormat"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:anyURI"</span>
-          default=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>/&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"Name"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> use=<span class="hljs-string">"required"</span>/&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">"##any"</span>/&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;NameFormat&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span>
+          default=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>/&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span>/&gt;
     &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
 &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="requestedprincipalselection"></a></p>
-<h3 id="2.2.-requestedprincipalselection">2.2. RequestedPrincipalSelection</h3>
+<h3 id="22-requestedprincipalselection">2.2. RequestedPrincipalSelection</h3>
 <p>An Identity Provider uses the <code>&lt;RequestedPrincipalSelection&gt;</code> element to declare that it wishes to receive the <code>&lt;PrincipalSelection&gt;</code> extension element in authentication requests. The contained <code>MatchValue</code> elements should contain no values, only the attribute name of a <code>MatchValue</code> element is relevant to declare which attributes of a known user that is interest for the Identity Provider.</p>
 <p>The following schema fragment defines the <code>&lt;RequestedPrincipalSelection&gt;</code> element:</p>
-<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequestedPrincipalSelection"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:RequestedPrincipalSelectionType"</span> /&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"RequestedPrincipalSelectionType"</span>&gt;
+<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:RequestedPrincipalSelectionType&quot;</span> /&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelectionType&quot;</span>&gt;
   &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"psc:PrincipalSelectionType"</span> /&gt;
+    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
 &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="examples"></a></p>
-<h2 id="3.-examples">3. Examples</h2>
+<h2 id="3-examples">3. Examples</h2>
 <p>Attributes in the examples below are specified in [<a href="#eidattributes">EidAttributes</a>].</p>
 <p><a name="authentication-requests"></a></p>
-<h3 id="3.1.-authentication-requests">3.1. Authentication Requests</h3>
+<h3 id="31-authentication-requests">3.1. Authentication Requests</h3>
 <pre class="hljs"><code>...
 <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.29.4.13"</span>&gt;</span>197309069289<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span>&gt;</span>197309069289<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
   <span class="hljs-tag">&lt;/<span class="hljs-name">psc:PrincipalSelection</span>&gt;</span>
 <span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
 ...</code></pre><p>Example of a <code>PrincipalSelection</code> specifying a Swedish personal identity number (personnummer) as match attribute.</p>
 <pre class="hljs"><code>...
 <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.29.4.13"</span>&gt;</span>198906059483<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.201.3.4"</span>&gt;</span>NO:05068907693<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">psc:PrincipalSelection</span> <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span>&gt;</span>198906059483<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.4&quot;</span>&gt;</span>NO:05068907693<span class="hljs-tag">&lt;/<span class="hljs-name">psc:MatchValue</span>&gt;</span>
   <span class="hljs-tag">&lt;/<span class="hljs-name">psc:PrincipalSelection</span>&gt;</span>
 <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Extensions</span>&gt;</span>
 ...</code></pre><p>Example of a <code>PrincipalSelection</code> specifying two alternative matching policies. The first policy specifies a Swedish personal identity number (personnummer) and the second specifies a ProvisionalID attribute.</p>
 <p><a name="metadata-extension"></a></p>
-<h3 id="3.2.-metadata-extension">3.2. Metadata Extension</h3>
+<h3 id="32-metadata-extension">3.2. Metadata Extension</h3>
 <pre class="hljs"><code>...
-<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">"true"</span>
-     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:protocol"</span>&gt;</span>
+<span class="hljs-tag">&lt;<span class="hljs-name">md:IDPSSODescriptor</span> <span class="hljs-attr">WantAuthnRequestsSigned</span>=<span class="hljs-string">&quot;true&quot;</span>
+     <span class="hljs-attr">protocolSupportEnumeration</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:protocol&quot;</span>&gt;</span>
   <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:ui"</span>&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">mdui:UIInfo</span> <span class="hljs-attr">xmlns:mdui</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:ui&quot;</span>&gt;</span>
       ...
     <span class="hljs-tag">&lt;/<span class="hljs-name">mdui:UIInfo</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">psc:RequestedPrincipalSelection</span>
-         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oid:1.2.752.29.4.13"</span> /&gt;</span>
+    <span class="hljs-tag">&lt;<span class="hljs-name">psc:RequestedPrincipalSelection</span> 
+         <span class="hljs-attr">xmlns:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;</span>
+      <span class="hljs-tag">&lt;<span class="hljs-name">psc:MatchValue</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.29.4.13&quot;</span> /&gt;</span>
     <span class="hljs-tag">&lt;/<span class="hljs-name">psc:RequestedPrincipalSelection</span>&gt;</span>
   <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">"signing"</span>&gt;</span>
+  <span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;signing&quot;</span>&gt;</span>
     ...</code></pre><p>Example of how an Identity Provider advertises, it its metadata, that it wishes to receive the Swedish personal identity number (personnummer) of the user in a <code>&lt;PrincipalSelection&gt;</code> extension element of the authentication request if this information is known to the requestor.</p>
 <p><a name="schemas"></a></p>
-<h2 id="4.-schemas">4. Schemas</h2>
+<h2 id="4-schemas">4. Schemas</h2>
 <p>The following XML schema defines the <code>http://id.swedenconnect.se/authn/1.0/principal-selection/ns</code> namespace:</p>
-<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">"1.0"</span> encoding=<span class="hljs-string">"UTF-8"</span>?&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">"http://www.w3.org/2001/XMLSchema"</span> elementFormDefault=<span class="hljs-string">"qualified"</span>
-  targetNamespace=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>
-  xmln<span class="hljs-variable">s:psc</span>=<span class="hljs-string">"http://id.swedenconnect.se/authn/1.0/principal-selection/ns"</span>&gt;
+<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
+&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
+  targetNamespace=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>
+  xmln<span class="hljs-variable">s:psc</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/principal-selection/ns&quot;</span>&gt;
 
   &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
     &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
       Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/authn/<span class="hljs-number">1.0</span>/PrincipalSelection-<span class="hljs-number">1.0</span>.xsd
     &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"PrincipalSelection"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:PrincipalSelectionType"</span> /&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"PrincipalSelectionType"</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;PrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;PrincipalSelectionType&quot;</span>&gt;
     &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"MatchValue"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:MatchValueType"</span> minOccurs=<span class="hljs-string">"1"</span> maxOccurs=<span class="hljs-string">"unbounded"</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;MatchValue&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:MatchValueType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span> /&gt;
     &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequestedPrincipalSelection"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"psc:RequestedPrincipalSelectionType"</span> /&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"RequestedPrincipalSelectionType"</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelection&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;psc:RequestedPrincipalSelectionType&quot;</span> /&gt;
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;RequestedPrincipalSelectionType&quot;</span>&gt;
     &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"psc:PrincipalSelectionType"</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;psc:PrincipalSelectionType&quot;</span> /&gt;
     &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexContent</span>&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"MatchValueType"</span>&gt;
+  
+  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MatchValueType&quot;</span>&gt;
     &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"NameFormat"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:anyURI"</span>
-            default=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span> /&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"Name"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> use=<span class="hljs-string">"required"</span> /&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">"##any"</span> /&gt;
+      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;NameFormat&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:anyURI&quot;</span> 
+            default=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;Name&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span> /&gt;
+        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> /&gt;
       &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
     &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
   &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
+  
 &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
-<h2 id="5.-normative-references">5. Normative References</h2>
+<h2 id="5-normative-references">5. Normative References</h2>
 <p><a name="rfc2119"></a>
 <strong>[RFC2119]</strong></p>
 <blockquote>
@@ -227,7 +227,7 @@ <h2 id="5.-normative-references">5. Normative References</h2>
 <p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
 </blockquote>
 <p><a name="changes-between-versions"></a></p>
-<h2 id="6.-changes-between-versions">6. Changes between versions</h2>
+<h2 id="6-changes-between-versions">6. Changes between versions</h2>
 <p>This is the first version of this specification.</p>
     </article>
   </body>
diff --git a/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html b/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html
deleted file mode 100644
index 1777146..0000000
--- a/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html
+++ /dev/null
@@ -1,530 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Introduction to the Swedish eID Framework</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="introduction-to-the-swedish-eid-framework">Introduction to the Swedish eID Framework</h1>
-<h3 id="2022-10-05">2022-10-05</h3>
-<p>Registration number: <strong>2019-267</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2022. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#overview">Overview</a></p>
-<p> 1.2. <a href="#the-assurance-framework-and-levels-of-assurance">The Assurance Framework and Levels of Assurance</a></p>
-<p> 1.3. <a href="#service-for-collection-administration-and-publishing-of-metadata">Service for Collection, Administration and Publishing of Metadata</a></p>
-<p> 1.4. <a href="#discovery-service">Discovery Service</a></p>
-<p> 1.5. <a href="#relying-party-integration">Relying Party Integration</a></p>
-<p> 1.6. <a href="#signatures">Signatures</a></p>
-<p> 1.7. <a href="#the-technical-framework-and-eidas">The Technical Framework and eIDAS</a></p>
-<p> 1.7.1. <a href="#foreign-eid-authentication">Foreign eID Authentication</a></p>
-<p> 1.7.2. <a href="#signing-using-a-foreign-eid">Signing using a Foreign eID</a></p>
-<p> 1.7.3. <a href="#handling-of-identities">Handling of Identities</a></p>
-<p> 1.7.4. <a href="#swedish-eids-in-foreign-services">Swedish eID:s in Foreign Services</a></p>
-</li>
-<li><p><a href="#technical-specifications"><strong>Technical Specifications</strong></a></p>
-<p> 2.1. <a href="#saml-profiles">SAML Profiles</a></p>
-<p> 2.1.1. <a href="#deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</a></p>
-<p> 2.1.2. <a href="#swedish-eid-framework-registry-for-identifiers">Swedish eID Framework - Registry for identifiers</a></p>
-<p> 2.1.3. <a href="#attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</a></p>
-<p> 2.1.4. <a href="#entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</a></p>
-<p> 2.1.5. <a href="#eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a></p>
-<p> 2.1.6. <a href="#bankid-profile">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a></p>
-<p> 2.1.7. <a href="#principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</a></p>
-<p> 2.2. <a href="#signature-specifications">Signature Specifications</a></p>
-<p> 2.2.1. <a href="#implementation-profile-oasis-dss">Implementation Profile for using OASIS DSS in Central Signing Services</a></p>
-<p> 2.2.2. <a href="#dss-extensions">DSS Extension for Federated Central Signing Services</a></p>
-<p> 2.2.3. <a href="#certificate-profile-css">Certificate Profile for Certificates Issued by Central Signing Services</a></p>
-<p> 2.2.4. <a href="#signature-activation">Signature Activation Protocol for Federated Signing</a></p>
-</li>
-<li><p><a href="#references"><strong>References</strong></a></p>
-<p> 3.1. <a href="#digg">DIGG</a></p>
-<p> 3.2. <a href="#other-references">Other References</a></p>
-</li>
-</ol>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p><a name="overview"></a></p>
-<h3 id="1.1.-overview">1.1. Overview</h3>
-<p>The Swedish eID Framework (Sweden Connect Technical Framework) is adapted for identity federations based on SAML 2.0.</p>
-<p>Relying parties receive identity assertions in a standardized format
-from an identity provider.</p>
-<p>Service providers that require electronic signatures do not need to be adapted to different
-signature techniques based on different types of eID:s. Instead, a service provider makes 
-use of a signature service where users with the support of authenticating at an identity 
-provider are given the possibility to sign digital documents.</p>
-<p>Within the federation, e-services and relying parties are taking the roles of 
-Service Providers (SP), and authenticating services issuing identity assertions assume 
-the roles of Identity Providers (IdP).</p>
-<p>In cases where the service provider needs more information about the user, for example its
-legal authority, an attribute service (<em>Attribute Authority</em>) within the federation can be queried, if such a service exists. Through an attribute 
-request a service provider can obtain the necessary supplementary information in order to
-authorize the user and provide access to its service.</p>
-<p>As both personal identity information and other attributes linked to
-users are provided through identity assertions, all types of eID:s that have 
-an identity provider within the federation can be used by a service provider
-that requires specific identity attributes, even if a particular eID does not
-hold this information.</p>
-<p class="img-container"><img src="img/sweeid-overview1-en.png" alt=""></p>
-<p>Figure 1: <em>Illustration of the communication between the different services within an identity federation.</em></p>
-<p><a name="the-assurance-framework-and-levels-of-assurance"></a></p>
-<h3 id="1.2.-the-assurance-framework-and-levels-of-assurance">1.2. The Assurance Framework and Levels of Assurance</h3>
-<p>The basis for the level of security applied when a user authenticates is the 
-<em>level of assurance</em> for the eID required by the service provider. In order for
-these levels to be comparable within the federation, four assurance levels are defined (1 to
- 4) in the Swedish eID Assurance Framework [<a href="#eidtillit">EidTillit</a>] and three
-assurance levels (low, substantial, high) are defined by the EU regulation eIDAS. 
-Any service issuing identity assertions must prove that the process of issuing
-identity assertions meets the requirements of a given level. This includes:</p>
-<ul class="list">
-<li><p>Requirements for the creation of an identity assertion.</p>
-</li>
-<li><p>Requirements for electronic authentication.</p>
-</li>
-<li><p>Requirements for the issuing process.</p>
-</li>
-<li><p>Requirements for the actual eID and its use.</p>
-</li>
-<li><p>Requirements on the issuer of the eID.</p>
-</li>
-<li><p>Requirements for establishing the identity of the eID applicant.</p>
-</li>
-</ul>
-<p><a name="service-for-collection-administration-and-publishing-of-metadata"></a></p>
-<h3 id="1.3.-service-for-collection,-administration-and-publishing-of-metadata">1.3. Service for Collection, Administration and Publishing of Metadata</h3>
-<p>A SAML federation provides information about the federation
-participants through SAML metadata. Participants of a federation comprises of
-services providing identity and attributes assertions and relying parties, i.e., 
-service providers that consume these services.</p>
-<p>Through the federation&#39;s metadata, participants obtain information about others
-participants&#39; services, including the information required for a safe
-exchange of information between services. Metadata needs to be updated
-by each party and conform to agreed conditions.</p>
-<p>The main purpose of metadata is to provide the keys/certificates
-required for secure communication and information exchange between services.
-In addition to keys, metadata also contain other important information
-for collaboration between services, for example, addresses of required functions,
-information on assurance levels, service categories, user interface information, etc.</p>
-<p>An identity federation is defined by a register in XML format that is
-signed with the federation operator certificate. The file contains
-information on identity federation members including their
-certificates. Because the metadata file is signed, it is sufficient to
-compare a certificate with its equivalent in metadata. An
-infrastructure based on a central federation register requires
-that the register is constantly updated and that the members of the federation
-always use the latest version of the file.</p>
-<p><a name="discovery-service"></a></p>
-<h3 id="1.4.-discovery-service">1.4. Discovery Service</h3>
-<p>Within an identity federation, it is possible to offer and consume a common
-Discovery Service, that lists which identity providers (or eID:s) that are 
-available for a user to choose from to authenticate. The purpose of such a
-service is to relieve the individual service providers that are part of the 
-identity federation from implementing support for how users choose how to
-authenticate.</p>
-<p>By making the discovery service available within the identity federation,
-service providers may direct its users there for the choice of how to authenticate.
-The discovery service interacts with the user who makes the choice and is
-directed back to the service provider, along with the selected authentication choice. 
-The service provider now knows to which identity provider the user should be directed
-to for authentication.</p>
-<blockquote>
-<p>Currently, there is no common discovery service available within the Sweden Connect federation.</p>
-</blockquote>
-<p><a name="relying-party-integration"></a></p>
-<h3 id="1.5.-relying-party-integration">1.5. Relying Party Integration</h3>
-<p>Relying parties, e.g., service providers, integrate towards identity providers using
-standardized messages and consume identity assertions that also have a standardized
-format.</p>
-<p>The Swedish eID Framework is influenced by the interoperability profile
-”SAML V2.0 Deployment Profile for Federation Interoperability”
-[<a href="#saml2int">SAML2Int</a>]. This profile is supported by several commercial
-products and vendors as well as open source libraries. This facilitates
-the integration at the relying party side.</p>
-<p>Most relying parties use stand-alone authentication servers which means that
-the integration adaptation for supporting the Swedish eID Framework usually
-is limited to the authentication solution used.</p>
-<p><a name="signatures"></a></p>
-<h3 id="1.6.-signatures">1.6. Signatures</h3>
-<p>The Swedish eID Framework enables digital signatures using any type of eID, even
-those not based on certificates, as long as there is an identity provider for 
-the particular eID. The reason for this is that the identity assertion that is
-used during authentication for signature is standardized.</p>
-<p>A Signature Service has as its purpose to offer digital signature services
-within identity federations that follows the Swedish eID Framework.</p>
-<p>By procuring<sup>1</sup> and introducing a signature service, a relying party within the 
-federation can offer users to sign electronic documents with the support
-of the signature service. The user signature, and associated signature certificate,
-is created by the signature service after the user has accepted to sign the
-document by authenticating for the signature service<sup>2</sup>.</p>
-<blockquote>
-<p>[1]: It is also possible for a relying party to implement a signature service based on the specifications.</p>
-<p>[2]: It is important to point out that it is of the utmost importance that the user 
-experiences that he or she is signing a document. Therefore, a signature flow should be 
-used for the eID types that support this during &quot;authentication for signature&quot;.</p>
-</blockquote>
-<p><a name="the-technical-framework-and-eidas"></a></p>
-<h3 id="1.7.-the-technical-framework-and-eidas">1.7. The Technical Framework and eIDAS</h3>
-<p>The EU regulation (<a href="https://ec.europa.eu/futurium/en/system/files/ged/eidas_regulation.pdf">910/2014</a>)
-on electronic identification and trust services, eIDAS, places demands on Swedish 
-public bodies to recognize the eID:s that other eIDAS countries have notified. 
-This means that a public Swedish e-service based on certain rules must be able
-to accept a login that is performed with an eID issued in another country.</p>
-<p><a name="foreign-eid-authentication"></a></p>
-<h4 id="1.7.1.-foreign-eid-authentication">1.7.1. Foreign eID Authentication</h4>
-<p>The eIDAS technical specifications is built, as for the Swedish eID
-Framework, upon SAML standards and profiles, and even though the
-similarities are many, there are also differences between the specifications.
-However, a Swedish service provider does not have top directly relate to
-the eIDAS specifications. The figure below illustrates how the Swedish
-eIDAS node (<em>eIDAS connector</em>) acts as a proxy between other countries
-and the Swedish federation when a person is authenticated using a foreign
-eID at a Swedish service provider.</p>
-<p class="img-container"><img src="img/eidas-flow-en.png" alt=""></p>
-<p>The flow is as follows:</p>
-<ol class="list">
-<li><p>A user with a foreign eID requests access to a Swedish service provider (i.e., wants to log in).</p>
-</li>
-<li><p>The service provider lets the user select the login method using a
-discovery service. In this case the user chooses the &quot;Foreign eID&quot; option.</p>
-</li>
-<li><p>The service provider creates an authentication request according to
-the Swedish eID Framework and directs the user to the Swedish eIDAS
-node (<em>connector</em>). The eIDAS node acts as an identity provider within
-the federation, which implies that the interaction with this service is
-performed in the same way as for other identity providers that comply
-with the Swedish eID Framework.</p>
-</li>
-<li><p>The received request is processes and the eIDAS node displays a page
-where the user chooses his or hers country<sup>1</sup>. The Swedish
-eIDAS node now transforms the received authentication request into an
-authentication request according to the eIDAS format, and directs the
-user to the selected country&#39;s <em>eIDAS Proxy Service</em>.</p>
-</li>
-<li><p>When the authentication request is processed by the eIDAS proxy service
-of the selected country, this country&#39;s technique for authentication will
-be used. Not all countries within eIDAS use SAML for authentication, but
-if that was the case in our example, the user would be directed to a
-national identity provider, and before that, maybe also a discovery service
-where the eID to use would be selected.</p>
-</li>
-<li><p>When the user has authenticated an identity assertion, according to the
-eIDAS specifications, is created. This assertion contains eIDAS specific
-attribute that identify the user. This assertion is now posted back to the 
-Swedish eIDAS node.</p>
-</li>
-<li><p>The node receives the assertion and validates its validity. The assertion is
-transformed from eIDAS format to an assertion according to the Swedish eID Framework
-and is posted back to the service provider.</p>
-</li>
-<li><p>The service provider may now complement the data with additional information
-in order to decide whether the user should be granted access to the service.</p>
-</li>
-</ol>
-<p>Thus, Swedish services only have to implement support according to the Swedish eID
-Framework also when authenticating foreign users. However, in order for the service
-to fully accept the authenticated user it must also be able to handle the identity 
-presented, and this is most likely not a  Swedish personal identity number. See further
-section 1.7.3 below.</p>
-<blockquote>
-<p>[1]: The correct way to describe this would be to ask the user to which eIDAS Proxy
-Service to send the request to. This is dependent on the nationality of the user&#39;s
-eID issuer.</p>
-</blockquote>
-<p><a name="signing-using-a-foreign-eid"></a></p>
-<h4 id="1.7.2.-signing-using-a-foreign-eid">1.7.2. Signing using a Foreign eID</h4>
-<p>As already described, a model for digital signatures named &quot;federated signatures&quot;
-is used within the context of the Swedish eID Framework. A server based signature
-service is associated with the e-service that is the requestor of signatures.
-When a user signs a document the e-service directs the user along with a signature 
-request to the signature service. The signature service now requests that the
-user authenticate (at an identity provider). In conjunction with the authentication
-the user approves the signature. The signature service then sends the user back to
-the e-service along with the signature data, and the e-service stores the signature
-as a signed document.</p>
-<p>This procedure makes it possible for Swedish e-services to offer signing för users
-having foreign eID:s, since a signature service can choose to authenticate the user
-having a foreign eID in accordance with the process described in section 1.7.1 above.</p>
-<p>In this case, the Swedish eIDAS node is responsible of informing the user that
-the purpose of the authentication is to approve the signature of a document,
-and displays information about the requestor of the signature and information
-about what is being signed. When the user has authenticated an identity assertion
-is issued and sent back to the signature service who now generates the signature.</p>
-<p><a name="handling-of-identities"></a></p>
-<h4 id="1.7.3.-handling-of-identities">1.7.3. Handling of Identities</h4>
-<p>Identity assertions from other countries follow common technical
-specifications within the framework of the eIDAS regulations. These
-specifications define a <em>Minimum Dataset</em> (MDS) which is the a set of
-attributes that every country must supply for authenticated users and 
-legal entities. Each country must provide an unique identifier per eID
-that represents a natural person. For some countries, these identifiers
-will be unique and persistent per person in the same way as a Swedish
-personal identity number is, but identifiers may have different compositions
-and properties. A property that may vary is the persistence of an
-person identifier, i.e., whether such an identifier is unchanged during
-a person&#39;s lifetime, or whether it is changed because the user moves to
-another region, changes name, or simply obtains a new eID. For some
-countries (for example, Great Britain) the identifier will be different
-depending on which of the country&#39;s eID:s that user is currently using.</p>
-<p>In order to simplify the handling of users and identities in Swedish services
-the Swedish eIDAS node generates a standardized identity attribute for
-users that have been authenticated using a foreign eID, a so called 
-<em>Provisional ID</em> (PRID). The eIDAS node will also create an attribute
-that declares which persistence, or lifetime, the PRID attribute has.
-The PRID attribute is generated based on attributes values received from
-the foreign authentication according to specific methods for each country.
-Every combination of country and method a graded based on expected persistence,
-i.e., how likely it is that an identity for a person is changed over time.
-This makes it possible for Swedish services to customize the communication
-with the user and to proactively provide features for a user whose identity
-has changed, and make it possible for this user to access his or hers account.</p>
-<p>In some cases, a person that has been authenticated using a foreign eID may
-hold a Swedish personal identity number. It can, for example, be a Swedish
-citizen that has moved abroad and obtained a foreign eID, or a foreign
-citizen that is, or has been, registered (folkbokförd) in Sweden and has been
-assigned a Swedish personal identity number.</p>
-<p>The fact that a person holding a foreign eID possesses a Swedish personal identity
-number is normally not known to the foreign identity provider, and this information
-will not be part of the identity assertion from the foreign country. However, the
-Swedish eIDAS node has the possibility to query an attribute authority in Sweden<sup>1</sup>
-whether there exists a registered Swedish personal identity number for the person
-being authenticated, and may, if this is the case, add this information to the identity
-assertion that is sent back to the Swedish service provider.</p>
-<blockquote>
-<p>[1]: At the time of writing there is no attribute authority available
-providing Swedish personal identity numbers based on eIDAS attributes.</p>
-</blockquote>
-<p><a name="swedish-eids-in-foreign-services"></a></p>
-<h4 id="1.7.4.-swedish-eid:s-in-foreign-services">1.7.4. Swedish eID:s in Foreign Services</h4>
-<p>Sweden has notified Swedish eID:s according to the assurance levels substantial and high. </p>
-<p>A request for authentication from a foreign service provider is sent to the Swedish 
-eIDAS node (<em>eIDAS proxy service</em>) via an eIDAS connector in the service provider country. 
-At the Swedish eIDAS node, the user chooses which Swedish eID he or she wants to use 
-to authenticate, and an authentication request is sent to the identity provider that
-offers authentication for the selected eID. This request is according to the Swedish
-eID Framework which means that a Swedish identity provider does not have to conform to
-the eIDAS technical specifications.</p>
-<p>The user is authenticated by the Swedish identity provider and an identity assertion
-is issued (according to the Swedish eID Framework). This assertion is received by the
-Swedish eIDAS node (proxy service), and transformed to an assertion according to the
-eIDAS specifications before being sent to the foreign eIDAS connector, and then to the
-initiating foreign service provider.</p>
-<p><a name="technical-specifications"></a></p>
-<h2 id="2.-technical-specifications">2. Technical Specifications</h2>
-<p>This chapter contains specifications and profiles for identity federations and 
-related services that conforms to the Swedish eID Framework (Sweden Connect 
-Technical Framework). These documents are normative for the delivery of services 
-within identity federations that implement the Swedish eID Framework, unless 
-otherwise stated.</p>
-<p><a name="saml-profiles"></a></p>
-<h3 id="2.1.-saml-profiles">2.1. SAML Profiles</h3>
-<p>Identity federations conforming to the Swedish eID Framework are built around
-”Deployment Profile for the Swedish eID Framework”, [<a href="#eidprofile">EidProfile</a>].
-This profile is influenced by, but not normatively dependent on, ”SAML V2.0 Deployment Profile for Federation Interoperability” [<a href="#saml2int">SAML2Int</a>]. [<a href="#eidprofile">EidProfile</a>] also contains rules and guidelines specific for the Swedish eID Framework.</p>
-<p><a name="deployment-profile-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.1.-deployment-profile-for-the-swedish-eid-framework">2.1.1. Deployment Profile for the Swedish eID Framework</h4>
-<p>The ”Deployment Profile for the Swedish eID Framework” specification, [<a href="#eidprofile">EidProfile</a>], 
-is the main specification of the eID Framework and comprises of:</p>
-<ul class="list">
-<li><p>How SAML metadata is constructed and interpreted.</p>
-</li>
-<li><p>How the format of an authentication request should be compiled.</p>
-</li>
-<li><p>How an authentication request should be processed, and how an identity assertion should be constructed, verified and processed.</p>
-</li>
-<li><p>Security requirements.</p>
-</li>
-<li><p>Specific SAML requirements for signature services and &quot;authentication for signature&quot;.</p>
-</li>
-</ul>
-<p><a name="swedish-eid-framework-registry-for-identifiers"></a></p>
-<h4 id="2.1.2.-swedish-eid-framework---registry-for-identifiers">2.1.2. Swedish eID Framework - Registry for identifiers</h4>
-<p>The implementation of an infrastructure for Swedish eID:s demand different forms
-of identifiers to represent objects in data structures. The document
-”Swedish eID Framework - Registry for identifiers”, [<a href="#eidregistry">EidRegistry</a>],
-defines the structure for identifiers that are assigned within the scope of
-the Swedish eID Framework, and contains a registry of defined identifiers.</p>
-<p><a name="attribute-specification-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.3.-attribute-specification-for-the-swedish-eid-framework">2.1.3. Attribute Specification for the Swedish eID Framework</h4>
-<p>The specification ”Attribute Specification for the Swedish eID Framework”,
-[<a href="#eidattributes">EidAttributes</a>], declares the SAML attribute profiles
-that are used within identity federations that follow the Swedish eID
-Framework, including services that connect to eIDAS using the Swedish eID
-node.</p>
-<p><a name="entity-categories-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.4.-entity-categories-for-the-swedish-eid-framework">2.1.4. Entity Categories for the Swedish eID Framework</h4>
-<p>Entity Categories are used within the federation for different purposes:</p>
-<ul class="list">
-<li><p>Service Entity Categories – Are used in metadata to represent service
-provider requirements regarding assurance levels and attributes,
-and identity provider declarations for supported assurance levels
-and attribute release capabilities.</p>
-</li>
-<li><p>Service Property Categories – Are used to represent certain properties
-of services within the federation.</p>
-</li>
-<li><p>Service Type Entity Categories – Represents different service types
-within the federation.</p>
-</li>
-<li><p>Service Contract Entity Categories - Are used by services to declare
-legal and business agreements.</p>
-</li>
-<li><p>General Entity Categories - Entity categories that do not fall within
-the scope of any of the other types.</p>
-</li>
-</ul>
-<p>The specification ”Entity Categories for the Swedish eID Framework”
-[<a href="#eidentcat">EidEntCat</a>] specifies the entity categories that are defined in
-the Swedish eID Framework and describes their meaning.</p>
-<p><a name="eidas-constructed-attributes-specification-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.5.-eidas-constructed-attributes-specification-for-the-swedish-eid-framework">2.1.5. eIDAS Constructed Attributes Specification for the Swedish eID Framework</h4>
-<p>The specification ”eIDAS Constructed Attributes Specification for the Swedish
-eID Framework”, [<a href="#eidconstrattributes">EidConstrAttributes</a>], defines processes and
-rules for how an identity attribute are constructed based on the attributes that are
-received during an eIDAS authentication.</p>
-<p><a name="bankid-profile"></a></p>
-<h4 id="2.1.6.-implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">2.1.6. Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h4>
-<p>The specification &quot;Implementation Profile for BankID Identity Providers within the Swedish eID Framework&quot;, [<a href="#eidbankid">EidBankID</a>], defines rules for identity providers that implement
-support for the Swedish BankID eID.</p>
-<blockquote>
-<p><strong>Note:</strong> This specification is not normative for conformance to the Swedish eID Framework.
-It is only relevant for identity providers implementing support for BankID and for service
-providers using those identity providers. However, an identity provider that implements BankID and wants to join the Sweden Connect federation must follow this specification.</p>
-</blockquote>
-<p><a name="principal-selection-in-saml-authentication-requests"></a></p>
-<h4 id="2.1.7.-principal-selection-in-saml-authentication-requests">2.1.7. Principal Selection in SAML Authentication Requests</h4>
-<p>The specification &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#eidprincipalsel">EidPrincipalSel</a>], defines an extension to SAML making it possible for a relying party
-to inform an identity provider about the identity of the user that it wishes to be authenticated.</p>
-<p><a name="signature-specifications"></a></p>
-<h3 id="2.2.-signature-specifications">2.2. Signature Specifications</h3>
-<p>This section contains references to the documents that define signature services
-within federations conformant to the Swedish eID Framework.</p>
-<p><a name="implementation-profile-oasis-dss"></a></p>
-<h4 id="2.2.1.-implementation-profile-for-using-oasis-dss-in-central-signing-services">2.2.1. Implementation Profile for using OASIS DSS in Central Signing Services</h4>
-<p>The implementation profile ”Implementation Profile for Using OASIS DSS in
-Central Signing Services”, [<a href="#eiddssprofile">EidDSSProfile</a>], specifies a profile
-for signature requests and responses according to the OASIS standard
-”Digital Signature Service Core Protocols, Elements, and Bindings”,
-[<a href="#dss">DSS</a>].</p>
-<p><a name="dss-extensions"></a></p>
-<h4 id="2.2.2.-dss-extension-for-federated-central-signing-services">2.2.2. DSS Extension for Federated Central Signing Services</h4>
-<p>”DSS Extension for Federated Central Signing Services”, [<a href="#eiddssext">EidDSSExt</a>], is an
-extension to the OASIS standard ”Digital Signature Service Core Protocols, Elements, and Bindings”, [<a href="#dss">DSS</a>], where definitions required for signatures according to the Swedish 
-eID Framework are specified.</p>
-<p><a name="certificate-profile-css"></a></p>
-<h4 id="2.2.3.-certificate-profile-for-certificates-issued-by-central-signing-services">2.2.3. Certificate Profile for Certificates Issued by Central Signing Services</h4>
-<p>The certificate profile ”Certificate profile for certificates issued by Central Signing services”, [<a href="#eidcertprof">EidCertProf</a>], specifies the contents of a signature certificate. This profile
-defines a certificate extension for use by signature services.</p>
-<p>This profile refers to &quot;Authentication Context Certificate Extension&quot;, [<a href="#authcontext">AuthContext</a>], 
-that describes how an ”Authentication Context” is represented in X.509 certificates.</p>
-<p><a name="signature-activation"></a></p>
-<h4 id="2.2.4.-signature-activation-protocol-for-federated-signing">2.2.4. Signature Activation Protocol for Federated Signing</h4>
-<p>The specification &quot;Signature Activation Protocol for Federated Signing&quot;, [<a href="#eidsigact">EidSigAct</a>], 
-defines a &quot;Signature Activation Protocol&quot; (SAP) for implementation of &quot;Sole Control Assurance Level 2&quot; (SCAL2) according to the standard &quot;prEN 419241 - Trustworthy Systems Supporting Server Signing&quot;.</p>
-<p><a name="references"></a></p>
-<h2 id="3.-references">3. References</h2>
-<p><a name="digg"></a></p>
-<h3 id="3.1.-digg">3.1. DIGG</h3>
-<p><a name="eidtillit"></a>
-<strong>[EidTillit]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digital-identitet/e-legitimering/tillitsnivaer/tillitsramverket">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="eidprofile"></a>
-<strong>[EidProfile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidentcat"></a>
-<strong>[EidEntCat]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidconstrattributes"></a>
-<strong>[EidConstrAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID
-Framework</a>.</p>
-</blockquote>
-<p><a name="eidbankid"></a>
-<strong>[EidBankID]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidprincipalsel"></a>
-<strong>[EidPrincipalSel]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
-</blockquote>
-<p><a name="eiddssprofile"></a>
-<strong>[EidDSSProfile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing
-Services</a>.</p>
-</blockquote>
-<p><a name="eiddssext"></a>
-<strong>[EidDSSExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="eidcertprof"></a>
-<strong>[EidCertProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing
-services</a>.</p>
-</blockquote>
-<p><a name="eidsigact"></a>
-<strong>[EidSigAct]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="other-references"></a></p>
-<h3 id="3.2.-other-references">3.2. Other references</h3>
-<p><a name="saml2int"></a>
-<strong>[SAML2Int]</strong></p>
-<blockquote>
-<p><a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML V2.0 Deployment Profile for Federation Interoperability</a>.</p>
-</blockquote>
-<p><a name="dss"></a>
-<strong>[DSS]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc">OASIS Standard – Digital Signature Service Core Protocols, Elements,
-and Bindings Version 1.0, April 11,
-2007</a>.</p>
-</blockquote>
-<p><a name="authcontext"></a>
-<strong>[AuthContext]</strong></p>
-<blockquote>
-<p><a href="https://tools.ietf.org/html/rfc7773">RFC-7773: Authentication Context Certificate Extension</a>.</p>
-</blockquote>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html b/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html
new file mode 120000
index 0000000..add31a8
--- /dev/null
+++ b/docs/updates/00_-_Swedish_eID_Framework_-_Introduction.html
@@ -0,0 +1 @@
+../december-2024/00_-_Swedish_eID_Framework_-_Introduction.html
\ No newline at end of file
diff --git a/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html b/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html
deleted file mode 100644
index 3c53237..0000000
--- a/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html
+++ /dev/null
@@ -1,548 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>En introduktion till Sweden Connect Tekniskt ramverk</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="en-introduktion-till-sweden-connect-tekniskt-ramverk">En introduktion till Sweden Connect Tekniskt ramverk</h1>
-<h3 id="2022-10-05">2022-10-05</h3>
-<p>Diarienummer: <strong>2019-267</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">Myndigheten för digital förvaltning (DIGG)</a>, 2015-2022.
-</p>
-
-<h2 id="innehållsförteckning">Innehållsförteckning</h2>
-<ol class="list">
-<li><p><a href="#introduktion"><strong>Introduktion</strong></a></p>
-<p> 1.1. <a href="#oeversikt">Översikt</a></p>
-<p> 1.2. <a href="#tillitsramverk-och-saekerhetsnivaaer">Tillitsramverk och säkerhetsnivåer</a></p>
-<p> 1.3. <a href="#tjaenst-foer-insamling-administration-och-publicering-av-metadata">Tjänst för insamling, administration och publicering av metadata</a></p>
-<p> 1.4. <a href="#anvisningstjaenst">Anvisningstjänst</a></p>
-<p> 1.5. <a href="#integration-hos-foerlitande-part">Integration hos förlitande part</a></p>
-<p> 1.6. <a href="#underskrift">Underskrift</a></p>
-<p> 1.7. <a href="#tekniskt-ramverk-och-eidas">Tekniskt ramverk och eIDAS</a></p>
-<p> 1.7.1. <a href="#autentiseringar-med-utlaendska-e-legitimationer">Autentiseringar med utländska e-legitimationer</a></p>
-<p> 1.7.2. <a href="#underskrifter-med-utlaendska-e-legitimationer">Underskrifter med utländska e-legitimationer</a></p>
-<p> 1.7.3. <a href="#hantering-av-identiteter">Hantering av identiteter</a></p>
-<p> 1.7.4. <a href="#svenska-e-legitimationer-i-utlaendska-e-tjaenster">Svenska e-legitimationer i utländska e-tjänster</a></p>
-</li>
-<li><p><a href="#tekniska-specifikationer"><strong>Tekniska specifikationer</strong></a></p>
-<p> 2.1. <a href="#saml-profiler">SAML-profiler</a></p>
-<p> 2.1.1. <a href="#deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</a></p>
-<p> 2.1.2. <a href="#swedish-eid-framework-registry-for-identifiers">Swedish eID Framework - Registry for identifiers</a></p>
-<p> 2.1.3. <a href="#attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</a></p>
-<p> 2.1.4. <a href="#entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</a></p>
-<p> 2.1.5. <a href="#eidas-constructed-attributes-specification-for-the-swedish-eid-framework">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a></p>
-<p> 2.1.6. <a href="#bankid-profile">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a></p>
-<p> 2.1.7. <a href="#principal-selection-in-saml-authentication-requests">Principal Selection in SAML Authentication Requests</a></p>
-<p> 2.2. <a href="#specifikationer-foer-underskrift">Specifikationer för Underskrift</a></p>
-<p> 2.2.1. <a href="#implementation-profile-oasis-dss">Implementation Profile for using OASIS DSS in Central Signing Services</a></p>
-<p> 2.2.2. <a href="#dss-extensions">DSS Extension for Federated Central Signing Services</a></p>
-<p> 2.2.3. <a href="#certificate-profile-css">Certificate Profile for Certificates Issued by Central Signing Services
-</a></p>
-<p> 2.2.4. <a href="#signature-activation">Signature Activation Protocol for Federated Signing</a></p>
-</li>
-<li><p><a href="#referenslista"><strong>Referenslista</strong></a></p>
-<p> 3.1. <a href="#digg">DIGG</a></p>
-<p> 3.2. <a href="#oevriga-referenser">Övriga referenser</a></p>
-</li>
-</ol>
-<p><a name="introduktion"></a></p>
-<h2 id="1.-introduktion">1. Introduktion</h2>
-<p><a name="oeversikt"></a></p>
-<h3 id="1.1.-översikt">1.1. Översikt</h3>
-<p>Sweden Connect Tekniskt Ramverk är anpassat för
-identitetsfederationer som baseras på SAML 2.0.</p>
-<p>Förlitande parter erhåller identitetsintyg i ett standardiserat format
-från en legitimeringstjänst<sup>1</sup>.</p>
-<p>E-tjänster som kräver underskrift behöver inte anpassas efter olika 
-användares e-legitimationer för att skapa elektroniska underskrifter. 
-Istället överlåter e-tjänsten detta till en underskriftstjänst där användare 
-med stöd av legitimering via en legitimeringstjänst ges möjlighet att underteckna
-elektroniska handlingar.</p>
-<p>Inom federationen intar e-tjänster och motsvarande förlitande parter
-rollen som Service Provider (SP) medan legitimeringstjänster som
-utfärdar identitetsintyg intar rollen som Identity Provider (IdP) och
-därmed den som autentiserar användaren, oavsett mot vilken e-tjänst som
-användaren legitimerar sig.</p>
-<p>För de fall där e-tjänsten behöver mer information om användaren t ex.
-uppgift om juridisk behörighet, kan en fråga ställas till en
-attributtjänst, Attribute Authority (AA), inom federationen, om sådan
-relevant attributtjänst finns. Genom en attributsförfrågan kan
-e-tjänsten erhålla nödvändig kompletterande information för att kunna
-auktorisera användaren och ge tillgång till e-tjänsten eller
-motsvarande.</p>
-<p>Då såväl personidentitetsuppgifter som andra attribut kopplat till
-användare tillhandahålls genom identitetsintyg och attributsintyg, kan
-alla typer av e-legitimationer som förlitande part har avtal om och som
-ingår i federationen användas för legitimering mot en e-tjänst som
-kräver såväl personnummer som ytterligare information, även om 
-e-legitimationen inte innehåller några specifika personuppgifter 
-(t.ex. koddosor för generering av engångslösenord).</p>
-<p class="img-container"><img src="img/sweeid-overview1.png" alt=""></p>
-<p>Figur 1: <em>Illustration av kommunikationen mellan de olika tjänsterna inom
-en identitetsfederation.</em></p>
-<blockquote>
-<p>[1]: Legitimeringstjänst benämns i annan dokumentation från DIGG också som identitetstjänst och intygstjänst. I detta dokument används dock uteslutande benämningen legitimeringstjänst.</p>
-</blockquote>
-<p><a name="tillitsramverk-och-saekerhetsnivaaer"></a></p>
-<h3 id="1.2.-tillitsramverk-och-säkerhetsnivåer">1.2. Tillitsramverk och säkerhetsnivåer</h3>
-<p>Grunden för vilken säkerhetsnivå som tillämpas när en användare
-legitimerar sig är den tillitsnivå avseende e-legitimationen som
-e-tjänsten kräver. För att dessa säkerhetsnivåer ska kunna vara
-jämförbara inom ramen för federationen definieras fyra tillitsnivåer (1
-– 4) i Tillitsramverket för Svensk e-legitimation [<a href="#eidtillit">EidTillit</a>] och tre
-tillitsnivåer (låg, väsentlig, hög) i EU-förordningen eIDAS. Alla som
-utfärdar identitetsintyg måste visa att hela den process som ligger till
-grund för utfärdandet av identitetsintyg uppfyller kraven i den
-efterfrågade tillitsnivån, detta innefattar bl.a.</p>
-<ul class="list">
-<li><p>Krav på skapandet av identitetsintyget.</p>
-</li>
-<li><p>Krav på den elektroniska legitimeringen (autentiseringen).</p>
-</li>
-<li><p>Krav på utfärdandeprocessen.</p>
-</li>
-<li><p>Krav på själva e-legitimationen och dess användning.</p>
-</li>
-<li><p>Krav på utfärdaren av e-legitimationen.</p>
-</li>
-<li><p>Krav på fastställande av den e-legitimationssökandens identitet.</p>
-</li>
-</ul>
-<p><a name="tjaenst-foer-insamling-administration-och-publicering-av-metadata"></a></p>
-<h3 id="1.3.-tjänst-för-insamling,-administration-och-publicering-av-metadata">1.3. Tjänst för insamling, administration och publicering av metadata</h3>
-<p>En SAML-federation tillhandahåller information om federationens
-deltagare genom SAML metadata. Som deltagare i en federation räknas
-såväl aktörer som levererar legitimerings- och attributtjänster i
-federationen som förlitande parter, d.v.s. aktörer som konsumerar dessa
-tjänster, t ex. e-tjänster.</p>
-<p>Genom federationens metadata kan deltagare inhämta information om andra
-deltagares tjänster, inklusive de uppgifter som krävs för ett säkert
-informationsutbyte mellan deltagarna. Metadata måste hållas uppdaterat
-av respektive part och överensstämma med avtalade förhållanden.</p>
-<p>Det viktigaste syftet med metadata är att tillhandahålla de nycklar/certifikat 
-som krävs för säker kommunikation och informationsutväxling mellan tjänster.
-Utöver nycklar innehåller metadata även annan information som är viktig
-för samverkan mellan tjänster t ex. adresser till funktioner som krävs,
-information om tillitsnivåer, tjänstekategorier,
-användargränssnittsinformation mm.</p>
-<p>En identitetsfederation definieras av ett register i XML-format som är
-signerat med federationsoperatörens certifikat. Filen innehåller
-information om identitetsfederationens medlemmar inklusive deras
-certifikat. Eftersom filen med metadata är signerad räcker det med att
-jämföra ett certifikat med dess motsvarighet i metadata. En
-infrastruktur baserad på ett centralt federationsregister förutsätter
-att registret uppdateras kontinuerligt samt att federationsmedlemmarna
-alltid använder den senaste versionen av filen.</p>
-<p><a name="anvisningstjaenst"></a></p>
-<h3 id="1.4.-anvisningstjänst">1.4. Anvisningstjänst</h3>
-<p>I en identitetsfederation är det möjligt att erbjuda och konsumera en
-gemensam anvisningstjänst (Discovery Service), som listar vilka
-legitimeringstjänster som är möjliga för användaren att välja mellan.
-Syftet med en sådan anvisningstjänst är att avlasta de enskilda
-e-tjänsterna som ingår i identitetsfederationen från att själva
-implementera stöd för hur användare väljer legitimeringstjänst (eller
-inloggningsmetod).</p>
-<p>Genom att anvisningstjänsten finns tillgänglig inom
-identitetsfederationen kan e-tjänster styra sina användare dit för val
-av legitimeringstjänst. Anvisningstjänsten interagerar med användaren
-som gör sitt val och användaren, tillsammans med dennes val, styrs
-tillbaka till e-tjänsten som nu vet till vilken legitimeringstjänst
-användaren ska skickas för legitimering.</p>
-<blockquote>
-<p>För närvarande finns ingen gemensam anvisningstjänst för Sweden Connect-federationen.</p>
-</blockquote>
-<p><a name="integration-hos-foerlitande-part"></a></p>
-<h3 id="1.5.-integration-hos-förlitande-part">1.5. Integration hos förlitande part</h3>
-<p>Förlitandeparter, t.ex. e-tjänster, integrerar mot legitimeringstjänster
-genom standardiserade meddelanden och konsumerar identitetsintyg vilka
-också har standardiserade format.</p>
-<p>Sweden Connect tekniskt ramverk är influerad av interoperabilitetsprofilen 
-”SAML V2.0 Deployment Profile for Federation Interoperability”
-[<a href="#saml2int">SAML2Int</a>]. Profilen stöds av ett flertal kommersiella 
-produkter och Open Source-lösningar, vilket underlättar integrationsarbetet
-hos e-tjänster.</p>
-<p>Många e-tjänster använder fristående autentiseringslösningar vilket
-innebär att en anpassning av integrationen för att följa
-tekniskt ramverk får en begränsad påverkan på e-tjänsten som sådan.</p>
-<p><a name="underskrift"></a></p>
-<h3 id="1.6.-underskrift">1.6. Underskrift</h3>
-<p>Vid underskrift blir det med Sweden Connect tekniskt ramverk
-möjligt att använda olika typer av e-legitimationer, även sådana som
-inte är certifikatbaserade, utan att speciella anpassningar i e-tjänsten
-behövs. Anledningen är att det är det elektroniskt utställda
-identitetsintyget (som används för identifiering av användare vid
-underskrift) har samma format oavsett vilken typ av e-legitimation som
-användaren använder.</p>
-<p>En underskriftstjänst har som syfte att möjliggöra underskrift inom
-identitetsfederationer som följer tekniskt ramverk med stöd av alla 
-typer av e-legitimationer som erbjuder tillräcklig grad av säkerhet.</p>
-<p>Genom att upphandla<sup>1</sup> och införa en underskriftstjänst kan en förlitande
-part som ingår i federationen låta en användare skriva under en
-elektronisk handling med stöd av underskriftstjänsten.
-Användarens elektroniska signatur och tillhörande signeringscertifikat
-skapas av underskriftstjänsten efter det att användaren accepterat att
-skriva under genom att legitimera sig mot underskriftstjänsten<sup>2</sup>.</p>
-<blockquote>
-<p>[1]: Det är också möjligt att själv implementera en underskriftstjänst baserat på specifikationerna i tekniskt ramverk, eller på annat sätt införskaffa en underskriftstjänst.</p>
-<p>[2]: Viktigt att påpeka är att det är av största vikt att användaren upplever det som att denne skriver under en handling. Därför ska ett underskriftsflöde användas för de e-legitimationer som stödjer detta i samband med &quot;legitimering för underskrift&quot;.</p>
-</blockquote>
-<p><a name="tekniskt-ramverk-och-eidas"></a></p>
-<h3 id="1.7.-tekniskt-ramverk-och-eidas">1.7. Tekniskt ramverk och eIDAS</h3>
-<p>EU-förordningen (<a href="http://eur-lex.europa.eu/legal-content/SV/TXT/PDF/?uri=CELEX:32014R0910&amp;from=EN">910/2014</a>) om elektronisk identifiering och betrodda
-tjänster, eIDAS, ställer krav på svenska offentliga organ att erkänna de
-e-legitimationer som andra eIDAS-länder har anmält. Detta innebär att en
-offentlig svensk e-tjänst baserat på vissa regler skall kunna acceptera
-en inloggning som utförs med en e-legitimation utställd i ett annat
-land.</p>
-<p><a name="autentiseringar-med-utlaendska-e-legitimationer"></a></p>
-<h4 id="1.7.1.-autentiseringar-med-utländska-e-legitimationer">1.7.1. Autentiseringar med utländska e-legitimationer</h4>
-<p>De tekniska specifikationerna för eIDAS bygger, såsom
-tekniskt ramverk, på SAML-standarder, och även
-om likheterna är många finns även skillnader i dessa specifikationer. En
-svensk e-tjänst ska dock inte förhålla sig direkt till eIDAS tekniska
-specifikationer. Nedanstående bild illustrerar hur
-den svenska eIDAS-noden (<em>eIDAS-connector</em>) agerar som en brygga
-mellan andra länder och den svenska federationen då en person autentiseras
-med en utländsk e-legitimation mot en svensk e-tjänst.
-Den svenska eIDAS-noden följer tekniskt ramverk.</p>
-<p class="img-container"><img src="img/eidas-flow.png" alt=""></p>
-<p>Flödet är enligt följande:</p>
-<ol class="list">
-<li><p>En användare med en utländsk e-legitimation begär åtkomst till en
-svensk e-tjänst (d.v.s., loggar in).</p>
-</li>
-<li><p>E-tjänsten låter användaren välja inloggningssätt med hjälp av en
-anvisningstjänst. Ett val ”Foreign eID” visas upp, vilket användaren
-i eIDAS-fallet väljer.</p>
-</li>
-<li><p>E-tjänsten skapar en legitimeringsbegäran enligt detta tekniska
-ramverk och styr användaren till den svenska eIDAS-noden (<em>connector</em>)
-som DIGG ansvarar för. eIDAS-noden uppträder som
-en legitimeringstjänst (<em>Identity Provider</em>) i federationen in
-mot svenska förlitande parter vilket innebär att kommunikation med
-denna tjänst utförs på samma sätt som mot övriga
-legitimeringstjänster inom federationer som följer tekniskt ramverk.</p>
-</li>
-<li><p>Den mottagna begäran behandlas och eIDAS-noden visar upp en valsida
-där användaren väljer ”sitt land”<sup>1</sup>. Den svenska eIDAS-noden
-omvandlar nu den mottagna legitimeringsbegäran till en
-legitimeringsbegäran enligt eIDAS och användaren styrs till det
-valda landets ”eIDAS Proxy-tjänst”.</p>
-</li>
-<li><p>Då legitimeringsbegäran mottas av den eIDAS-Proxy-tjänst för valt
-land tar detta lands teknik för autentisering över. Inte alla länder
-inom eIDAS använder SAML för autentisering, men om så var fallet i
-vårt exempel skulle användaren styras vidare till en
-legitimeringstjänst (<em>Identity Provider</em>), och innan dess kanske även
-en anvisningstjänst för val av legitimeringstjänst.</p>
-</li>
-<li><p>Då en autentisering utförts skapas ett intyg (<em>Assertion</em>) enligt
-eIDAS specifikationer. Detta intyg innehåller bl.a. eIDAS-specifika
-attribut som identifierar användaren. Detta intyg styrs nu vidare till
-den svenska eIDAS-noden.</p>
-</li>
-<li><p>Noden tar emot intyget och validerar dess korrekthet. Detta intyg
-transformeras från eIDAS-format till ett intyg utformat
-enligt tekniskt ramverk och postas till e-tjänsten.</p>
-</li>
-<li><p>Förlitande part kompletterar eventuellt med ytterligare information
-och avgör om användaren ska ges till åtkomst till tjänsten.</p>
-</li>
-</ol>
-<p>Svenska e-tjänster behöver således endast stödja 
-tekniskt ramverk för att kunna hantera en autentisering utförd med en
-europeisk e-legitimation. Dock måste e-tjänsten kunna hantera den
-identitet som presenteras, vilket inte nödvändigtvis är ett personnummer. 
-Det kan alltså hända att en e-tjänst autentiserar en användare via 
-eIDAS-ramverket, men att användarens
-presenterade identitet inte går att använda hos e-tjänsten. Mer om detta
-i kapitlet 1.7.3 nedan.</p>
-<blockquote>
-<p>[1]: Egentligen väljer användaren till vilken ”eIDAS Proxy-tjänst” som begäran ska skickas vidare till. Detta är beroende landstillhörigheten för användarens e-legitimationsutfärdare.</p>
-</blockquote>
-<p><a name="underskrifter-med-utlaendska-e-legitimationer"></a></p>
-<h4 id="1.7.2.-underskrifter-med-utländska-e-legitimationer">1.7.2. Underskrifter med utländska e-legitimationer</h4>
-<p>Som redan beskrivits tillämpas en modell för
-elektronisk underskrift inom ramen för detta tekniska ramverk
-som kallas federerad underskrift. En
-serverbaserad underskriftstjänst knyts till e-tjänsten som i sin tur
-begär underskrift. När en användare skriver under ett dokument skickar
-e-tjänsten en underskriftsbegäran till underskriftstjänsten.
-Underskriftstjänsten begär därefter att användaren legitimerar sig. I
-samband med legitimeringen godkänner användaren underskriften.
-Underskriftstjänsten skickar tillbaka uppgifter till e-tjänsten och
-därefter lagras underskriftsuppgifterna kopplade till den handling som
-har skrivits under.</p>
-<p>Detta förfarande möjliggör att skriva under även med utländsk
-e-legitimation då underskriftstjänsten kan välja att legitimera
-användaren med utländsk e-legitimation i enlighet med förfarandet som
-beskrivs ovan i avsnitt 1.7.1.</p>
-<p>Vid en underskrift ansvarar i det fallet den svenska eIDAS-noden för att
-användaren upplyses om att syftet med legitimeringen är att skriva under
-ett dokument, vem som begärt underskrift samt med eventuell information
-om vad som undertecknas. Först när användaren genom att legitimera sig
-(för underskrift) utfärdas ett identitetsintyg, som skickas till
-underskriftstjänsten och som i sin tur genererar underskriften.</p>
-<p><a name="hantering-av-identiteter"></a></p>
-<h4 id="1.7.3.-hantering-av-identiteter">1.7.3. Hantering av identiteter</h4>
-<p>Identitetsintyg från andra länder följer EU-gemensamma tekniska
-specifikationer framtagna inom ramen för eIDAS-regelverket. Här
-specificeras de attribut som varje land alltid måste skicka med för
-fysiska personer såväl som för organisationer (”Minimum Dataset”, MDS).
-Varje land måste skicka med en unik identifierare per e-legitimation som
-representerar endast en fysisk person. Från vissa länder kommer dessa
-identifierare vara unika och beständiga per person på motsvarande sätt
-som t.ex. svenska personnummer, men dessa identifierare kan ha vitt
-skilda sammansättningar och ha väldigt olika egenskaper. En egenskap som
-kan variera är hur persistent en sådan identifierare är, d.v.s., om en
-sådan identifierare är oförändrad under en persons livstid eller om den
-ändras om personen exempelvis flyttar till en annan region, byter namn
-eller bara byter e-legitimation. Från några länder (t.ex.
-Storbritannien) kommer identifieraren att vara olika beroende på vilken
-av landets e-legitimationer en användare för tillfället väljer att
-använda.</p>
-<p>För att förenkla hanteringen av användare i svenska e-tjänster
-genererar den svenska eIDAS-noden ett standardiserat ID-attribut för
-användare som legitimerats med utländsk e-legitimation, ett s.k.
-<em>provisional ID</em> (förkortat PRID). Dessutom skapas ett tillhörande
-attribut som deklarerar vilken förväntad persistens, eller livslängd,
-detta ID-attribut har. PRID-attributet genereras utifrån de
-attributvärden som erhålls från den utländska legitimeringen enligt
-specificerade metoder för respektive land. Varje kombination av land och
-metod klassas med avseende på förväntad persistens, d.v.s., hur
-sannolikt det är att en identitet ändras över tiden för samma person.
-Detta gör det möjligt för svenska e-tjänster att anpassa kommunikationen
-med användaren och proaktivt tillhandahålla funktioner som underlättar
-för en användare vars identitet har ändrats, att återfå kontrollen över
-sin information i e-tjänsten.</p>
-<p>I vissa fall kan en person som legitimeras med en utländsk
-e-legitimation även inneha ett svenskt personnummer. Det kan till exempel 
-röra sig om en svensk medborgare som flyttat utomlands och skaffat utländsk e-legitimation
-eller en utländsk medborgare som är folkbokförd i Sverige och har tilldelats ett
-personnummer.</p>
-<p>Det faktum att en person med utländsk e-legitimation innehar ett svenskt
-personnummer är normalt sett inte känt för den
-utländska legitimeringstjänsten och denna information ingår därför inte
-i identitetsintyg från landet där personen legitimeras. Den svenska
-noden har däremot möjlighet att fråga en attributtjänst i Sverige<sup>1</sup> om
-det finns ett registrerat personnummer för den
-legitimerade personen och kan, om så är fallet, påföra sådan information
-i det identitetsintyg som skickas till e-tjänsten.</p>
-<blockquote>
-<p>[1]: I skrivande stund finns ingen attributtjänst som utför koppling mellan eIDAS-identiteter och svenska personnummer.</p>
-</blockquote>
-<p><a name="svenska-e-legitimationer-i-utlaendska-e-tjaenster"></a></p>
-<h4 id="1.7.4.-svenska-e-legitimationer-i-utländska-e-tjänster">1.7.4. Svenska e-legitimationer i utländska e-tjänster</h4>
-<p>Sverige har anmält svenska e-legitimationer på tillitsnivå väsentlig (substantial) och hög (high) enligt eIDAS. </p>
-<p>En begäran om legitimering från en utländsk e-tjänst ställs till den svenska eIDAS-noden (proxy-tjänst) via en s.k. eIDAS-connector i e-tjänstens land. 
-I den svenska eIDAS-noden väljer användaren med vilken svensk e-legitimation denne önskar autentisera sig, varpå en legitimeringsbegäran till den legitimeringstjänst (<em>Identity Provider</em>) som hanterar vald e-legitimation skickas. Denna begäran är utformad enligt tekniskt ramverk vilket innebär att en svensk legitimeringstjänst inte behöver förhålla sig till eIDAS tekniska specifikationer.</p>
-<p>Användaren autentiseras hos den svenska legitimeringstjänsten och ett identitetsintyg ställs ut (enligt tekniskt ramverk). Detta intyg mottas av den svenska eIDAS Proxy-tjänsten och omvandlas till ett intyg enligt eIDAS specifikationer innan det skickas vidare till den utländska eIDAS-connectorn och därpå till den anropande e-tjänsten (<em>Service Provider</em>).</p>
-<p><a name="tekniska-specifikationer"></a></p>
-<h2 id="2.-tekniska-specifikationer">2. Tekniska specifikationer</h2>
-<p>Detta kapitel innehåller specifikationer och profiler för
-identitetsfederationer som följer Sweden Connect tekniskt
-ramverk, och vissa kringliggande tjänster. Där inget annat nämns är
-dessa dokument normativa för leverans av tjänster inom
-identitetsfederationer som implementerar 
-tekniskt ramverk.</p>
-<p><a name="saml-profiler"></a></p>
-<h3 id="2.1.-saml-profiler">2.1. SAML-profiler</h3>
-<p>Identitetsfederationer som följer Sweden Connect tekniska ramverk är uppbyggda
-kring ”Deployment Profile for the Swedish eID Framework”, [<a href="#eidprofile">EidProfile</a>]. Denna profil är influerad av, men inte normativt beroende på, ”SAML V2.0 Deployment Profile for Federation Interoperability” [<a href="#saml2int">SAML2Int</a>]. [<a href="#eidprofile">EidProfile</a>] innehåller också regler och riktlinjer specifika för Sweden Connect tekniskt ramverk. </p>
-<p><a name="deployment-profile-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.1.-deployment-profile-for-the-swedish-eid-framework">2.1.1. Deployment Profile for the Swedish eID Framework</h4>
-<p>”Deployment Profile for the Swedish eID Framework”, [<a href="#eidprofile">EidProfile</a>], är huvuddokumentet för tekniskt ramverk och specificerar bland annat:</p>
-<ul class="list">
-<li><p>Hur SAML metadata ska byggas upp och tolkas.</p>
-</li>
-<li><p>Hur formatet av en legitimeringsbegäran ska se ut.</p>
-</li>
-<li><p>Hur en legitimeringsbegäran ska behandlas, och hur ett identitetsintyg ska konstrueras, verifieras och behandlas.</p>
-</li>
-<li><p>Krav på säkerhet.</p>
-</li>
-<li><p>Specifika SAML-krav för underskriftstjänster och &quot;legitimering för underskrift&quot;.</p>
-</li>
-</ul>
-<p><a name="swedish-eid-framework-registry-for-identifiers"></a></p>
-<h4 id="2.1.2.-swedish-eid-framework---registry-for-identifiers">2.1.2. Swedish eID Framework - Registry for identifiers</h4>
-<p>Implementering av en infrastruktur för Svensk e-legitimation kräver
-olika former av identifierare för att representera objekt i
-datastrukturer. Dokumentet ”Swedish eID Framework - Registry for identifiers”, [<a href="#eidregistry">EidRegistry</a>], definierar strukturen
-för identifierare som tilldelats inom ramen för tekniskt ramverk, samt ett
-register över definierade identifierare.</p>
-<p><a name="attribute-specification-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.3.-attribute-specification-for-the-swedish-eid-framework">2.1.3. Attribute Specification for the Swedish eID Framework</h4>
-<p>Specifikationen ”Attribute Specification for the Swedish eID Framework”,
-[<a href="#eidattributes">EidAttributes</a>], deklarerar de SAML attributprofiler som används inom
-identitetsfederationer som följer tekniskt ramverk inklusive de som
-ansluter till eIDAS via den svenska eIDAS-noden.</p>
-<p><a name="entity-categories-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.4.-entity-categories-for-the-swedish-eid-framework">2.1.4. Entity Categories for the Swedish eID Framework</h4>
-<p>Entitetskategorier (Entity Categories) används inom federationen för ett antal olika
-syften:</p>
-<ul class="list">
-<li><p>Service Entity Categories – Används i metadata för att
-representera e-tjänsters krav på tillitsnivåer och begärda attribut,
-samt legitimeringstjänsters uppfyllande av tillitsnivåer och
-leverans av attribut.</p>
-</li>
-<li><p>Service Property Categories – Används för att representera en viss
-egenskap hos en tjänst.</p>
-</li>
-<li><p>Service Type Entity Categories – Används för att representera olika
-tjänstetyper inom federationen.</p>
-</li>
-<li><p>Service Contract Entity Categories - Används av tjänster för att annonsera 
-avtalsformer och liknande.</p>
-</li>
-<li><p>General Entity Categories - Entitetskategorier som inte faller inom ramen
-för någon av de ovanstående typerna.</p>
-</li>
-</ul>
-<p>Specifikationen ”Entity Categories for the Swedish eID Framework”
-[<a href="#eidentcat">EidEntCat</a>] specificerar de entitetskategorier som definieras av tekniskt ramverk och beskriver dess betydelse.</p>
-<p><a name="eidas-constructed-attributes-specification-for-the-swedish-eid-framework"></a></p>
-<h4 id="2.1.5.-eidas-constructed-attributes-specification-for-the-swedish-eid-framework">2.1.5. eIDAS Constructed Attributes Specification for the Swedish eID Framework</h4>
-<p>Specifikationen ”eIDAS Constructed Attributes Specification for the Swedish
-eID Framework”, [<a href="#eidconstrattributes">EidConstrAttributes</a>], specificerar processer och regler
-för hur ID-attribut konstrueras baserat på attribut som tas emot vid
-legitimering mot eIDAS.</p>
-<p><a name="bankid-profile"></a></p>
-<h4 id="2.1.6.-implementation-profile-for-bankid-identity-providers-within-the-swedish-eid-framework">2.1.6. Implementation Profile for BankID Identity Providers within the Swedish eID Framework</h4>
-<p>Specifikationen &quot;Implementation Profile for BankID Identity Providers within the Swedish eID Framework&quot;, [<a href="#eidbankid">EidBankID</a>], definierar regler för hur en legitimeringstjänst som implementerar stöd för BankID skall utformas.</p>
-<blockquote>
-<p><strong>Notera:</strong> Denna specifikation är inte normativ för uppfyllande av tekniskt ramverk. Den är endast relevant för legitimeringstjänster som implementerar stöd för BankID samt e-tjänster som använder dessa. Dock så skall legitimeringstjänster som implementerar stöd för BankID och vill ansluta till Sweden Connect-federationen uppfylla denna specifikation.</p>
-</blockquote>
-<p><a name="principal-selection-in-saml-authentication-requests"></a></p>
-<h4 id="2.1.7.-principal-selection-in-saml-authentication-requests">2.1.7. Principal Selection in SAML Authentication Requests</h4>
-<p>Specifikationen &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#eidprincipalsel">EidPrincipalSel</a>], definierar en utökning till SAML som möjliggör för en förlitande part att informera en legitimeringstjänst vilken identitet den önskar ska legitimeras.</p>
-<p><a name="specifikationer-foer-underskrift"></a></p>
-<h3 id="2.2.-specifikationer-för-underskrift">2.2. Specifikationer för Underskrift</h3>
-<p>Detta stycke innehåller referenser till de dokument vilka definierar
-underskriftstjänster inom federationer som följer Sweden Connect tekniskt
-ramverk.</p>
-<p><a name="implementation-profile-oasis-dss"></a></p>
-<h4 id="2.2.1.-implementation-profile-for-using-oasis-dss-in-central-signing-services">2.2.1. Implementation Profile for using OASIS DSS in Central Signing Services</h4>
-<p>Implementationsprofilen ”Implementation Profile for Using OASIS DSS in
-Central Signing Services”, [<a href="#eiddssprofile">EidDSSProfile</a>], specificerar en profil för
-underskriftsbegäran och respons enligt OASIS standarden &quot;Digital
-Signature Service Core Protocols, Elements, and Bindings&quot;,
-[<a href="#dss">DSS</a>].</p>
-<p><a name="dss-extensions"></a></p>
-<h4 id="2.2.2.-dss-extension-for-federated-central-signing-services">2.2.2. DSS Extension for Federated Central Signing Services</h4>
-<p>”DSS Extension for Federated Central Signing Services”, [<a href="#eiddssext">EidDSSExt</a>], är en påbyggnad av 
-OASIS standarden ”Digital Signature Service Core Protocols, Elements, and Bindings”, [<a href="#dss">DSS</a>], där definitioner som behövs för underskrift enligt tekniskt ramverk specificeras.</p>
-<p><a name="certificate-profile-css"></a></p>
-<h4 id="2.2.3.-certificate-profile-for-certificates-issued-by-central-signing-services">2.2.3. Certificate Profile for Certificates Issued by Central Signing Services</h4>
-<p>Certifikatprofilen ”Certificate profile for certificates issued by Central Signing services”, [<a href="#eidcertprof">EidCertProf</a>], specificerar innehåll i signeringscertifikat. Denna profil tillämpar en
-ny certifikatextension till stöd för underskriftstjänster.</p>
-<p>Denna profil refererar till &quot;Authentication Context Certificate Extension&quot;, [<a href="#authcontext">AuthContext</a>], vilken beskriver hur ”Authentication Context” representeras i X.509 certifikat.</p>
-<p><a name="signature-activation"></a></p>
-<h4 id="2.2.4.-signature-activation-protocol-for-federated-signing">2.2.4. Signature Activation Protocol for Federated Signing</h4>
-<p>Specifikationen &quot;Signature Activation Protocol for Federated Signing&quot;, [<a href="#eidsigact">EidSigAct</a>], definierar ett &quot;Signature Activation Protocol&quot; (SAP) för implementation av &quot;Sole Control Assurance Level 2&quot; (SCAL2) enligt standarden &quot;prEN 419241 - Trustworthy Systems Supporting Server Signing&quot;.</p>
-<p><a name="referenslista"></a></p>
-<h2 id="3.-referenslista">3. Referenslista</h2>
-<p><a name="digg"></a></p>
-<h3 id="3.1.-digg">3.1. DIGG</h3>
-<p><a name="eidtillit"></a>
-<strong>[EidTillit]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digital-identitet/e-legitimering/tillitsnivaer/tillitsramverket">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="eidprofile"></a>
-<strong>[EidProfile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidentcat"></a>
-<strong>[EidEntCat]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidconstrattributes"></a>
-<strong>[EidConstrAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID
-Framework</a>.</p>
-</blockquote>
-<p><a name="eidbankid"></a>
-<strong>[EidBankID]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html">Implementation Profile for BankID Identity Providers within the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidprincipalsel"></a>
-<strong>[EidPrincipalSel]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
-</blockquote>
-<p><a name="eiddssprofile"></a>
-<strong>[EidDSSProfile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="eiddssext"></a>
-<strong>[EidDSSExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="eidcertprof"></a>
-<strong>[EidCertProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing
-services</a>.</p>
-</blockquote>
-<p><a name="eidsigact"></a>
-<strong>[EidSigAct]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="oevriga-referenser"></a></p>
-<h3 id="3.2.-övriga-referenser">3.2. Övriga referenser</h3>
-<p><a name="saml2int"></a>
-<strong>[SAML2Int]</strong></p>
-<blockquote>
-<p><a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML V2.0 Deployment Profile for Federation Interoperability</a>.</p>
-</blockquote>
-<p><a name="dss"></a>
-<strong>[DSS]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc">OASIS Standard – Digital Signature Service Core Protocols, Elements,
-and Bindings Version 1.0, April 11,
-2007</a>.</p>
-</blockquote>
-<p><a name="authcontext"></a>
-<strong>[AuthContext]</strong></p>
-<blockquote>
-<p><a href="https://tools.ietf.org/html/rfc7773">RFC-7773: Authentication Context Certificate Extension</a>.</p>
-</blockquote>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html b/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html
new file mode 120000
index 0000000..3b2d32b
--- /dev/null
+++ b/docs/updates/00_-_Tekniskt_ramverk_-_Introduktion.html
@@ -0,0 +1 @@
+../december-2024/00_-_Tekniskt_ramverk_-_Introduktion.html
\ No newline at end of file
diff --git a/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html b/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
deleted file mode 100644
index 5097c33..0000000
--- a/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1,1585 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Deployment Profile for the Swedish eID Framework</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="deployment-profile-for-the-swedish-eid-framework">Deployment Profile for the Swedish eID Framework</h1>
-<h3 id="version-1.8---2022-10-19---*draft-version*">Version 1.8 - 2022-10-19 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2019-308</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2022. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#references-to-saml-2.0-standards-and-profiles">References to SAML 2.0 Standards and Profiles</a></p>
-</li>
-<li><p><a href="#metadata-and-trust-management"><strong>Metadata and Trust Management</strong></a></p>
-<p> 2.1. <a href="#requirements-for-metadata-content">Requirements for Metadata Content</a></p>
-<p> 2.1.1. <a href="#generic">Generic</a></p>
-<p> 2.1.2. <a href="#service-providers">Service Providers</a></p>
-<p> 2.1.3. <a href="#identity-providers">Identity Providers</a></p>
-<p> 2.1.4. <a href="#signature-service">Signature Service</a></p>
-</li>
-<li><p><a href="#name-identifiers"><strong>Name Identifiers</strong></a></p>
-</li>
-<li><p><a href="#attributes"><strong>Attributes</strong></a></p>
-</li>
-<li><p><a href="#authentication-requests"><strong>Authentication Requests</strong></a></p>
-<p> 5.1. <a href="#discovery">Discovery</a></p>
-<p> 5.2. <a href="#binding-and-security-requirements">Binding and Security Requirements</a></p>
-<p> 5.3. <a href="#message-content">Message Content</a></p>
-<p> 5.3.1. <a href="#requested-authentication-context">Requested Authentication Context</a></p>
-<p> 5.3.2. <a href="#scoping">Scoping</a></p>
-<p> 5.3.3. <a href="#principal-selection">Principal Selection</a></p>
-<p> 5.4. <a href="#processing-requirements">Processing Requirements</a></p>
-<p> 5.4.1. <a href="#validation-of-destination">Validation of Destination</a></p>
-<p> 5.4.2. <a href="#validation-of-assertion-consumer-addresses">Validation of Assertion Consumer Addresses</a></p>
-<p> 5.4.3. <a href="#identity-provider-user-interface">Identity Provider User Interface</a></p>
-<p> 5.4.4. <a href="#authentication-context-and-level-of-assurance-handling">Authentication Context and Level of Assurance Handling</a></p>
-<p> 5.4.5. <a href="#single-sign-on-processing">Single Sign On Processing</a></p>
-</li>
-<li><p><a href="#authentication-responses"><strong>Authentication Responses</strong></a></p>
-<p> 6.1. <a href="#security-requirements">Security Requirements</a></p>
-<p> 6.2. <a href="#message-content2">Message Content</a></p>
-<p> 6.2.1. <a href="#attribute-release-and-consuming-rules">Attribute Release and Consuming Rules</a></p>
-<p> 6.2.2. <a href="#message-content-requirements-for-holder-of-key">Message Content Requirements for Holder-of-key</a></p>
-<p> 6.3. <a href="#processing-requirements2">Processing Requirements</a></p>
-<p> 6.3.1. <a href="#signature-validation">Signature Validation</a></p>
-<p> 6.3.2. <a href="#subject-confirmation">Subject Confirmation</a></p>
-<p> 6.3.3. <a href="#conditions">Conditions</a></p>
-<p> 6.3.4. <a href="#the-authentication-statement">The Authentication Statement</a></p>
-<p> 6.3.5. <a href="#general-security-validation">General Security Validation</a></p>
-<p> 6.4. <a href="#error-responses">Error Responses</a></p>
-</li>
-<li><p><a href="#authentication-for-signature"><strong>Authentication for Signature</strong></a></p>
-<p> 7.1. <a href="#authentication-requests2">Authentication Requests</a></p>
-<p> 7.1.1. <a href="#requesting-display-of-signature-message">Requesting Display of Signature Message</a></p>
-<p> 7.1.2. <a href="#requesting-scal2-signature-activation-data">Requesting SCAL2 Signature Activation Data</a></p>
-<p> 7.2. <a href="#authentication-responses2">Authentication Responses</a></p>
-</li>
-<li><p><a href="#cryptographic-algorithms"><strong>Cryptographic Algorithms</strong></a></p>
-<p> 8.1. <a href="#digest-algorithms">Digest Algorithms</a></p>
-<p> 8.2. <a href="#signature-algorithms">Signature Algorithms</a></p>
-<p> 8.3. <a href="#block-encryption-algorithms">Block Encryption Algorithms</a></p>
-<p> 8.4. <a href="#key-transport-algorithms">Key Transport Algorithms</a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>This profile specifies behaviour and options that deployments of the SAML
-V2.0 Web Browser SSO Profile, [<a href="#saml2prof">SAML2Prof</a>], and the SAML V2.0 Holder-of-key
-Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>],
-are required or permitted to rely on. The requirements specified in this profile
-are in addition to the underlying normative requirements of [<a href="#saml2prof">SAML2Prof</a>]
-and [<a href="#saml2hokprof">SAML2HokProf</a>] (including updates to these specifications provided by [<a href="#saml2errata05">SAML v2.0 Errata 05</a>]).</p>
-<blockquote>
-<p>Note: The profile is influenced by, but not normatively dependent on, <a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html">SAML2Int</a>.</p>
-</blockquote>
-<p>Readers should be familiar with all relevant reference documents, and
-any requirements stated are not repeated unless where deemed necessary
-to clarify or highlight a certain issue.</p>
-<p>Any SAML features specified in referenced SAML documents that are
-optional are out of scope of this profile, unless explicitly specified
-by this profile.</p>
-<p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
-&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
-document are to be interpreted as described in
-[<a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>].</p>
-<p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
-on deployment practices intended to foster both interoperability and
-guarantees of security and confidentiality needed to satisfy the
-requirements of many organizations that engage in the use of federated
-identity. Deviating may limit a deployment&#39;s ability to technically
-interoperate without additional negotiation, and should be undertaken
-with caution.</p>
-<p><a name="references-to-saml-2.0-standards-and-profiles"></a></p>
-<h3 id="1.2.-references-to-saml-2.0-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
-<p>When referring to elements from the SAML 2.0 core specification
-[<a href="#saml2core">SAML2Core</a>], the following syntax is used:</p>
-<ul class="list">
-<li><p><code>&lt;saml2p:Protocolelement&gt;</code> – for elements from the SAML 2.0
-Protocol namespace.</p>
-</li>
-<li><p><code>&lt;saml2:Assertionelement&gt;</code> – for elements from the SAML 2.0
-Assertion namespace.</p>
-</li>
-</ul>
-<p>When referring to elements from the SAML 2.0 metadata specifications,
-the following syntax is used:</p>
-<ul class="list">
-<li><p><code>&lt;md:Metadataelement&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
-</li>
-<li><p><code>&lt;mdui:Element&gt;</code> – for elements defined in [<a href="#saml2metaui">SAML2MetaUI</a>].</p>
-</li>
-<li><p><code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
-</li>
-<li><p><code>&lt;alg:Element&gt;</code> – for elements defined in [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>].</p>
-</li>
-</ul>
-<p>When referring to elements from the SAML V2.0 Holder-of-key Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>], the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;hoksso:ProtocolBinding&gt;</code> - for elements from the SAML V2.0 Web Browser Holder-of-key namespace.</li>
-</ul>
-<p>When referring to elements from the &quot;Identity Provider Discovery Service Protocol and Profile&quot; specification [<a href="#idpdisco">IdpDisco</a>], the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;idpdisc:DiscoveryResponse&gt;</code></li>
-</ul>
-<p>When referring to the <code>Scope</code> element defined in the &quot;Subject Identifier Attributes Profile&quot; specification, [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>], the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;shibmd:Scope&gt;</code></li>
-</ul>
-<p>When referring to elements from the W3C XML Signature namespace
-(<code>http://www.w3.org/2000/09/xmldsig\#</code>) the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;ds:Signature&gt;</code></li>
-</ul>
-<p><strong>Note</strong>: For all references to core SAML specifications, direct or indirect, the [<a href="#saml2errata05">SAML v2.0 Errata 05</a>] MUST always be considered.</p>
-<p><a name="metadata-and-trust-management"></a></p>
-<h2 id="2.-metadata-and-trust-management">2. Metadata and Trust Management</h2>
-<p>Identity Providers and Service Providers conformant with this profile MUST provide a SAML 2.0 Metadata document representing its entity. The provided metadata MUST conform to &quot;Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0&quot;, [<a href="#saml2meta">SAML2Meta</a>], and SHOULD follow &quot;SAML v2.0 Metadata Profile for Algorithm Support Version 1.0&quot;, [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>].</p>
-<p>Services conforming to this profile MUST be able to consume SAML metadata on an automated and periodic basis using the processing rules defined by &quot;SAML V2.0 Metadata Interoperability Profile Version 1.0&quot; [<a href="#saml2metaiop">SAML2MetaIOP</a>]. Automatic consumption of metadata MUST be followed by a successful signature verification of the downloaded metadata before it is trusted and used. </p>
-<p><a name="requirements-for-metadata-content"></a></p>
-<h3 id="2.1.-requirements-for-metadata-content">2.1. Requirements for Metadata Content</h3>
-<p><a name="generic"></a></p>
-<h4 id="2.1.1.-generic">2.1.1. Generic</h4>
-<p><a name="display-information"></a></p>
-<h5 id="2.1.1.1.-display-information">2.1.1.1. Display Information</h5>
-<p>All services that are represented in the Metadata SHALL include a
-<code>&lt;md:Organization&gt;</code> element with mandatory child elements, which
-includes at least one of each of the elements
-<code>&lt;md:OrganizationName&gt;</code>, <code>&lt;md:OrganizationDisplayName&gt;</code> and
-<code>&lt;md:OrganizationURL&gt;</code>.</p>
-<p>The <code>&lt;md:OrganizationName&gt;</code> element SHALL hold a registered name of
-the organization, which matches the agreement with the federation
-operator.</p>
-<p>The <code>&lt;md:OrganizationDisplayName&gt;</code> element SHALL contain a display
-name of the organization and SHALL NOT contain a service name that is
-unrelated to the name of the organization.</p>
-<p>Metadata for an entity SHALL contain an <code>&lt;mdui:UIInfo&gt;</code>
-extension, extending the <code>&lt;md:SPSSODescriptor&gt;</code> or <code>&lt;md:IDPSSODescriptor&gt;</code> element 
-(depending on the type of the entity). This <code>&lt;mdui:UIInfo&gt;</code> element SHALL at least contain a
-<code>&lt;mdui:DisplayName&gt;</code> element with the language attribute <code>sv</code>
-(Swedish), representing the entity name that has been approved
-by the federation operator. The <code>&lt;mdui:UIInfo&gt;</code> element SHALL also
-contain a reference to one, or more, logotype images (<code>&lt;mdui:Logo&gt;</code>) as described in section 2.1.5
-of [<a href="#saml2metaui">SAML2MetaUI</a>] and SHOULD
-contain a <code>&lt;mdui:Description&gt;</code> element with the language attribute
-<code>sv</code> (Swedish).</p>
-<p>It is RECOMMENDED that the above elements represented in Swedish also be
-represented with the language attribute <code>en</code> (English).</p>
-<p>A federation operator may impose further requirements regarding the <code>&lt;mdui:UIInfo&gt;</code> extension.</p>
-<p><a name="certificates-in-metadata"></a></p>
-<h5 id="2.1.1.2.-certificates-in-metadata">2.1.1.2. Certificates in Metadata</h5>
-<p>Public keys used for signature validation and encryption MUST be expressed via X.509
-certificates included in metadata as <code>&lt;ds:X509Certificate&gt;</code> child elements to
-<code>&lt;md:KeyDescriptor&gt;</code> elements. These certificates merely acts as containers for the public keys 
-needed for signature validation and encryption and the consumer of a metadata entry cannot
-expect to be able to execute a successful certificate path validation of such certificates.
-A metadata consumer MUST NOT reject a metadata entry due to that certificate trust is missing,
-the certificate is expired, or certificate revocation information is missing.</p>
-<p>However, for interoperability reasons it is RECOMMENDED that:</p>
-<ul class="list">
-<li>self-signed certificates are used,</li>
-<li>non-expired certificates (with a long validity time) are used,</li>
-<li>certificates are not signed with MD5- och SHA1-based signature algorithms. </li>
-</ul>
-<p>All services represented in metadata SHOULD include at least one <code>&lt;md:KeyDescriptor&gt;</code> 
-element holding a certificate to be used for signature validation (with the <code>use</code>-attribute
-set to <code>signing</code>), and one <code>&lt;md:KeyDescriptor&gt;</code> element containing a certificate 
-to be used for message encryption (with the <code>use</code>-attribute set to <code>encryption</code>).
-It is allowed to use the same key and certificate for both usages, but in order to enable
-a future key rollover it is RECOMMENDED to avoid using only one <code>&lt;md:KeyDescriptor&gt;</code> element
-for both usages (i.e., with an absent <code>use</code>-attribute).</p>
-<p>In order to facilitate key rollover of a signing key, a service MUST support multiple signing 
-certificates found in peer metadata and MUST support signature validation using a key from 
-any of the available peer signature certificates.</p>
-<p>For key rollover of encryption keys, the service that is performing the key rollover MUST only
-publish the latest key (in a certificate) to its metadata entry. Until all peers have consumed
-the service&#39;s metadata entry containing the new certificate, the service MUST support decrypting 
-messages using both the old and new key.</p>
-<p><a name="declaring-algorithm-support"></a></p>
-<h5 id="2.1.1.3.-declaring-algorithm-support">2.1.1.3. Declaring Algorithm Support</h5>
-<p>Services MAY declare encryption and signature capabilities as defined in [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>]. The declared algorithms MUST meet the algorithm requirements defined by the Swedish eID Framework or by the federation operator . Thus, it is not allowed to declare an algorithm, or key size, that is prohibited from use. </p>
-<p>All services conformant with this specification MUST support the mandatory algorithms defined by the Swedish eID Framework, meaning that a service has no possibility to opt-out from a certain mandatory algorithm by excluding it from the declared capabilities. The main purpose of declaring an algorithm using any of the elements <code>&lt;md:EncryptionMethod&gt;</code>, <code>&lt;alg:SigningMethod&gt;</code> or <code>&lt;alg:DigestMethod&gt;</code> is to declare which algorithm the service prefers.</p>
-<p><a name="service-providers"></a></p>
-<h4 id="2.1.2.-service-providers">2.1.2. Service Providers</h4>
-<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of a Service Provider’s
-entity descriptor SHOULD contain one entity category attribute
-[<a href="#entcat">EntCat</a>] that holds at least
-one attribute value representing a service entity category as defined in
-[<a href="#eidentcat">EidEntCat</a>], identifying the Service Provider requirements in relation to
-identity services concerning attribute release and level of assurance.</p>
-<p>The example below illustrates how an entity declares the service entity
-category identifier <strong><code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></strong> in its
-metadata.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:attribute"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"http://macedir.org/entity-category"</span>
-                     <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>
-                     <span class="hljs-attr">xmlns:saml2</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:assertion"</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xs:string"</span>&gt;</span>
-        http://id.elegnamnden.se/ec/1.0/loa3-pnr
-      <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-    <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p>If a Service Provider does not have any attribute requirements other than those
-implicitly requested by inclusion of one or more service entity categories, the
-metadata entry of the Service Provider SHOULD NOT include a
-<code>&lt;md:AttributeConsumingService&gt;</code> element (with <code>&lt;md:RequestedAttribute&gt;</code> 
-elements). </p>
-<p>Any needs for particular attributes from Identify Providers, when
-present, MUST be expressed through present service entity categories in
-combination with <code>&lt;md:RequestedAttribute&gt;</code> elements under the
-<code>&lt;md:AttributeConsumingService&gt;</code> element in the Service
-Provider metadata. The <code>&lt;md:RequestedAttribute&gt;</code> elements in the
-Service Provider metadata, when present, hold a list of requested and/or
-required attributes. This list of attributes MUST be interpreted in the
-context of present service entity categories defined in [<a href="#eidentcat">EidEntCat</a>].</p>
-<blockquote>
-<p>Note: Only the requirements for attributes that are not implicitly requested through a declared
-service entity category need to be expressed as <code>&lt;md:RequestedAttribute&gt;</code> elements.</p>
-</blockquote>
-<p>A Service Provider MAY sign authentication request messages sent to
-Identity Providers. A Service Provider that signs authentication
-requests messages MAY also ensure that a receiving Identity Provider
-will only accept valid signed requests from this Service Provider by
-assigning the <code>AuthnRequestsSigned</code> attribute of the
-<code>&lt;md:SPSSODescriptor&gt;</code> to a value of <code>true</code>.</p>
-<p>Section E7, “Metadata for Agreeing to Sign Authentication Requests”, of
-[<a href="#saml2errata05">SAML v2.0 Errata 05</a>]
-specifies the following concerning the <code>AuthnRequestsSigned</code> attribute:</p>
-<blockquote>
-<p>Optional attribute that indicates whether the
-<code>&lt;saml2p:AuthnRequest&gt;</code> messages sent by this Service Provider
-will be signed. If omitted, the value is assumed to be false. A value
-of false (or omission of this attribute) does not imply that the
-Service Provider will never sign its requests or that a signed request
-should be considered an error. However, an Identity Provider that
-receives an unsigned <code>&lt;saml2p:AuthnRequest&gt;</code> message from a
-Service Provider whose metadata contains this attribute with a value
-of true MUST return a SAML error response and MUST NOT fulfill the
-request.</p>
-</blockquote>
-<p>Furthermore, a Service Provider MAY require assertions that are issued
-to it, to be signed. This is done by assigning the <code>WantAssertionsSigned</code>
-attribute of the <code>&lt;md:SPSSODescriptor&gt;</code> to a value of <code>true</code>.</p>
-<p>Note that the response message that carries the assertion will always be
-signed, so the Service Provider should only require signed assertions in
-case that it wants to preserve the proof of authenticity of an assertion
-separate from the response.</p>
-<p>A Service Provider wishing to make use of a central discovery service as specified in the &quot;Identity Provider Discovery Service Protocol Profile&quot; [<a href="#idpdisco">IdPDisco</a>] MUST include at least one <code>&lt;idpdisc:DiscoveryResponse&gt;</code> element as an extension under the <code>&lt;md:SPSSODescriptor&gt;</code> element. </p>
-<p><a name="sp-holder-of-key-support"></a></p>
-<h5 id="2.1.2.1.-holder-of-key-support">2.1.2.1. Holder of Key Support</h5>
-<p>A Service Provider that sends authentication requests using the Holder-of-key Web Browser SSO Profile MUST include a <code>&lt;md:AssertionConsumerService&gt;</code> element in its metadata according to section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-<p>If the Service Provider also makes use of the ordinary Web Browser SSO Profile at least one <code>&lt;md:AssertionConsumerService&gt;</code> element according to section 2.4.4 of [<a href="#saml2meta">SAML2Meta</a>] MUST also be included in the Service Provider metadata. </p>
-<p>In those cases, where a Service Provider supports both profiles, it is RECOMMENDED that the a <code>&lt;md:AssertionConsumerService&gt;</code> element for ordinary Web Browser SSO Profile is marked as default.</p>
-<pre class="hljs"><code>&lt;md:AssertionConsumerService <span class="hljs-built_in">index</span>=<span class="hljs-string">"0"</span> isDefault=<span class="hljs-string">"true"</span>
-  xmln<span class="hljs-variable">s:md</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"</span>
-  Location=<span class="hljs-string">"https://sp.example.org/path1"</span> /&gt;
-
-&lt;md:AssertionConsumerService <span class="hljs-built_in">index</span>=<span class="hljs-string">"1"</span> isDefault=<span class="hljs-string">"false"</span>   
-  xmln<span class="hljs-variable">s:md</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>   
-  xmln<span class="hljs-variable">s:hoksso</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span> 
-  hoksso:ProtocolBinding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"</span> 
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span> 
-  Location=<span class="hljs-string">"https://sp.example.org/path2"</span> /&gt;</code></pre><p><em>Example of a Service Provider&#39;s declared AssertionConsumerService elements; one for receiving assertions according the Web Browser SSO Profile and one for receiving assertions according to the Holder-of-key Web Browser SSO Profile.</em></p>
-<p><a name="identity-providers"></a></p>
-<h4 id="2.1.3.-identity-providers">2.1.3. Identity Providers</h4>
-<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of an Identity Provider’s
-entity descriptor SHOULD contain one entity category attribute
-[<a href="#entcat">EntCat</a>] that holds at least
-one attribute value representing a service entity category as defined in
-[<a href="#eidentcat">EidEntCat</a>], defining the Identity Provider ability to deliver
-assertions (defining the level of assurance and attribute release).</p>
-<p>If an Identity Provider has the ability to release attributes, other than those
-implicitly given by the declared service entity categories, it is RECOMMENDED that 
-those attributes are declared as <code>&lt;saml:Attribute&gt;</code> elements under the 
-<code>&lt;md:IDPSSODescriptor&gt;</code> element. </p>
-<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of an Identity Provider’s
-metadata SHALL contain an attribute according to
-[<a href="#saml2iap">SAML2IAP</a>] with its <code>Name</code> attribute set to 
-<code>urn:oasis:names:tc:SAML:attribute:assurance-certification</code>
-and holding at least one attribute value identifying a Level of Assurance
-(LoA) for which the Identity Provider has been approved. 
-The Swedish eID Framework defines such identifier values in section 3.1.1 of
-[<a href="#eidregistry">EidRegistry</a>] and their meanings are defined in [<a href="#eidtillit">EidTillit</a>].</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:attribute"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:attribute:assurance-certification"</span>
-                    <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>
-                    <span class="hljs-attr">xmlns:saml</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:assertion"</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xsd:string"</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>
-    <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>
-    ...
-  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p><em>Example of how an Identity Provider advertises that the service delivers authentication according to
-the <code>http://id.elegnamnden.se/loa/1.0/loa3</code> level of assurance.</em></p>
-<p>An Identity Provider MAY require authentication request messages to be
-signed. This is indicated by assigning the
-<code>WantAuthnRequestsSigned</code> attribute of the <code>&lt;md:IDPSSPDescriptor&gt;</code>
-element to a value of <code>true</code>. See further section E7, “Metadata for
-Agreeing to Sign Authentication Requests”, of [<a href="#saml2errata05">SAML v2.0 Errata
-05</a>].</p>
-<p>Identity Providers SHALL advertise support for the SAP protocol according to [<a href="#sigsap">SigSAP</a>], by including the service property entity category URI
-<code>http://id.elegnamnden.se/sprop/1.0/scal2</code> in its metadata. An Identity Provider that does not advertise support for SAP MAY ignore requests for SAD.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:attribute"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"http://macedir.org/entity-category"</span> 
-                    <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>
-                    <span class="hljs-attr">xmlns:saml</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:assertion"</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xs:string"</span>&gt;</span>http://id.elegnamnden.se/sprop/1.0/scal2<span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>
-    <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>
-    ...
-  <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span></code></pre><p><em>Example of how an Identity Provider advertises its support for SCAL2 authentication.</em></p>
-<p>An Identity Provider that wishes to receive the <code>&lt;psc:PrincipalSelection&gt;</code> extension in authentication requests SHOULD include the <code>&lt;psc:RequestedPrincipalSelection&gt;</code> extension extending the <code>&lt;md:IDPSSODescriptor&gt;</code> element. In this extension the Identity Provider declares which attribute value(s) it wants to receive in authentication requests from requestors using the <code>&lt;psc:PrincipalSelection&gt;</code> authentication request extension. See <a href="#principal-selection">section 5.3.3</a> and [<a href="#principalsel">PrincipalSel</a>].</p>
-<p><a name="declaring-authorized-scopes"></a></p>
-<h5 id="2.1.3.1.-declaring-authorized-scopes">2.1.3.1. Declaring Authorized Scopes</h5>
-<p>An Identity Provider that releases &quot;scoped attributes&quot;, see section 3.1.3 of [<a href="#eidattributes">EidAttributes</a>],
-MUST be authorized to do so by the federation operator. Each authorized scope MUST be declared in the Identity Provider metadata entry using a <code>&lt;shibmd:Scope&gt;</code> element, see section 3.5.2, &quot;Scope Filtering&quot;, in [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>]. The <code>&lt;shibmd:Scope&gt;</code> elements MUST appear within the <code>&lt;md:Extensions&gt;</code> element of the <code>&lt;md:IDPSSODescriptor&gt;</code>.</p>
-<pre class="hljs"><code>&lt;md:IDPSSODescriptor ...&gt;
-  &lt;md:<span class="hljs-keyword">Extensions&gt;
-</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">"false"</span> xmlns:<span class="hljs-keyword">shibmd="urn:mace:shibboleth:metadata:1.0&gt;2021006883&lt;/shibmd:Scope&gt;
-</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">"false"</span> xmlns:<span class="hljs-keyword">shibmd="urn:mace:shibboleth:metadata:1.0&gt;2021006255&lt;/shibmd:Scope&gt;
-</span>    &lt;<span class="hljs-keyword">shibmd:Scope </span>regexp=<span class="hljs-string">"false"</span> xmlns:<span class="hljs-keyword">shibmd="urn:mace:shibboleth:metadata:1.0&gt;example.com&lt;/shibmd:Scope&gt;
-</span>    ...</code></pre><p><em>Example of how an Identity Provider declares that it is authorized to deliver scoped attributes for three different scopes; two organizational numbers and one domain.</em></p>
-<p><a name="idp-holder-of-key-support"></a></p>
-<h5 id="2.1.3.2.-holder-of-key-support">2.1.3.2. Holder of Key Support</h5>
-<p>An Identity Provider that supports the Holder-of-key Web Browser SSO Profile MUST declare <code>&lt;md:SingleSignOnService&gt;</code> elements<sup>*</sup> in its metadata according to section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-<p>If the Identity Provider also supports authentication according the ordinary Web Browser SSO Profile <code>&lt;md:SingleSignOnService&gt;</code> elements<sup>*</sup> according to section 2.4.3 of [<a href="#saml2meta">SAML2Meta</a>] MUST also be included in the Identity Provider metadata.</p>
-<pre class="hljs"><code>&lt;md:SingleSignOnService
-  xmlns:md=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"</span>
-  Location=<span class="hljs-string">"https://idp.example.org/path1"</span> /&gt;
-
-&lt;md:SingleSignOnService
-  xmlns:md=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"</span>
-  Location=<span class="hljs-string">"https://idp.example.org/path2"</span> /&gt;
-
-&lt;md:SingleSignOnService
-  xmlns:md=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>
-  xmlns:hoksso=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span>
-  hoksso:ProtocolBinding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"</span> 
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span>
-  Location=<span class="hljs-string">"https://idp.example.org/path2"</span> /&gt;
-
-&lt;md:SingleSignOnService
-  xmlns:md=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span>
-  xmlns:hoksso=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span>
-  hoksso:ProtocolBinding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"</span> 
-  Binding=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key:SSO:browser"</span>
-  Location=<span class="hljs-string">"https://idp.example.org/path2"</span> /&gt;</code></pre><p><em>Example of an Identity Provider&#39;s declared SingleSignOnService elements; two for receiving requests according to the Web Browser SSO Profile and two for receiving requests according to the Holder-of-key Web Browser SSO Profile.</em></p>
-<blockquote>
-<p>[*]: This profile requires an Identity Provider to support both the POST and Redirect bindings, see section <a href="#binding-and-security-requirements">5.2</a> below.</p>
-</blockquote>
-<p><a name="signature-service"></a></p>
-<h4 id="2.1.4.-signature-service">2.1.4. Signature Service</h4>
-<p>A Signature Service within the Swedish eID Framework is a Service
-Provider with specific requirements concerning its representation in
-metadata. </p>
-<p>The <code>&lt;mdattr:EntityAttributes&gt;</code> element of a Signature Service SP
-entity descriptor SHALL include the service type entity category
-identifier <strong><code>http://id.elegnamnden.se/st/1.0/sigservice</code></strong> ([<a href="#eidentcat">EidEntCat</a>])
-as a value to the entity category attribute [<a href="#entcat">EntCat</a>].</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:metadata:attribute"</span>&gt;</span>`
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">"http://macedir.org/entity-category"</span>
-                   <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</span>
-                   <span class="hljs-attr">xmlns:saml2</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:assertion"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xs:string"</span>&gt;</span>http://id.elegnamnden.se/ec/1.0/loa3-pnr<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">"xs:string"</span>&gt;</span>http://id.elegnamnden.se/st/1.0/sigservice<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span></code></pre><p><em>Entity attributes for a Signature Service SP.</em></p>
-<p>A Signature Service MUST assign the <code>AuthnRequestsSigned</code> attribute of the
-<code>&lt;md:SPSSODescriptor&gt;</code> element to <code>true</code>. This requirement ensures
-that the Signature Service always signs its authentication requests in
-order for the request to be accepted by the Identity Provider. The
-federation operator will enforce that all Service Providers that operate
-as Signature Services have this attribute set.</p>
-<p><a name="name-identifiers"></a></p>
-<h2 id="3.-name-identifiers">3. Name Identifiers</h2>
-<p>Identity Providers and Service Providers MUST support both the
-<code>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</code> and the
-<code>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</code> name identifier
-formats as specified in [<a href="#saml2core">SAML2Core</a>].</p>
-<p>Identity Providers SHALL default to use the
-<code>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</code> name identifier
-format in cases where a Service Provider has not specified the name
-identifier to use (via the <code>&lt;md:NameIDFormat&gt;</code> element of the
-Service Provider metadata entry, or via the <code>Format</code> attribute of the
-<code>&lt;saml2p:NameIDPolicy&gt;</code> element of the authentication request
-message).</p>
-<p><a name="attributes"></a></p>
-<h2 id="4.-attributes">4. Attributes</h2>
-<p>Attribute specifications for the Swedish eID Framework are defined in
-[<a href="#eidattributes">EidAttributes</a>].</p>
-<p>The content of <code>&lt;saml2:AttributeValue&gt;</code> elements exchanged via any
-SAML 2.0 messages or assertions SHOULD be limited to a single child text
-node.</p>
-<p>For requirements regarding attribute inclusion in SAML assertions, see
-section <a href="#attribute-release-and-consuming-rules">6.2.1</a>, “<a href="#attribute-release-and-consuming-rules">Attribute Release and Consuming Rules</a>”, below.</p>
-<p><a name="authentication-requests"></a></p>
-<h2 id="5.-authentication-requests">5. Authentication Requests</h2>
-<p>This profile supports two different SSO profiles; the Web Browser SSO Profile, [<a href="#saml2prof">SAML2Prof</a>], and the Holder-of-key Web Browser Profile, [<a href="#saml2hokprof">SAML2HokProf</a>]. </p>
-<p>The profile in use is determined by how an authentication process is initiated, meaning to which Identity Provider endpoint an <code>&lt;saml2p:AuthnRequest&gt;</code> message is sent, see <a href="#idp-holder-of-key-support">2.1.3.2</a>.</p>
-<p><a name="discovery"></a></p>
-<h3 id="5.1.-discovery">5.1. Discovery</h3>
-<p>This profile does not impose any requirements of
-how the process of discovery is implemented by Service Providers wishing
-to display user interfaces for selection of Identity Providers for end
-users. However, Service Providers making use of a centralized
-discovery service as defined in [<a href="#idpdisco">IdpDisco</a>] MUST follow the requirements
-stated for discovery responses in 
-section <a href="##service-providers">2.1.2</a>, &quot;<a href="#service-providers">Service Providers</a>&quot;.</p>
-<p><a name="binding-and-security-requirements"></a></p>
-<h3 id="5.2.-binding-and-security-requirements">5.2. Binding and Security Requirements</h3>
-<p>The endpoints, at which an Identity Provider receives a
-<code>&lt;saml2p:AuthnRequest&gt;</code> message, and all subsequent exchanges with
-the user agent, MUST be protected by TLS. </p>
-<p>If the Identity Provider supports the Holder-of-key Web Browser SSO Profile, the
-dedicated endpoints for this profile (see section <a href="#idp-holder-of-key-support">2.1.3.2</a>)
-MUST be configured to require a 
-client X.509 certificate being presented as part of the TLS handshake (mTLS, mutual TLS), 
-see section 2.4 of [<a href="#saml2hokprof">SAML2HokProf</a>]. If the Identity Provider receives
-a request on a Holder-of-key endpoint and is unable to retrieve the client X.509
-certificate it MUST respond with an error, see section 2.6.4 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-<p>A Service Provider sending an <code>&lt;saml2p:AuthnRequest&gt;</code> message to an Identity Provider
-may do so using either the HTTP-Redirect or HTTP-POST binding [<a href="#saml2bind">SAML2Bind</a>]<sup>*</sup>,
-meaning that Identity Providers conformant with this profile MUST support the
-HTTP-Redirect and the HTTP-POST binding.</p>
-<p>An Identity Provider that requires <code>&lt;saml2p:AuthnRequest&gt;</code> messages
-to be signed MUST not accept messages that are not signed, or where the
-verification of the signature fails. In these cases the Identity
-Provider MUST respond with an error.</p>
-<p>An Identity Provider that itself does not require authentication
-messages to be signed MUST still accept and verify signed request
-messages from Service Providers that indicate, in their metadata, that
-they sign request messages (see <a href="#service-providers">2.1.2</a> above). If this signature
-verification fails, the Identity Provider MUST return a SAML error
-response and MUST NOT fulfil the request.</p>
-<p>An Identity Provider that receives a request message that is not signed
-from a Service Provider that has indicated, in its metadata, that it
-will only send signed request messages (see <a href="#service-providers">2.1.2</a> above) MUST respond
-with an error.</p>
-<p>The signature for authentication request messages is applied differently
-depending on the binding. The HTTP-Redirect binding requires the
-signature to be applied to the URL-encoded value rather than being
-placed within the XML-message (see section 3.4.4.1 of
-[<a href="#saml2bind">SAML2Bind</a>]).
-For the HTTP-POST binding the <code>&lt;saml2p:AuthnRequest&gt;</code> element MUST
-be signed using a <code>&lt;ds:Signature&gt;</code> element within the
-<code>&lt;saml2:AuthnRequest&gt;</code>.</p>
-<p>Before signing the authentication request, the Service Provider SHOULD consult the Identity Provider&#39;s metadata (<code>&lt;alg:SigningMethod&gt;</code> and <code>&lt;alg:DigestMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory signing and digest algorithms defined in the Swedish eID Framework during the signature operation.</p>
-<blockquote>
-<p>[*]: A Service Provider should be aware of web browser, or web server, size limitations
-of URL:s, and it is RECOMMENDED that a Service Provider use the HTTP-POST binding in cases where 
-the <code>&lt;saml2p:AuthnRequest&gt;</code> message becomes very large. This may be the case when a <code>SignMessage</code>
-extension containing much data is used, or when a complete certificate chain is attached to the signature 
-of the message.</p>
-</blockquote>
-<p><a name="message-content"></a></p>
-<h3 id="5.3.-message-content">5.3. Message Content</h3>
-<p>An <code>&lt;saml2p:AuthnRequest&gt;</code> message MUST NOT contain a Document Type Definition (DTD).</p>
-<p>The <code>&lt;saml2p:AuthnRequest&gt;</code> message SHOULD contain an
-<code>AssertionConsumerServiceURL</code><sup>*</sup> attribute identifying the desired response
-location. The Service Provider MUST NOT use any other values for this
-attribute than those listed in its metadata record as
-<code>&lt;md:AssertionConsumerService&gt;</code> elements for the HTTP-POST binding
-(see section 4.1.6 of [<a href="#saml2prof">SAML2Prof</a>]), and URL
-canonicalization or normalization MUST NOT be required.</p>
-<p>The <code>Destination</code> attribute of the <code>&lt;saml2p:AuthnRequest&gt;</code> message
-MUST contain the URL to which the Service Provider has instructed the
-user agent to deliver the request. This is useful to prevent malicious
-forwarding of signed requests from being accepted by unintended Identity
-Providers.</p>
-<p>Identity Providers conformant with this profile MUST support the
-<code>ForceAuthn</code> and <code>IsPassive</code> attributes received in
-<code>&lt;saml2p:AuthnRequest&gt;</code> messages.</p>
-<p>Service Providers SHOULD include the <code>ForceAuthn</code> attribute in all
-<code>&lt;saml2p:AuthnRequest&gt;</code> messages and explicitly set its value to
-<code>true</code> or <code>false</code>, and not rely on its default value. The reason for this is
-to avoid accidental SSO.</p>
-<p>If the Service Provider has included more than one <code>&lt;md:AttributeConsumingService&gt;</code> element in its metadata it is RECOMMENDED that the <code>&lt;saml2p:AuthnRequest&gt;</code> message contains the <code>AttributeConsumingServiceIndex</code> attribute holding the index of the <code>&lt;md:AttributeConsumingService&gt;</code> element that the Identity Provider should consider during attribute release.</p>
-<blockquote>
-<p>[*]: The <code>AssertionConsumerServiceURL</code> attribute is mutually exclusive with the <code>AssertionConsumerServiceIndex</code> attribute, meaning that a <code>&lt;saml2p:AuthnRequest&gt;</code> message MUST NOT contain both attributes. </p>
-</blockquote>
-<p><a name="requested-authentication-context"></a></p>
-<h4 id="5.3.1.-requested-authentication-context">5.3.1. Requested Authentication Context</h4>
-<p>A Service Provider SHOULD explicitly specify a requested
-authentication context element (<code>&lt;saml2p:RequestedAuthnContext&gt;</code>),
-containing <code>&lt;saml2:AuthnContextClassRef&gt;</code> elements each holding
-a Level of Assurance authentication context URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>]) 
-that the Service Provider considers acceptable for the authentication process.</p>
-<p>A present <code>&lt;saml2p:RequestedAuthnContext&gt;</code> element MUST specify
-exact matching by means of either an absent <code>Comparison</code> attribute or a
-<code>Comparison</code> attribute with the value set to <code>exact</code>. This means that the
-Identity Provider is forced to return an assertion with exactly one of
-the requested <code>&lt;saml2:AuthnContextClassRef&gt;</code> in the request as the
-declared <code>&lt;saml2:AuthnContext&gt;</code>, or return an error response. If the
-Service Provider requires the Identity Provider to return specifically
-one out of a selection of acceptable authentication context URIs, then
-all of these URIs MUST be included in the request.</p>
-<p>The requested authentication context SHOULD be consistent with at least
-one of the service entity categories [<a href="#eidentcat">EidEntCat</a>] declared in the
-Service Provider’s metadata entry. See further <a href="#authentication-context-and-level-of-assurance-handling">section 5.4.4</a> below.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:RequestedAuthnContext</span> <span class="hljs-attr">Comparison</span>=<span class="hljs-string">"exact"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:RequestedAuthnContext</span>&gt;</span></code></pre><p><em>Example of how an Authentication Context URI identifier representing a
-requested Level of Assurance is included in an authentication request
-message.</em></p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:RequestedAuthnContext</span> <span class="hljs-attr">Comparison</span>=<span class="hljs-string">"exact"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/eidas-nf-sub<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:RequestedAuthnContext</span>&gt;</span></code></pre><p><em>Example of how several Authentication Context URIs are included in an
-authentication request message. In this case, the Service Provider
-states that it requests the authentication to be performed according to
-either the LoA3 URI defined within the Swedish eID Framework or the
-substantial level for notified eIDs defined within the eIDAS Framework.</em></p>
-<p><a name="scoping"></a></p>
-<h4 id="5.3.2.-scoping">5.3.2. Scoping</h4>
-<p>An Identity Provider that acts as a proxy for other Identity Providers SHOULD support the <code>&lt;saml2p:Scoping&gt;</code> element holding one, or more, entries signalling to the Proxy Identity Provider which Identity Provider(s) that may be used to authenticate the user. A Service Provider that sends authentication requests to a Proxy
-IdP MAY include the <code>&lt;saml2p:Scoping&gt;</code> element. See section 3.4.1.5 of [<a href="#saml2core">SAML2Core</a>].</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Scoping</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPEntry</span> <span class="hljs-attr">ProviderID</span>=<span class="hljs-string">"http://idp.example.com"</span> /&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Scoping</span>&gt;</span></code></pre><p><em>Example of how an <code>AuthnRequest</code> contains a <code>Scoping</code>-element where the requester (Service Provider) signals to the Proxy IdP which Identity Provider that should perform the authentication of the user.</em></p>
-<p>The Swedish eIDAS Connector is a Proxy IdP that proxies requests to foreign eIDAS Proxy Services. Normally, the eIDAS connector presents a country selection dialogue to the user, prompting for the country where the user should be directed to for authentication. However, a Service Provider MAY include an eIDAS Proxy Service alias URI for a specific country&#39;s Proxy Service under the <code>&lt;saml2p:Scoping&gt;</code> element of the <code>&lt;saml2p:AuthnRequest&gt;</code> in order to bypass the country selection dialogue. See section 3.1.9.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Scoping</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:IDPEntry</span> <span class="hljs-attr">ProviderID</span>=<span class="hljs-string">"http://id.swedenconnect.se/eidas/1.0/proxy-service/no"</span> /&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:IDPList</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Scoping</span>&gt;</span></code></pre><p><em>Example of how an <code>AuthnRequest</code> sent to the eIDAS Connector requests that the eIDAS Connector should
-proxy the request to the Norwegian eIDAS Proxy Service for authentication.</em></p>
-<blockquote>
-<p><strong>Note</strong>: A Service Provider may list more than one country in the <code>&lt;saml2p:IDPList&gt;</code> of a <code>&lt;saml2p:Scoping&gt;</code> element. The eIDAS Connector will then present a country selection dialogue containing only the listed countries.</p>
-</blockquote>
-<p><strong>Note:</strong> Another method of bypassing the country selection dialogue is to include the <code>c</code> (<code>urn:oid:2.5.4.6</code>) 
-attribute with the country code for the requested country as its value in a <code>&lt;psc:PrincipalSelection&gt;</code>
-extension of the <code>AuthnRequest</code> message, see section <a href="#principal-selection">5.3.3</a> below.</p>
-<p><a name="principal-selection"></a></p>
-<h4 id="5.3.3.-principal-selection">5.3.3. Principal Selection</h4>
-<p>The specification &quot;Principal Selection in SAML Authentication Requests&quot;, [<a href="#principalsel">PrincipalSel</a>], defines the <code>&lt;psc:PrincipalSelection&gt;</code> extension that enables a requestor to inform the Identity Provider about known attributes for the principal that is about to be authenticated. </p>
-<p>This may be relevant for Identity Provider services who prompt users for an identifier in order initiate an authentication process with the user&#39;s eID. In such cases, this extension can be used to avoid unnecessary prompting when the user&#39;s identity is known in advance to the service requesting authentication, such as when a previously authenticated user is requested to sign a document.</p>
-<p>An Identity Provider that wishes to receive the <code>&lt;psc:PrincipalSelection&gt;</code> extension SHOULD advertise this in its metadata according to <a href="#identity-providers">section 2.1.3</a>.</p>
-<p>A Service Provider that sends an authentication request  to an Identity Provider that has declared that it wishes to receive certain attribute values MAY include the <code>&lt;psc:PrincipalSelection&gt;</code> extension in the <code>&lt;saml2p:AuthnRequest&gt;</code> message, provided that the Service Provider has knowledge about this information.</p>
-<p>A Service Provider that is a Signature Service SHOULD include the extension for the case described above.</p>
-<p><a name="processing-requirements"></a></p>
-<h3 id="5.4.-processing-requirements">5.4. Processing Requirements</h3>
-<p><a name="validation-of-destination"></a></p>
-<h4 id="5.4.1.-validation-of-destination">5.4.1. Validation of Destination</h4>
-<p>An Identity Provider receiving a <code>&lt;saml2p:AuthnRequest&gt;</code> message
-MUST verify that the <code>Destination</code> attribute is present, and that it is
-consistent with URLs configured in the Identity Provider’s metadata.</p>
-<p><a name="validation-of-assertion-consumer-addresses"></a></p>
-<h4 id="5.4.2.-validation-of-assertion-consumer-addresses">5.4.2. Validation of Assertion Consumer Addresses</h4>
-<p>If the <code>AssertionConsumerServiceURL</code> attribute is present in the
-<code>&lt;saml2p:AuthnRequest&gt;</code> message, its value MUST be verified to be
-consistent with one of the <code>&lt;md:AssertionConsumerService&gt;</code> elements
-having the HTTP-POST binding<sup>*</sup> found in the Service Provider’s metadata
-entry and matching the SSO profile<sup>**</sup> in use 
-(see <a href="#sp-holder-of-key-support">section 2.1.2.1</a>). If this is not the case, 
-the request must be rejected.</p>
-<p>If the <code>AssertionConsumerServiceIndex</code> attribute is present in the
-<code>&lt;saml2p:AuthnRequest&gt;</code> message, a <code>&lt;md:AssertionConsumerService&gt;</code> matching this
-index MUST be present in the Service Provider’s metadata. This
-<code>&lt;md:AssertionConsumerService&gt;</code> element MUST also match the binding and SSO
-profile in use as defined above. If this is not the case, 
-the request must be rejected.</p>
-<blockquote>
-<p>This means that an Identity Provider that services an authentication request
-received on an <code>SingleSignOnService</code> endpoint dedicated for the Holder-of-key
-Web Browser Profile MUST NOT allow an <code>&lt;md:AssertionConsumerService&gt;</code> element
-that is not intended for the Holder-of-key profile, see section 2.8 of 
-[<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-</blockquote>
-<p>If the attribute is not present in the <code>&lt;saml2p:AuthnRequest&gt;</code>
-message, the Identity Provider MUST obtain the desired response location
-from the Service Provider’s metadata entry.  This location is determined by first 
-finding all the <code>&lt;md:AssertionConsumerService&gt;</code> 
-elements that matches the SSO profile<sup>**</sup> in use (see 
-<a href="#sp-holder-of-key-support">section 2.1.2.1</a>) and the binding<sup>*</sup> (HTTP-POST), 
-and then selecting the element that is marked as default (has the <code>isDefault</code> attribute set), 
-or if no matching element is marked as default, the one with the lowest index value (see 
-section 2.4.4.1 of [<a href="#saml2meta">SAML2Meta</a>] and section 2.8 of 
-[<a href="#saml2hokprof">SAML2HokProf</a>]). If no matching <code>&lt;md:AssertionConsumerService&gt;</code>
-element is found the request must be rejected.</p>
-<blockquote>
-<p>[*]: For Holder-of-key <code>&lt;md:AssertionConsumerService&gt;</code> elements the actual binding
-is given by the <code>hoksso:ProtocolBinding</code> attribute, see section 2.8 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-<p>[**]: The Web Browser SSO Profile or the Holder-of-key Web Browser SSO Profile are possible profiles.</p>
-</blockquote>
-<p><a name="identity-provider-user-interface"></a></p>
-<h4 id="5.4.3.-identity-provider-user-interface">5.4.3. Identity Provider User Interface</h4>
-<p>An Identity Provider presenting information related to a Service Provider
-in its user interface during processing of an <code>&lt;saml2p:AuthnRequest&gt;</code> message
-MUST obtain this information from the
-<code>&lt;mdui:UIInfo&gt;</code> element of the Service Provider’s metadata entry.
-Implementers of this profile MUST be capable of handling display
-information stored in the <code>&lt;mdui:DisplayName&gt;</code>, <code>&lt;mdui:Logo&gt;</code>
-and the <code>&lt;mdui:Description&gt;</code> elements.</p>
-<p>An Identity Provider displaying logotypes found in a Service Provider&#39;s
-metadata MUST be able to handle embedded in-line images, as well as
-vector-based images where the height and width given in metadata should
-be interpreted as image dimensions and not the actual size.</p>
-<p><a name="authentication-context-and-level-of-assurance-handling"></a></p>
-<h4 id="5.4.4.-authentication-context-and-level-of-assurance-handling">5.4.4. Authentication Context and Level of Assurance Handling</h4>
-<p>This framework defines a number of authentication context identifiers
-(URI), where each such identifier specifies a defined Level of Assertion
-and may define specific requirements on the authentication process.
-There can be multiple authentication context URIs representing the same
-Level of Assertion, but one authentication context URI always identifies
-one defined Level of Assurance. </p>
-<p>Identity Providers SHALL exclusively use one of the requested
-authentication contexts in <code>&lt;saml2p:AuthnRequest&gt;</code> in the
-<code>&lt;saml2:AuthnContextClassRef&gt;</code> element under the
-<code>&lt;saml2p:RequestedAuthnContext&gt;</code> element, when present, to determine
-the requested authentication process and Level of Assurance. The
-Identity Provider SHALL respond with an error <code>&lt;saml2p:StatusCode&gt;</code>
-with the value <code>urn:oasis:names:tc:SAML:2.0:status:Requester</code>
-[<a href="#saml2core">SAML2Core</a>]
-if no requested authentication context is supported. If no requested
-authentication context is present in the <code>&lt;saml2p:AuthnRequest&gt;</code>,
-the Identity Provider MAY return the result of a default authentication
-process that is consistent with the Identity Providers metadata.</p>
-<p><strong>Note</strong>: The Identity Provider does not have to consider the service
-entity categories ([<a href="#eidentcat">EidEntCat</a>]) declared in the Service Provider’s
-metadata entry when determining the requested authentication context
-under which the authentication should be performed. The purpose of the
-service entity categories is primarily to support service matching in
-discovery services and attribute release policies in Identity Providers.
-Significant Identity Provider products and software are not equipped to
-use service entity category information to determine the requested
-authentication context.</p>
-<p><a name="single-sign-on-processing"></a></p>
-<h4 id="5.4.5.-single-sign-on-processing">5.4.5. Single Sign On Processing</h4>
-<p>An Identity Provider conformant to this profile MAY issue an assertion
-relying on a previously established security context (active session)
-instead of authenticating the user. However, the Identity Provider MUST
-NOT re-use an already existing security context in the following cases:</p>
-<ul class="list">
-<li><p>When the security context has expired, i.e., the time elapsed since
-the security context was established is too long given the
-SSO-policy stipulated by the federation or Identity Provider itself.</p>
-</li>
-<li><p>When the <code>&lt;saml2p:AuthnRequest&gt;</code> contains a <code>ForceAuthn</code> attribute
-with the value of <code>true</code>.</p>
-</li>
-<li><p>If the original authentication process, which led to the
-establishment of the security context, was performed using another
-Level of Assurance that what is requested in the current
-<code>&lt;saml2p:AuthnRequest&gt;</code> message.</p>
-</li>
-<li><p>If the original authentication was performed according to the Holder-of-key
-Web Browser SSO Profile, [<a href="#saml2hokprof">SAML2HokProf</a>], and
-no certificate, or a certificate not matching the certificate included
-in the <code>&lt;saml2:SubjectConfirmation&gt;</code> element of the original assertion, 
-is presented in along with the current <code>&lt;saml2p:AuthnRequest&gt;</code> message. </p>
-</li>
-<li><p>If the original authentication was performed according to the Web Browser SSO
-Profile, [<a href="#saml2prof">SAML2Prof</a>] and the current request is made 
-according to the Holder-of-key Web Browser SSO Profile, 
-[<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-</li>
-</ul>
-<p>If the Identity Provider user interface contains some sort of user
-consent, or information, concerning which attributes, or any other
-information, that is included in an assertion being issued, the Identity
-Provider SHOULD preserve this functionality if a
-<code>&lt;saml2p:AuthnRequest&gt;</code> message requesting a different set of
-attributes (or any other information) compared to what was delivered in
-the assertion at the time of establishing the security context. The
-Identity Provider may require re-authentication or display a user
-interface for consent/information in these cases.</p>
-<p><a name="authentication-responses"></a></p>
-<h2 id="6.-authentication-responses">6. Authentication Responses</h2>
-<p><a name="security-requirements"></a></p>
-<h3 id="6.1.-security-requirements">6.1. Security Requirements</h3>
-<p>The endpoint(s) at which a Service Provider receives a
-<code>&lt;saml2p:Response&gt;</code> message MUST be protected by TLS.</p>
-<p>If a Service Provider wants to make use of the Holder-of-key Web Browser SSO Profile
-it needs to provide a dedicated endpoint for this purpose, see section <a href="#sp-holder-of-key-support">2.1.2.1</a>. This endpoint MUST be configured to require a client X.509 certificate
-being presented as part of the TLS handshake (mTLS, mutual TLS), see section 2.4 of 
-[<a href="#saml2hokprof">SAML2HokProf</a>]. If the Service Provider receives a <code>&lt;saml2p:Response&gt;</code>
-on a Holder-of-key endpoint and is unable to retrieve the client X.509 certificate it MUST 
-reject the message and not create a security context for the principal, see section 2.6.6 of [<a href="#saml2hokprof">SAML2HokProf</a>].</p>
-<p>The <code>&lt;saml2p:Response&gt;</code> message issued by the Identity Provider MUST
-be signed using a <code>&lt;ds:Signature&gt;</code> element within the
-<code>&lt;saml2p:Response&gt;</code> element.</p>
-<p>The <code>&lt;saml2:Assertion&gt;</code> element issued by the Identity Provider MAY
-be signed using a <code>&lt;ds:Signature&gt;</code> element within the
-<code>&lt;saml2:Assertion&gt;</code>. If a Service Provider requires signed
-assertions, by assigning the <code>WantAssertionsSigned</code> attribute of its
-metadata record (see <a href="#service-providers">chapter 2.1.2</a>), the Identity Provider MUST sign
-assertions issued to this Service Provider (as well as the response
-message as stated above).</p>
-<p>Identity Providers SHALL utilize XML Encryption and return a
-<code>&lt;saml2:EncryptedAssertion&gt;</code> element in the <code>&lt;saml2p:Response&gt;</code>
-message. The elements <code>&lt;saml2:EncryptedID&gt;</code> and
-<code>&lt;saml2:EncryptedAttribute&gt;</code> MUST NOT be used; instead the entire
-assertion MUST be encrypted.</p>
-<p>Before performing encryption and signing, the Identity Provider SHOULD consult the Service Provider&#39;s metadata (<code>&lt;md:EncryptionMethod&gt;</code>, <code>&lt;alg:SigningMethod&gt;</code> and <code>&lt;alg:DigestMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Service Provider prefers. If the intersection is empty, or if the Service Provider has not declared any algorithms, the Identity Provider MUST use algorithms listed as mandatory by the Swedish eID Framework. For encryption, the chosen algorithm MUST also be compatible with the Service Provider&#39;s encryption key 
-declared in metadata.</p>
-<p>Service Providers SHOULD NOT accept unsolicited <code>&lt;saml2p:Response&gt;</code>
-messages (i.e., responses that are not the result of an earlier
-<code>&lt;saml2p:AuthnRequest&gt;</code> message). Service Providers that do accept
-unsolicited response messages MUST ensure, by other means, that the
-security and processing requirements of this profile (<a href="#processing-requirements">section 6.3</a>) can be fully satisfied.</p>
-<p><a name="message-content2"></a></p>
-<h3 id="6.2.-message-content">6.2. Message Content</h3>
-<p>The <code>&lt;saml2:Response&gt;</code> message MUST NOT contain a Document Type Definition (DTD).</p>
-<p>Successful response messages MUST contain exactly one <code>&lt;saml2:AuthnStatement&gt;</code> element
-and exactly one <code>&lt;saml2:AttributeStatement&gt;</code> element.</p>
-<p>The <code>&lt;saml2:Response&gt;</code> message MUST contain an <code>&lt;saml2:Issuer&gt;</code>
-element containing the unique identifier (entityID) of the issuing
-Identity Provider.</p>
-<p>The <code>AuthnInstant</code> attribute of the <code>&lt;saml2:AuthnStatement&gt;</code> element
-MUST be assigned the time when the actual authentication took place.
-This time may differ from the <code>IssueInstant</code> attribute of the assertion
-itself, which holds the time when the assertion was issued. This is
-especially important in cases of re-use of already established security
-contexts at the Identity Provider side (Single Sign On).</p>
-<p>Each identity assertion MUST have a <code>&lt;saml:Subject&gt;</code> element that
-specifies the principal that is the subject of all of the statements in
-the assertion.</p>
-<p>The value of the <code>&lt;saml:NameID&gt;</code> element under the
-<code>&lt;saml:Subject&gt;</code> element MUST hold a pseudonym identifier of the
-subject, which SHALL be:</p>
-<ul class="list">
-<li><p>Unique for the IdP – SP combination being the issuer and recipient
-for the assertion.</p>
-</li>
-<li><p>Constructed in a manner that does not reveal the registered identity
-of the subject.</p>
-</li>
-</ul>
-<p>The <code>&lt;saml2:Subject&gt;</code> element MUST contain one
-<code>&lt;saml2:SubjectConfirmation&gt;</code> element containing a <code>Method</code> attribute having the value
-of <code>urn:oasis:names:tc:SAML:2.0:cm:bearer</code> if the Web Browser SSO Profile was used,
-and <code>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</code> if the Holder-of-key Web Browser 
-SSO Profile was used. This element MUST contain a <code>&lt;saml2:SubjectConfirmationData&gt;</code> 
-element that contains at least the following:</p>
-<ul class="list">
-<li><p>An <code>InResponseTo</code> attribute matching the request’s ID.</p>
-</li>
-<li><p>A <code>Recipient</code> attribute containing the Service Provider’s assertion
-consumer service URL (see sections <a href="#message-content">5.3</a> and 
-<a href="#validation-of-destination">5.4.1</a>).</p>
-</li>
-<li><p>A <code>NotOnOrAfter</code> attribute containing a time instant at which the
-subject no longer can be confirmed.</p>
-</li>
-<li><p>An <code>Address</code> attribute containing the network address from which an attesting entity
-(user) can present the assertion.</p>
-</li>
-<li><p>If the Holder-of-key Web Browser SSO Profile was used to authenticate the
-principal a <code>&lt;ds:KeyInfo&gt;</code> element identifying the X.509 certificate presented
-to the Identity Provider. See section <a href="#message-content-requirements-for-holder-of-key">6.2.2</a> below.</p>
-</li>
-</ul>
-<p>The assertion MUST contain a <code>&lt;saml2:Conditions&gt;</code> element containing
-the following attributes and elements:</p>
-<ul class="list">
-<li><p>A <code>&lt;saml2:AudienceRestriction&gt;</code> element including the requesting
-Service Provider’s unique identifier (entityID) as an
-<code>&lt;saml2:Audience&gt;</code> value.</p>
-</li>
-<li><p>A <code>NotBefore</code> attribute specifying the earliest time instant at which
-the assertion is valid.</p>
-</li>
-<li><p>A <code>NotOnOrAfter</code> attribute specifying the time instant when the
-assertion expires.</p>
-</li>
-</ul>
-<p>An Identity Provider conformant to this profile MUST, in its issued
-assertions, include an authentication context URI indicating under which
-Level of Assurance the assertion was issued. This identifier MUST be
-placed under the <code>&lt;saml2:AuthnStatement&gt;</code> element as the value of an
-<code>&lt;saml2:AuthnContextClassRef&gt;</code> element that is part of the
-<code>&lt;saml2:AuthnContext&gt;</code> element.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnStatement</span> <span class="hljs-attr">AuthnInstant</span>=<span class="hljs-string">"2013-03-15T09:22:00"</span> <span class="hljs-attr">SessionIndex</span>=<span class="hljs-string">"b07b804c-7c29-ea16-7300-4f3d6f7928ac"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>http://id.elegnamnden.se/loa/1.0/loa3<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContextClassRef</span>&gt;</span>
-    ...
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnStatement</span>&gt;</span></code></pre><p><em>Example of how an Authentication Context URI identifier representing a
-Level of Assurance is included in an authentication statement.</em></p>
-<p>An Identity Provider that acts as a proxy for other Identity Providers SHOULD include the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element under the <code>&lt;saml2:AuthnContext&gt;</code> element. This element will contain the entityID of the Identity Provider that authenticated the principal.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnStatement</span> <span class="hljs-attr">AuthnInstant</span>=<span class="hljs-string">"2013-03-15T09:22:00"</span> <span class="hljs-attr">SessionIndex</span>=<span class="hljs-string">"b07b804c-7c29-ea16-7300-4f3d6f7928ac"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
-    ...
-    <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AuthenticatingAuthority</span>&gt;</span>http://idp.example.com/auth<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthenticatingAuthority</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnContext</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AuthnStatement</span>&gt;</span></code></pre><p><em>Example of how the entityID of an Identity Provider that provided the authentication for the principal is included in an authentication statement.</em></p>
-<p><a name="attribute-release-and-consuming-rules"></a></p>
-<h4 id="6.2.1.-attribute-release-and-consuming-rules">6.2.1. Attribute Release and Consuming Rules</h4>
-<p>An Identity Provider determines which attributes to include in the
-<code>&lt;saml2:AttributeStatement&gt;</code> element of an assertion based on the
-Service Provider requirements and its agreements with the user being
-authenticated. Service Provider attribute preferences and requirements
-are specified by the service entity categories [<a href="#eidentcat">EidEntCat</a>] and
-requested attributes in the <code>&lt;md:AttributeConsumingService&gt;</code> element
-declared in the Service Provider metadata. A service entity category
-specifies the attribute set (as defined in [<a href="#eidattributes">EidAttributes</a>]) that is
-requested for the attribute release process.</p>
-<p>An Identity Provider declares service entity categories in order to
-publish its ability to deliver attributes according to certain attribute
-sets. For all declared service entity categories, the Identity Provider
-MUST possess the ability to deliver the mandatory attributes of the
-underlying attribute set. See [<a href="#eidentcat">EidEntCat</a>] and [<a href="#eidattributes">EidAttributes</a>] for details.</p>
-<p>An Identity Provider releasing scoped attributes, see section 3.1.3 of [<a href="#eidattributes">EidAttributes</a>], MUST be authorized to release attributes with given scopes by the federation operator. An Identity Provider&#39;s authorized scopes are published in its metadata according to section <a href="#declaring-authorized-scopes">2.1.3.1</a>, &quot;<a href="#declaring-authorized-scopes">Declaring Authorized Scopes</a>&quot;. </p>
-<p>Consequently, a Service Provider consuming a scoped attribute SHOULD verify that the issuing Identity Provider has been authorized to release attributes for the given scope by asserting its presence in the Identity Provider&#39;s metadata, see section <a href="#declaring-authorized-scopes">2.1.3.1</a> and section 3.5.2 of [<a href="#saml2subjidattr">SAML2SubjIdAttr</a>]. A scoped attribute that fails this check MUST NOT be accepted by the Service Provider.</p>
-<p>The Service Provider is responsible for checking that an Identity
-Provider is capable of providing necessary attributes before sending a
-request and to verify that it received all attributes necessary for
-providing a requested service. Checks whether an Identity Provider is
-capable of fulfilling the needs of a Service Provider can be done either
-by relying on a discovery process to filter out non-conformant Identity
-Providers, and/or by examining the metadata of Identity providers. </p>
-<p>An Identity Provider receiving a request for more attributes than it can
-provide SHOULD return an assertion with the attributes it can provide
-according to its defined attribute release policy if the user has been successfully 
-authenticated, leaving it up to the Service Provider to decide how to proceed, 
-e.g., by denying service to the authenticated user, provide limited services or to use other
-resources to collect necessary attributes. However, if a Service Provider
-has expressed a specific attribute requirement using the <code>&lt;md:RequestedAttribute&gt;</code>
-element of a matching <code>&lt;md:AttributeConsumingService&gt;</code> element in its metadata
-and assigned the <code>isRequired</code>-attribute to <code>true</code>, and the Identity Provider knows that it will not be able to provide this attribute, then the Identity Provider SHOULD reject any request for authentication from that Service Provider and respond with an error.</p>
-<p>For privacy reasons, an Identity Provider SHOULD NOT release identity attributes<sup>*</sup> that are not requested by the Service Provider via its metadata declarations
- (service entity categories or <code>&lt;md:RequestedAttribute&gt;</code> elements).</p>
-<blockquote>
-<p>[*]: This requirement does not apply to attributes that are not &quot;identity&quot; attributes, for example transaction identifiers or any other attribute that does not directly belong to a user&#39;s identity.</p>
-</blockquote>
-<p><a name="message-content-requirements-for-holder-of-key"></a></p>
-<h4 id="6.2.2.-message-content-requirements-for-holder-of-key">6.2.2. Message Content Requirements for Holder-of-key</h4>
-<p>When the Holder-of-key Web Browser SSO Profile has been used during the authentication
-of the user, information about the X.509 certificate presented by the user MUST be 
-included in a <code>&lt;ds:KeyInfo&gt;</code> element placed in the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element. Section 2.4 of [<a href="#saml2hokap">SAML2HokAP</a>] defines the requirements for this.</p>
-<p>This profile adds the following requirements to what is specified in [<a href="#saml2hokap">SAML2HokAP</a>]:</p>
-<p>The user X.509 certificate SHOULD be represented using a <code>&lt;ds:X509Certificate&gt;</code> element
-in all cases, except for the cases when this certificate contains identity information 
-about the subject that is not represented as SAML attributes in the 
-<code>&lt;saml2:AttributeStatement&gt;</code> element.
-The reason for this is to ensure the privacy of the user and not release identity information that is not requested by the Service Provider (see section <a href="#attribute-release-and-consuming-rules">6.2.1</a> above).</p>
-<p>In these cases the <code>&lt;ds:X509Certificate&gt;</code> MUST NOT be used, and the Identity Provider 
-SHOULD include a <code>&lt;ds:KeyValue&gt;</code> representing the public key of the user certificate.</p>
-<p><a name="processing-requirements2"></a></p>
-<h3 id="6.3.-processing-requirements">6.3. Processing Requirements</h3>
-<p>This profile mandates a correct processing of a <code>&lt;saml2p:Response&gt;</code>
-message in order to ensure proper protection from the security threats
-described in [<a href="#saml2sec">SAML2Sec</a>].
-Processing requirements are listed in [<a href="#saml2core">SAML2Core</a>],
-[<a href="#saml2prof">SAML2Prof</a>] and [<a href="#saml2sec">SAML2Sec</a>].
-This document will list the necessary requirements that apply to this
-profile.</p>
-<p>After the Service Provider has encrypted the assertion from the received
-response message the following requirements apply. Any verification that
-fails MUST lead to that the Service Provider rejects the response
-message and does not use the assertion.</p>
-<p>Some of the processing requirements below are defined in order to
-protect from MITM- or MITB-attacks<sup>*</sup> were unsigned authentication
-requests may be changed before being sent to the Identity Provider.
-However, a Service Provider MUST implement all of the specified
-processing requirements even if it sends signed authentication request
-messages.</p>
-<blockquote>
-<p>[*]: MITM stands for ”man in the middle” and MITB stands for ”man in the browser”.</p>
-</blockquote>
-<p><a name="signature-validation"></a></p>
-<h4 id="6.3.1.-signature-validation">6.3.1. Signature Validation</h4>
-<p>The signature present on the <code>&lt;saml2p:Response&gt;</code> message, and
-optionally on the <code>&lt;saml2:Assertion&gt;</code>, MUST be successfully
-verified.</p>
-<p>The public key being used to verify the signature MUST appear in the
-issuing Identity Provider’s metadata record (as a
-<code>&lt;ds:X509Certificate&gt;</code> under the <code>&lt;ds:KeyInfo&gt;</code> element).</p>
-<p><a name="subject-confirmation"></a></p>
-<h4 id="6.3.2.-subject-confirmation">6.3.2. Subject Confirmation</h4>
-<p>Based on the <code>InResponseTo</code> attribute of the
-<code>&lt;saml2:SubjectConfirmationData&gt;</code> the Service Provider MUST be able
-to obtain the corresponding <code>&lt;saml2p:AuthnRequest&gt;</code> message, or a
-secure context containing corresponding information from the request
-(for future processing of the assertion).</p>
-<p>The <code>Recipient</code> attribute from the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element 
-MUST match the location to which the <code>&lt;saml2p:Response&gt;</code> message was delivered 
-<strong>and</strong> match the value the <code>AssertionConsumerServiceURL</code> attribute included in the
-request message, or if this attribute was not provided in the request
-message, the default response location specified in the Service
-Provider’s metadata entry, as described in <a href="#validation-of-assertion-consumer-addresses">section 5.4.2</a>.</p>
-<p>The time from the <code>NotOnOrAfter</code> attribute from the
-<code>&lt;saml2:SubjectConfirmationData&gt;</code> MUST NOT have passed compared with
-the time instant at which the subject is confirmed (i.e., when the
-assertion is validated). A reasonable allowable clock skew between the
-providers should be taken in account.</p>
-<p>If the <code>Address</code> attribute is assigned to the
-<code>&lt;saml2:SubjectConfirmationData&gt;</code> element, the Service Provider MAY
-choose to check the user agent’s client address against it. Practical
-issues regarding the Service Provider’s network setup and the risk of
-introducing false negatives makes this an optional step in the
-validation phase.</p>
-<p>If the <code>&lt;saml2:SubjectConfirmation&gt;</code> element has a <code>Method</code> set to
-<code>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</code> its containing 
-<code>&lt;saml2:SubjectConfirmationData&gt;</code> element MUST be processed according to
-section 2.5 of [<a href="#saml2hokap">SAML2HokAP</a>]. The Service Provider MUST also
-be able to verify the holder-of-key assertion if the <code>&lt;saml2:SubjectConfirmationData&gt;</code>
-element contains a <code>&lt;ds:KeyValue&gt;</code> element, see <a href="#message-content-requirements-for-holder-of-key">6.2.2</a>.</p>
-<p><a name="conditions"></a></p>
-<h4 id="6.3.3.-conditions">6.3.3. Conditions</h4>
-<p>The Service Provider MUST assert that the value of the
-<code>&lt;saml2:Audience&gt;</code> element under the
-<code>&lt;saml2:AudienceRestriction&gt;</code> element matches the unique entityID of
-the Service Provider.</p>
-<p>The Service Provider MUST verify that the time instant at which the
-assertion is validated is within the range given by the <code>NotBefore</code> and
-<code>NotOnOrAfter</code> attributes of the <code>&lt;saml2:Conditions&gt;</code> element
-(allowing for a reasonable clock skew). See also the processing of the
-<code>NotOnOrAfter</code> attribute in <a href="#subject-confirmation">section 6.3.2</a>.</p>
-<p><a name="the-authentication-statement"></a></p>
-<h4 id="6.3.4.-the-authentication-statement">6.3.4. The Authentication Statement</h4>
-<p>The Service Provider MUST assert that the <code>&lt;saml2:AuthnStatement&gt;</code>
-contains a <code>&lt;saml2:AuthnContext&gt;</code> element that holds a
-<code>&lt;saml2:AuthnContextClassRef&gt;</code> element having as its value the
-authentication context URI indicating under which Level of Assurance the
-authentication was performed. If the Service Provider declared one, or more, 
-<code>&lt;saml2:AuthnContextClassRef&gt;</code> elements under the <code>&lt;saml2p:RequestedAuthnContext&gt;</code>
-element of the authentication request (see <a href="#message-content">section 5.4</a>), 
-the received authentication context URI MUST match one of the declared 
-authentication context URI:s from the request. If not, the Service Provider 
-MUST reject the assertion<sup>*</sup>.</p>
-<blockquote>
-<p>[*]: If the Service Provider does not declare an authentication context URI
-in the authentication request it should be prepared to receive any of the
-authentication context URI:s declared by the Identity Provider in its metadata
-record (see <a href="#identity-providers">section 2.1.3</a>).</p>
-</blockquote>
-<p><a name="general-security-validation"></a></p>
-<h4 id="6.3.5.-general-security-validation">6.3.5. General Security Validation</h4>
-<p>In order to protect itself from replay attacks, the Service Provider
-MUST ensure that the same assertion is not processed more than once
-within the time it is valid (with respect to the <code>NotOnOrAfter</code> attribute
-of the <code>&lt;saml2:Conditions&gt;</code> element).</p>
-<p>In order to prevent stolen assertions and user impersonation, the
-Service Provider SHOULD implement a validation that rejects an assertion
-if the time given it its <code>IssueInstant</code> attribute compared to the time
-when the response message is received is too great. This time is
-typically on the order of seconds, and limits the time window when a
-stolen assertion could be used.</p>
-<p>If the Service Provider included the attribute <code>ForceAuthn</code> with a value
-of <code>true</code> in the authentication request, the Service Provider SHOULD
-ensure that the <code>AuthnInstant</code> attribute of the
-<code>&lt;saml2:AuthnStatement&gt;</code> element is greater than the time when the
-request was sent (allowing for a reasonable clock skew).</p>
-<p>A reasonable clock skew according to this profile is between 3 and 5 minutes in either direction.</p>
-<p><a name="error-responses"></a></p>
-<h3 id="6.4.-error-responses">6.4. Error Responses</h3>
-<p>If the Identity Provider returns an error, it MUST NOT include any
-assertions in the <code>&lt;saml2p:Response&gt;</code> message.</p>
-<p>An Identity Provider conformant with this profile SHOULD NOT make use of
-any other <code>&lt;saml2p:StatusCode&gt;</code> values than those specified in
-section 3.2.2.2 of
-[<a href="#saml2core">SAML2Core</a>] or in section 3.1.4 of [<a href="#eidregistry">EidRegistry</a>]. 
-The top-level <code>&lt;saml2p:StatusCode&gt;</code> value may only be one of the following error
-identifiers:</p>
-<ul class="list">
-<li><p><code>urn:oasis:names:tc:SAML:2.0:status:Requester</code> – The request could not
-be performed due to an error on the part of the Service Provider.</p>
-</li>
-<li><p><code>urn:oasis:names:tc:SAML:2.0:status:Responder</code> – The request could not
-be performed due to an error on the part of the Identity Provider.</p>
-</li>
-<li><p><code>urn:oasis:names:tc:SAML:2.0:status:VersionMismatch</code> – The Identity
-Provider could not process the request because the version of the
-request message was incorrect.</p>
-</li>
-</ul>
-<p>If the user cancels an authentication process the Identity Provider
-SHOULD indicate this by assigning the second-level status code to
-<code>http://id.elegnamnden.se/status/1.0/cancel</code>.</p>
-<p>If an Identity Provider displays information describing an error in its
-user interface it MUST also offer ways for the end user to confirm this
-information (for example, by including an OK-button). When the end user
-acknowledges taking part of the information (i.e., clicks on the OK-button),
-the <code>&lt;saml2p:Response&gt;</code> message is posted back to the Service
-Provider according to the HTTP POST binding [<a href="#saml2bind">SAML2Bind</a>].</p>
-<p>If an Identity Provider detects suspicious fraudulent behaviour or if any of its security checks alerts a (possible) fraud, the Identity Provider MUST NOT issue an assertion but instead display an error message. After the end user confirms this error message, the error message posted back to the Service Provider SHOULD contain a second-level status code set to <code>http://id.elegnamnden.se/status/1.0/fraud</code> or <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> (depending on whether the Identity Provider aborted the authentication due to a determined or suspected fraud).</p>
-<p><a name="authentication-for-signature"></a></p>
-<h2 id="7.-authentication-for-signature">7. Authentication for Signature</h2>
-<p>“DSS Extension for Federated Central Signing Services”, [<a href="#eiddss">EidDSS</a>],
-defines an extension to the OASIS DSS protocol for providing centralized
-Signature Services within the Swedish eID Framework. This specification
-defines the communication between a <em>Signature Requestor</em><sup>*</sup> and a
-Signature Service, but does not cover SAML specific requirements
-regarding the user authentication phase that is part of the signature
-process.</p>
-<p>This section defines requirements on the SAML authentication process
-when authentication is requested by a Signature Service, acting as a
-SAML Service Provider. All requirements regarding user authentication
-specified earlier in this profile are still valid. This section extends
-these requirements for the “authentication for signature” process.</p>
-<blockquote>
-<p>[*]: A Signature Requestor is a Service Provider within the federation to which the user previously has logged in to and from where the user initiates a signature operation.</p>
-</blockquote>
-<p><a name="authentication-requests2"></a></p>
-<h3 id="7.1.-authentication-requests">7.1. Authentication Requests</h3>
-<p>Authentication requests from a Signature Service SHALL meet the
-following requirements:</p>
-<ul class="list">
-<li><p>The <code>ForceAuthn</code> attribute of the <code>&lt;saml2p:AuthnRequest&gt;</code> element
-MUST be set to <code>true</code>.</p>
-</li>
-<li><p>The <code>&lt;saml2p:AuthnRequest&gt;</code> element MUST be signed. This MUST
-also be indicated in the Signature Service metadata record using the
-<code>AuthnRequestsSigned</code> attribute (see <a href="#signature-service">section 2.1.4</a>).</p>
-</li>
-</ul>
-<p>If the receiving Identity Provider has declared that it wishes to receive principal selection information about the signer (see <a href="#principal-selection">section 5.3.3</a>), and the Signature Service has received any of the requested attribute values in the <code>Signer</code> element of the <code>SignRequest</code> ([<a href="#eiddss">EidDSS</a>]), the Signature Service SHOULD include those attribute values in a <code>&lt;psc:PrincipalSelection&gt;</code> extension of the authentication request. </p>
-<p>It is RECOMMENDED that the <code>&lt;saml2p:Scoping&gt;</code> element containing a <code>&lt;saml2p:RequesterID&gt;</code> element holding the entityID of the Service Requestor is included in <code>&lt;saml2p:AuthnRequest&gt;</code> messages generated by a Signature Service.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2p:Scoping</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2p:RequesterID</span>&gt;</span>http://www.origsp.com/sp<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:RequesterID</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2p:Scoping</span>&gt;</span></code></pre><p><em>Example when the <code>&lt;saml2p:RequesterID&gt;</code> element is used to inform the Identity Provider about which Service Provider that requested the signature associated with this request for authentication.</em></p>
-<blockquote>
-<p>The reason for this recommendation is that an Identity Provider may adapt user interfaces or authentication procedures to different Service Providers based on either static configuration or on information found in the Service Provider&#39;s metadata. It can therefore be useful for an Identity Provider to know which Service Provider that requested the signature (<em>Signature Requestor</em>) that caused a Signature Service to request authentication. The Identity Provider may use this information to maintain the same user experience and procedures regardless of whether authentication is requested directly by the Service Provider, or by a Signature Service as a result of a signature request from the same Service Provider.</p>
-</blockquote>
-<p>An Identity Provider that accepts an <code>&lt;saml2p:AuthnRequest&gt;</code> message
-from a Service Provider that has indicated that it is a Signature
-Service<sup>*</sup> MUST provide a user interface that is indicating that the
-end user is performing a signature.</p>
-<blockquote>
-<p>[*]: An Identity Provider identifies a Service Provider as a Signature Service if it declares the <code>http://id.elegnamnden.se/st/1.0/sigservice</code> URI as a service type entity category in its metadata (see <a href="#signature-service">2.1.4</a>).</p>
-</blockquote>
-<p><a name="requesting-display-of-signature-message"></a></p>
-<h4 id="7.1.1.-requesting-display-of-signature-message">7.1.1. Requesting Display of Signature Message</h4>
-<p>[<a href="#eiddssprofile">EidDSS_Profile</a>] specifies that a Signature Requestor may include a
-<code>SignMessage</code> element (as defined by [<a href="#eiddss">EidDSS</a>]) in a signature request.
-This element holds a message that the Identity Provider, which is
-responsible for “authentication for signature”, should present to the
-user that is performing the signature.</p>
-<p>A Signature Service MAY request the Identity Provider to show a sign
-message to the user by including the <code>SignMessage</code> element from the
-signature request as a child element to an <code>&lt;saml2p:Extensions&gt;</code>
-element in the <code>&lt;saml2p:AuthnRequest&gt;</code> message (see section 3.2.1 of
-[<a href="#saml2core">SAML2Core</a>]).</p>
-<p>All Identity Providers compliant with this profile MUST be able to parse and understand
-the <code>SignMessage</code> extension.</p>
-<p>If the <code>Message</code>-element of the <code>SignMessage</code> is to be encrypted, the Service Provider SHOULD consult the Identity Provider&#39;s metadata (<code>&lt;md:EncryptionMethod&gt;</code> elements) to determine the intersection of algorithms, key sizes and other parameters as defined by particular algorithms that it supports and that the Identity Provider prefers. If the intersection is empty, or if the Identity Provider has not declared any algorithms, the Service Provider MUST use one of the mandatory algorithms defined in the Swedish eID Framework during the encryption operation, which is compatible with the Identity Provider&#39;s encryption key declared in metadata.</p>
-<p>If an Identity Provider that has ways of determining the principal&#39;s identity before displaying
-a sign message receives a <code>&lt;psc:PrincipalSelection&gt;</code> extension in  the authentication request 
-it SHOULD ensure that the contents of the <code>&lt;psc:PrincipalSelection&gt;</code> extension matches the 
-principal identity. If there is a mismatch, the Identity Provider MUST NOT display the
-sign message, and if the request states that the sign message must be displayed, fail with
-an error response where the second-level status code is set to
-<code>urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal</code> ([<a href="#saml2core">SAML2Core</a>]).</p>
-<blockquote>
-<p>Typical scenarios where the above requirement apply is for the Swedish eIDAS connector that first authenticates a principal and then displays the sign message, and for Identity Providers that prompt the user for its user identity as part of its authentication scheme. In those scenarios the Identity Providers must compare the principal identity with the contents of <code>&lt;psc:PrincipalSelection&gt;</code>, if received in the authentication request. </p>
-</blockquote>
-<p>Identity Providers processing a request containing a <code>SignMessage</code> extension SHALL meet
-the following requirements (in addition to other general requirements associated with requests 
-from signature services):</p>
-<ul class="list">
-<li><p>If the <code>MustShow</code> attribute of the <code>SignMessage</code> extension is set, the Identity Provider
-MUST fail with an error response if the message, for some reason, can not be displayed 
-to the user.</p>
-</li>
-<li><p>The Identity Provider MUST display the sign message to the user in a manner that is consistent 
-with the data format of the sign message. If necessary, the Identity Provider MUST process 
-defined filtering rules on the message. If the present message format is not supported or the 
-sign message for any reason cannot be displayed in a proper manner, the Identity Provider must
-return an error response.</p>
-</li>
-<li><p>If authentication and sign message confirmation by the user was successful, the Identity Provider 
-MUST include the <code>signMessageDigest</code> attribute (see section 3.2.4 of [<a href="#eidattributes">EidAttributes</a>]) 
-in the assertion that is issued.</p>
-</li>
-<li><p>The Identity Provider MUST NOT return an assertion without performing an authentication process 
-consistent with the requested authentication context which includes display of a sign message,
-even if the request has no present <code>ForceAuthn</code> attribute or includes a <code>ForceAuthn</code> attribute set 
-to the value <code>false</code>.  </p>
-</li>
-</ul>
-<p><a name="requesting-scal2-signature-activation-data"></a></p>
-<h4 id="7.1.2.-requesting-scal2-signature-activation-data">7.1.2. Requesting SCAL2 Signature Activation Data</h4>
-<p>The type of signature requested in a signature request is, according to [<a href="#eiddssprofile">EidDSS_Profile</a>], specified by the <code>CertType</code> attribute of the <code>&lt;CertRequestProperties&gt;</code> element. When the value of this attribute is set to <code>QC/SSCD</code>, the requested signature is a Qualified Signature created in a Qualified Signature Creation Device (QSCD). To achieve this level of signature the Authentication Request MUST include a request for Signature Activation Data (SAD) for Sole Control Assurance Level 2 (SCAL2) in accordance with the &quot;Signature Activation Protocol for Federated Signing&quot; [<a href="#sigsap">SigSAP</a>], and MUST include the <code>SignMessage</code> extension (as described above).</p>
-<p>As pointed out in <a href="#identity-providers">section 2.1.3</a> an Identity Provider that supports processing of SAD requests and issuance of SAD-attributes SHALL advertise this by declaring the service property entity category <code>http://id.elegnamnden.se/sprop/1.0/scal2</code> in its metadata. An Identity Provider that has declared this entity category MUST return a SAD attribute in an issued assertion if the corresponding <code>&lt;saml2p:AuthnRequest&gt;</code> message contains the <code>&lt;sap:SADRequest&gt;</code> extension.</p>
-<p>A SAD returned from the Identity Provider MUST have a signature which can be verified using a certificate from the Identity Provider&#39;s metadata entry. The signature algorithm used to sign the SAD MUST be equivalent to the algorithm used to sign the responses and assertions from the Identity Provider.</p>
-<p>Verification of a received SAD-attribute MUST follow the verification rules specified in section 3.2.3 of [<a href="#sigsap">SigSAP</a>].</p>
-<p><a name="authentication-responses2"></a></p>
-<h3 id="7.2.-authentication-responses">7.2. Authentication Responses</h3>
-<p>By including the <code>signMessageDigest</code> attribute (see section 3.2.4 of [<a href="#eidattributes">EidAttributes</a>]) 
-in the SAML assertion, the Identity Provider asserts that it has successfully displayed the sign message
-received in the request for the user and that the user has accepted to sign under the context of this sign message. This attribute MUST be included in the issued assertion if a sign message was displayed for, and accepted by, the user.</p>
-<p><a name="cryptographic-algorithms"></a></p>
-<h2 id="8.-cryptographic-algorithms">8. Cryptographic Algorithms</h2>
-<p>This section lists the requirements for crypto algorithm support for being compliant with this profile.</p>
-<p>For signature and encryption keys the following requirements apply:</p>
-<ul class="list">
-<li>RSA public keys MUST be at least 2048 bits in length. 3072 bits or more is RECOMMENDED.</li>
-<li>EC public keys MUST be at least 256 bits in length (signature only).<ul class="list">
-<li>The curves NIST Curve P-256, NIST Curve P-384 and NIST Curve P-521 MUST be supported ([<a href="#rfc5480">RFC5480</a>]).</li>
-</ul>
-</li>
-</ul>
-<p>Services conforming to this profile MUST support the mandatory algorithms below, and SHOULD support the algorithms listed as optional.</p>
-<p>The sender of a secure message MUST NOT use an algorithm that is not listed as mandatory in the sections below, unless it is explicitly declared by the peer in its metadata (see [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>]). </p>
-<p>A service processing a message in which an algorithm not listed below has been used MUST refuse to accept the message and respond with an error, unless this algorithm has been declared as preferred or supported by the service in its metadata entry.</p>
-<blockquote>
-<p>This profile does not specify a complete list of blacklisted algorithms. However, there is a need to explicitly point out that the commonly used algorithms SHA-1 for digests and RSA PKCS#1 v1.5 for key transport are considered broken and SHOULD not be used or accepted.</p>
-</blockquote>
-<p>The algorithms below are defined in [<a href="#xmlenc">XMLEnc</a>], [<a href="#xmldsig">XMLDSig</a>] and [<a href="#rfc4051">RFC4051</a>].</p>
-<p><a name="digest-algorithms"></a></p>
-<h3 id="8.1.-digest-algorithms">8.1. Digest Algorithms</h3>
-<p><strong>Mandatory:</strong></p>
-<ul class="list">
-<li>SHA-256, <code>http://www.w3.org/2001/04/xmlenc#sha256</code></li>
-</ul>
-<p><strong>Optional:</strong></p>
-<ul class="list">
-<li>SHA-384, <code>http://www.w3.org/2001/04/xmldsig-more#sha384</code></li>
-<li>SHA-512, <code>http://www.w3.org/2001/04/xmlenc#sha512</code></li>
-</ul>
-<p><a name="signature-algorithms"></a></p>
-<h3 id="8.2.-signature-algorithms">8.2. Signature Algorithms</h3>
-<p><strong>Mandatory:</strong></p>
-<ul class="list">
-<li>RSA-SHA256, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</code></li>
-<li>ECDSA-SHA256, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256</code></li>
-</ul>
-<p><strong>Optional:</strong></p>
-<ul class="list">
-<li>RSA-SHA384, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha384</code></li>
-<li>RSA-SHA512, <code>http://www.w3.org/2001/04/xmldsig-more#rsa-sha512</code></li>
-<li>ECDSA-SHA384, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384</code></li>
-<li>ECDSA-SHA512, <code>http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512</code></li>
-</ul>
-<p><a name="block-encryption-algorithms"></a></p>
-<h3 id="8.3.-block-encryption-algorithms">8.3. Block Encryption Algorithms</h3>
-<p><strong>Mandatory:</strong></p>
-<ul class="list">
-<li>AES128-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes128-cbc</code></li>
-<li>AES192-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes192-cbc</code></li>
-<li>AES256-CBC, <code>http://www.w3.org/2001/04/xmlenc#aes256-cbc</code></li>
-</ul>
-<p><strong>Optional:</strong></p>
-<ul class="list">
-<li>AES128-GCM, <code>http://www.w3.org/2009/xmlenc11#aes128-gcm</code></li>
-<li>AES192-GCM, <code>http://www.w3.org/2009/xmlenc11#aes192-gcm</code></li>
-<li>AES256-GCM, <code>http://www.w3.org/2009/xmlenc11#aes256-gcm</code></li>
-</ul>
-<p><strong>Note:</strong> The AES-CBC algorithm has been reported to have vulnerabilities, but these weaknesses can not be exploited when using signed SAML messages. Also, the support for AES-GCM in SAML software is not sufficiently spread at the time of writing. Therefore, the current version of this profile specifies AES-CBC as the default block encryption algorithm.</p>
-<p>Services supporting the AES-GCM algorithm SHOULD indicate this in its metadata.</p>
-<pre class="hljs"><code>...
-<span class="hljs-tag">&lt;<span class="hljs-name">md:KeyDescriptor</span> <span class="hljs-attr">xmlns:md</span>=<span class="hljs-string">"urn:oasis:names:tc:SAML:2.0:metadata"</span> <span class="hljs-attr">use</span>=<span class="hljs-string">"encryption"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">ds:KeyInfo</span> <span class="hljs-attr">xmlns:ds</span>=<span class="hljs-string">"http://www.w3.org/2000/09/xmldsig#"</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">ds:X509Data</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">ds:X509Certificate</span>&gt;</span>MIIE+DC...SpWg==<span class="hljs-tag">&lt;/<span class="hljs-name">ds:X509Certificate</span>&gt;</span>
-    <span class="hljs-tag">&lt;/<span class="hljs-name">ds:X509Data</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">ds:KeyInfo</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">"http://www.w3.org/2009/xmlenc11#aes256-gcm"</span>/&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">"http://www.w3.org/2009/xmlenc11#aes128-gcm"</span>/&gt;</span>
-  ...
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:KeyDescriptor</span>&gt;</span></code></pre><p><em>Example of how a service announces that it has support for AES-GCM and wishes peers to use these algorithms when encrypting for the service.</em></p>
-<p><a name="key-transport-algorithms"></a></p>
-<h3 id="8.4.-key-transport-algorithms">8.4. Key Transport Algorithms</h3>
-<p><strong>Mandatory:</strong></p>
-<ul class="list">
-<li>RSA-OAEP-MGF1P, <code>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</code><ul class="list">
-<li>Key transport digest: SHA-1 (<code>http://www.w3.org/2000/09/xmldsig#sha1</code>)</li>
-</ul>
-</li>
-</ul>
-<p>For interoperability reasons the current version of this profile specifies the RSA-OAEP-MGF1P algorithm as the default key transport algorithms. This algorithm&#39;s padding method defaults to the use of SHA-1 as a digest algorithm and also uses the &quot;MGF1 with SHA-1&quot; mask generation function<sup>*</sup>.</p>
-<p><strong>Optional:</strong></p>
-<ul class="list">
-<li>RSA-OAEP-MGF1P, <code>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</code><ul class="list">
-<li>Key transport digest: Any of the digest methods listed as mandatory or optional in section <a href="#digest-algorithms">8.1</a>.</li>
-</ul>
-</li>
-</ul>
-<p>A service wishing to receive encrypted messages where SHA-1 is not used as the key transport digest SHOULD indicate this in its metadata using the <code>&lt;md:EncryptionMethod&gt;</code> element as the example below.</p>
-<pre class="hljs"><code>...
-<span class="hljs-tag">&lt;<span class="hljs-name">md:EncryptionMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">"http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">ds:DigestMethod</span> <span class="hljs-attr">Algorithm</span>=<span class="hljs-string">"http://www.w3.org/2001/04/xmlenc#sha256"</span>/&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">md:EncryptionMethod</span>&gt;</span>
-...</code></pre><p><em>Example of how a service announces that it wishes that the peer uses SHA-256 as the key transport digest when encrypting using RSA-OAEP-MGF1P.</em></p>
-<blockquote>
-<p>[*]: Note that the use if SHA-1 in this context (both as digest algoritm and as mask generation function) is limited to providing randomness of padding data and as a hash over optional OAEP parameter data which typically is an empty string. It is not used as a hash function to assert the integrity of the encrypted data. No weaknesses of SHA-1 is is known to be relevant to its use in this context.</p>
-</blockquote>
-<p><a name="normative-references"></a></p>
-<h2 id="9.-normative-references">9. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997.</a></p>
-</blockquote>
-<p><a name="xmlenc"></a>
-<strong>[XMLEnc]</strong></p>
-<blockquote>
-<p><a href="https://www.w3.org/TR/xmlenc-core1/">D. Eastlake et al. XML Encryption Syntax and Processing. W3C Recommendation, April 2013</a>.</p>
-</blockquote>
-<p><a name="xmldsig"></a>
-<strong>[XMLDSig]</strong></p>
-<blockquote>
-<p><a href="https://www.w3.org/TR/xmldsig-core1/">D. Eastlake et al. XML-Signature Syntax and Processing, Version 1.1. W3C Recommendation, April 2013</a>.</p>
-</blockquote>
-<p><a name="saml2core"></a>
-<strong>[SAML2Core]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
-Assertion Markup Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2errata05"></a>
-<strong>[SAML v2.0 Errata 05]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/errata05/os/saml-v2.0-errata05-os.html">SAML Version 2.0 Errata 05. 01 May 2012. OASIS Approved
-Errata</a>.</p>
-</blockquote>
-<p><a name="saml2bind"></a>
-<strong>[SAML2Bind]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf">OASIS Standard, Bindings for the OASIS Security Assertion Markup
-Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2prof"></a>
-<strong>[SAML2Prof]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf">OASIS Standard, Profiles for the OASIS Security Assertion Markup
-Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2meta"></a>
-<strong>[SAML2Meta]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">OASIS Standard, Metadata for the OASIS Security Assertion Markup
-Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2sec"></a>
-<strong>[SAML2Sec]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf">Security and Privacy Considerations for the OASIS Security Assertion
-Markup Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2iap"></a>
-<strong>[SAML2IAP]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html">SAML V2.0 Identity Assurance Profiles Version 1.0, 05 November
-2010</a>.</p>
-</blockquote>
-<p><a name="saml2metaiop"></a>
-<strong>[SAML2MetaIOP]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf">OASIS Standard, SAML V2.0 Metadata Interoperability Profile Version 1.0, October 2019</a>.</p>
-</blockquote>
-<p><a name="saml2metaui"></a>
-<strong>[SAML2MetaUI]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html">OASIS Draft, SAML V2.0 Metadata Extensions for Login and Discovery
-User Interface Version 1.0, April 2012</a></p>
-</blockquote>
-<p><a name="saml2metaattr"></a>
-<strong>[SAML2MetaAttr]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html">OASIS Committee Specification, SAML V2.0 Metadata Extension for
-Entity Attributes Version 1.0, August
-2009</a>.</p>
-</blockquote>
-<p><a name="saml2metaalg"></a>
-<strong>[SAML2MetaAlgSupport]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupport.html">SAML v2.0 Metadata Profile for Algorithm Support Version 1.0, 21 February 2011</a>.</p>
-</blockquote>
-<p><a name="entcat"></a>
-<strong>[EntCat]</strong></p>
-<blockquote>
-<p><a href="https://tools.ietf.org/html/rfc8409">RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types</a>.</p>
-</blockquote>
-<p><a name="idpdisco"></a>
-<strong>[IdpDisco]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf">OASIS Committee Specification, Identity Provider Discovery Service
-Protocol and Profile, March
-2008</a>.</p>
-</blockquote>
-<p><a name="saml2subjidattr"></a>
-<strong>[SAML2SubjIdAttr]</strong></p>
-<blockquote>
-<p><a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf">OASIS Committee Specification, SAML V2.0 Subject Identifier Attributes Profile Version 1.0, January 2019</a>.</p>
-</blockquote>
-<p><a name="saml2hokprof"></a>
-<strong>[SAML2HokProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.pdf">OASIS Committee Specification, SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0, August 2010</a>.</p>
-</blockquote>
-<p><a name="saml2hokap"></a>
-<strong>[SAML2HokAP]</strong></p>
-<blockquote>
-<p><a href="https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key.pdf">OASIS Committee Specification, SAML V2.0 Holder-of-Key Assertion Profile Version 1.0, January 2010</a>.</p>
-</blockquote>
-<p><a name="eidtillit"></a>
-<strong>[EidTillit]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digital-identitet/e-legitimering/tillitsnivaer/tillitsramverket">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidentcat"></a>
-<strong>[EidEntCat]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eiddss"></a>
-<strong>[EidDSS]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="seiddssprofile"></a>
-<strong>[EidDSS_Profile]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="sigsap"></a>
-<strong>[SigSAP]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="principalsel"></a>
-<strong>[PrincipalSel]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/14_-_Principal_Selection_in_SAML_Authentication_Requests.html">Principal Selection in SAML Authentication Requests</a>.</p>
-</blockquote>
-<p><a name="rfc4051"></a>
-<strong>[RFC4051]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc4051.txt">IETF RFC 4051, Additional XML Security Uniform Resource Identifiers, April 2005</a>.</p>
-</blockquote>
-<p><a name="rfc5480"></a>
-<strong>[RFC5480]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc5480.txt">IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information, March 2009</a>.</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="10.-changes-between-versions">10. Changes between versions</h2>
-<p><strong>Changes between version 1.7 and 1.8:</strong></p>
-<ul class="list">
-<li>Section 7.1.2 was updated to state that the requirement to include both a SAD and a SignMessage extension only applies when the requested CertType is &quot;QC/SSCD&quot;. Voluntary use of SAD for other types of signatures (e.g. non qualified signatures) does not automatically trigger a requirement to include SignMessage.</li>
-</ul>
-<p><strong>Changes between version 1.6 and 1.7:</strong></p>
-<ul class="list">
-<li><p>Sections 2.1.2 and 2.1.3 were updated with clarifications for how a Service Provider declares requested attributes and how an Identity Provider declares its ability to deliver attributes.</p>
-</li>
-<li><p>Section 6.2.1, &quot;Attribute Release and Consuming Rules&quot;, was updated with a privacy requirement that tells that an Identity Provider must not release identity attributes not requested by the Service Provider.</p>
-</li>
-<li><p>Section 2.1.3.1, &quot;Declaring Authorized Scopes&quot;, was introduced in order to define how an Identity Provider declares authorized scopes. Section 6.2.1, &quot;Attribute Release and Consuming Rules&quot;, was updated with release and consumption rules for scoped attributes.</p>
-</li>
-<li><p>Support for the Holder-of-key Web Browser SSO Profile has been added.</p>
-</li>
-<li><p>Removed text in section 7, &quot;Authentication for Signature&quot;, regarding the use of the deprecated sigmessage URI:s.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.5 and 1.6:</strong></p>
-<ul class="list">
-<li>In order to facilitate algorithm interoperability between peers additions concerning &quot;Metadata Profile for Algorithm Support&quot; [<a href="#saml2metaalg">SAML2MetaAlgSupport</a>] was added. Section 2.1.1 was updated with a section defining how preferred algorithms are declared in metadata, and sections 5.2, 6.1 and 7.2.1 was updated with requirements for algorithm selection during signing and encryption.</li>
-<li>Section 5.3, &quot;Message Content&quot;, was re-structured with sub-chapters for requested authentication contexts, scoping and principal selection.</li>
-<li>The <code>PrincipalSelection</code> and <code>RequestedPrincipalSelection</code> extensions were introduced to sections 2.1.3, 5.3.3 and 7.2.</li>
-<li>The link for the &quot;Tillitsramverk för Svensk e-legitimation&quot; specification was updated.</li>
-<li>This profile is no longer normatively dependent upon SAML2Int. Therefore, the profile has been updated with requirements that previously was implicit (due to the normative dependency to SAML2Int).</li>
-<li>Section 8, &quot;Cryptographic Algorithms&quot;, was introduced in order to clearly define the algorithm requirements for services that are conformant to this profile.</li>
-<li>Section 2.1.1 was updated with elaborations concerning certificates in metadata.</li>
-<li><p>Section 7.2.1 was updated with a requirement that ensures that a sign message is only displayed to the intended user.</p>
-</li>
-<li><p>Section 7, &quot;Authentication for Signature&quot;, was updated where &quot;Sign Message Authentication Context URI&quot; were deprecated
-and the use of the <code>signMessageDigest</code> attribute was introduced.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.4 and 1.5:</strong></p>
-<ul class="list">
-<li>Section 2.1.3 &quot;Identity Providers&quot;, was extended to include requirements on metadata to signal support for the SAP (Signature Activation Protocol).</li>
-<li>Section 7.2, &quot;Authentication Requests&quot;, was extended to recommend the usage of the <code>&lt;saml2p:RequesterID&gt;</code> element within <code>&lt;saml2p:Scoping&gt;</code>. The reason for this recommendation is that Identity Providers may need information about the &quot;Signature Requestor&quot;, i.e., the Service Provider that requested the signature that caused a Signature Service to request authentication.</li>
-<li>Section 6.3.4, &quot;The Authentication Statement&quot;, contained a requirement about how to process a received authentication context URI that was incorrect. This has been corrected.</li>
-<li>A new section, 7.2.2, &quot;Requesting SCAL2 Signature Activation Data&quot;, was added. This amendment describes how and when to request Signature Activation Data from an Identity Provider in order to enable a signature service to operate as a Qualified Signature Creation Device (QSCD).</li>
-<li>Attribute release rules have been clarified in sections 2.1.2, &quot;Service Providers&quot; and 6.2.1, &quot;Attribute Release Rules&quot;.</li>
-<li>Section 2.1.2, &quot;Service Providers&quot;, was updated to include a requirement for Service Providers communicating with a centralized discovery service.</li>
-<li>Section 5.3, &quot;Message Content&quot;, was updated to describe the use of <code>&lt;saml2p:IDPEntry&gt;</code> elements under the <code>&lt;samp2p:Scoping&gt;</code> elements for requests sent to Identity Providers acting as proxies for other Identity Providers.</li>
-<li>The reference to [<a href="#saml2metaui">SAML2MetaUI</a>] was updated to the latest official version: <a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html">http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html</a>.</li>
-<li>The reference to [<a href="#entcat">EntCat</a>] was updated to the latest version. </li>
-</ul>
-<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
-<ul class="list">
-<li><p>Version 1.3 of this profile stated that a
-<code>&lt;saml2p:AuthnRequest&gt;</code> message MUST contain an
-<code>AssertionConsumerServiceURL</code> attribute identifying the desired
-response location. It has shown that this requirement aggravates
-interoperability since some of the major providers of Service
-Provider software do not fully support this attribute. Furthermore,
-the requirement does increase security since an Identity Provider
-may only post response messages to locations registered in the
-<code>&lt;md:AssertionConsumerService&gt;</code> elements of the Service Provider
-metadata entry. Therefore, chapter 5.3, “Message Content”, has been
-changed to state that the <code>&lt;saml2p:AuthnRequest&gt;</code> message SHOULD
-contain an <code>AssertionConsumerServiceURL</code> attribute. Changes have also
-been made to sections 5.4.2 and 6.3.2 where processing requirements
-were updated.</p>
-</li>
-<li><p>In section 5.3, a clarification regarding specifying more than one
-authentication context URI was made.</p>
-</li>
-<li><p>In section 7.1, a set of authentication context URIs for the eIDAS
-Framework was added.</p>
-</li>
-<li><p>In section 6.4, the requirement to use the sub-level status code
-<code>http://id.elegnamnden.se/status/1.0/cancel</code> was added. This status
-should be used to indicate a cancelled operation.</p>
-</li>
-<li><p>In section 6.4, the status codes <code>http://id.elegnamnden.se/status/1.0/fraud</code> and <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> were introduced. Their purpose is to alert (suspected) fraudulent behaviour.</p>
-</li>
-<li><p>The specification for “Discovery within the Swedish eID Framework”
-has been deprecated and requirements referring to this document have
-been updated.</p>
-</li>
-<li><p>A clarification to section 5.2 was made stating that conformant
-Identity Providers MUST support the HTTP-POST binding.</p>
-</li>
-<li><p>Section 6.2 was updated with requirements for proxy-IdP:s that are expected to include the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element holding the entityID of the Identity Provider that provided the authentication of the principal.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
-<ul class="list">
-<li><p>This profile now extends a newer version of the SAML2Int Deployment
-Profile (see <a href="http://saml2int.org/profile/current/">http://saml2int.org/profile/current/</a>).</p>
-</li>
-<li><p>Clarifications on how entity categories are represented in metadata
-were made to chapters: 2.1.2, 2.1.3, and 2.1.4.</p>
-</li>
-<li><p>Changes were made to chapter 6.1, “Security Requirements”, where the
-profile now requires the entire <code>&lt;saml2p:Response&gt;</code> message to
-be signed, as compared to the previous version where the signature
-requirement was put on <code>&lt;saml2:Assertion&gt;</code> elements.</p>
-</li>
-<li><p>In chapter 6.2, it is now specified that an Address attribute MUST
-be part of the <code>&lt;saml2:SubjectConfirmationData&gt;</code> element. The
-previous version stated SHOULD.</p>
-</li>
-<li><p>Chapter 6.2.1, “Attribute Release Rules”, was introduced to clarify
-how the attribute release process should be handled by an issuing
-entity.</p>
-</li>
-<li><p>A Service Provider is now obliged to explicitly specify the required
-Level of Assurance under which a specific authentication should be
-performed. This is specified in chapter 5.3, “Message Content”, and
-5.4.4, “Authentication Context and Level of Assurance Handling”.</p>
-</li>
-<li><p>The specification “Authentication Context Classes for Levels of
-Assurance for the Swedish eID Framework” has been removed from the
-Swedish eID Framework. The reason for this is that it was proven
-difficult to make use of the <code>&lt;saml2:AuthnContextDecl&gt;</code> element
-to store authentication context parameters, and that no commercial,
-or open source, Identity Provider software had support for this
-feature. [EidAttributes] now describe how the <code>authContextParams</code>
-attribute may be used for the same purpose, and the examples where
-this information was stored under the <code>&lt;saml2:AuthnContextDecl&gt;</code>
-element was removed from chapter 6.2, “Message Content”.</p>
-</li>
-<li><p>Chapter 7, “Authentication for Signature”, was introduced to specify
-requirements regarding the process of “authentication for signature”
-where a <em>Signature Service</em> requests that a user performing a
-signature authenticates.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
-<ul class="list">
-<li><p>This profile now explicitly defines requirements for the use of
-signed authentication request messages, see sections 2.1and 5.2.</p>
-</li>
-<li><p>This profile now allows the HTTP-POST binding to be used for sending
-authentication request messages (see chapter 5.2, “Binding and
-Security Requirements”). The main reason for this is to facilitate
-the use of signed authentication request messages.</p>
-</li>
-<li><p>In chapter 5.4, additional processing requirements for received
-authentication requests were added or changed. These include:</p>
-</li>
-<li><p>Validation of assertion consumer addresses (5.4.1).</p>
-</li>
-<li><p>Clarifications to chapter 5.4.4.</p>
-</li>
-<li><p>Single Sign On processing (5.4.5).</p>
-</li>
-<li><p>This profile now states that “Unsolicited response” messages are not
-accepted by Service Providers due to security reasons, see chapter
-6.1, “Security Requirements”.</p>
-</li>
-<li><p>Changes and additions in chapter 6.2, “Message Content”, for
-responses including:</p>
-</li>
-<li><p>Clarifications about the usage of the <code>AuthnInstant</code> attribute of the
-<code>&lt;saml2:AuthnStatement&gt;</code> element.</p>
-</li>
-<li><p>Specifications of the use of <code>&lt;saml2:SubjectConfirmation&gt;</code> in
-assertions.</p>
-</li>
-<li><p>Clarifications on the use of audience restrictions and assertion
-validity.</p>
-</li>
-<li><p>Chapter 6.3, “Processing Requirements”, was added. This chapter
-contains specifications and requirements of how a response message
-should be processed in order to maintain security.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
-<ul class="list">
-<li><p>In chapter 5.1, “Discovery”, a reference to the specification
-“Discovery within the Swedish eID Framework” [Eid2Disco] was
-added.</p>
-</li>
-<li><p>In chapter 5.4.4, a note was added that informs about the need to
-ensure IdP-capabilities regarding level of assurance before issuing
-a request.</p>
-</li>
-<li><p>In chapter 6.2, “Message Content”, an example of how an Identity
-Provider may include an authentication context class declaration was
-provided.</p>
-</li>
-<li><p>Some faulty references were corrected.</p>
-</li>
-</ul>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html b/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
new file mode 120000
index 0000000..c34f5eb
--- /dev/null
+++ b/docs/updates/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
@@ -0,0 +1 @@
+../december-2024/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/updates/03_-_Registry_for_Identifiers.html b/docs/updates/03_-_Registry_for_Identifiers.html
deleted file mode 100644
index ab370c4..0000000
--- a/docs/updates/03_-_Registry_for_Identifiers.html
+++ /dev/null
@@ -1,1214 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Swedish eID Framework - Registry for identifiers</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-landscape.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="swedish-eid-framework---registry-for-identifiers">Swedish eID Framework - Registry for identifiers</h1>
-<h3 id="version-18---2024-11-26---draft-version">Version 1.8 - 2024-11-26 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2019-309</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#background"><strong>Background</strong></a></p>
-</li>
-<li><p><a href="#structure"><strong>Structure</strong></a></p>
-<p> 2.1. <a href="#uri-identifiers">URI Identifiers</a></p>
-<p> 2.2. <a href="#oid-identifiers">OID Identifiers</a></p>
-</li>
-<li><p><a href="#assigned-identifiers"><strong>Assigned Identifiers</strong></a></p>
-<p> 3.1. <a href="#url-identifiers">URL Identifiers</a></p>
-<p> 3.1.1. <a href="#authentication-context-uris">Authentication Context URIs</a></p>
-<p> 3.1.1.1. <a href="#authentication-context-uris-for-swedish-non-residents">Authentication Context URIs for Swedish Non-residents</a></p>
-<p> 3.1.1.2. <a href="#authentication-context-uris-for-uncertified-providers">Authentication Context URIs for Uncertified Providers</a></p>
-<p> 3.1.2. <a href="#attribute-sets">Attribute Sets</a></p>
-<p> 3.1.3. <a href="#entity-category-identifiers">Entity Category Identifiers</a></p>
-<p> 3.1.3.1. <a href="#service-entity-categories">Service Entity Categories</a></p>
-<p> 3.1.3.2. <a href="#entity-categories-for-service-properties">Entity Categories for Service Properties</a></p>
-<p> 3.1.3.3. <a href="#entity-categories-for-service-type">Entity Categories for Service Type</a></p>
-<p> 3.1.3.4. <a href="#entity-categories-for-service-contract">Entity Categories for Service Contract</a></p>
-<p> 3.1.3.5. <a href="#general-entity-categories">General Entity Categories</a></p>
-<p> 3.1.4. <a href="#saml-protocol-status-codes">SAML Protocol Status Codes</a></p>
-<p> 3.1.5. <a href="#central-signing">Central Signing</a></p>
-<p> 3.1.6. <a href="#authentication-context">Authentication Context</a></p>
-<p> 3.1.7. <a href="#sign-response-status-codes">Sign Response Status Codes</a></p>
-<p> 3.1.8. <a href="#name-registration-authorities">Name Registration Authorities</a></p>
-<p> 3.1.9. <a href="#eidas-identifiers">eIDAS Identifiers</a></p>
-<p> 3.1.9.1. <a href="#eidas-proxy-service-aliases">eIDAS Proxy Service Aliases</a></p>
-<p> 3.1.9.2. <a href="#eidas-connector-aliases">eIDAS Connector Aliases</a></p>
-<p> 3.1.9.3. <a href="#identity-binding-processes">Identity Binding Processes</a></p>
-<p> 3.2. <a href="#oid-identifiers3">OID Identifiers</a></p>
-<p> 3.2.1. <a href="#asn1-declarations">ASN.1 Declarations</a></p>
-</li>
-<li><p><a href="#references"><strong>References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<p><a name="background"></a></p>
-<h2 id="1-background">1. Background</h2>
-<p>The implementation of a Swedish infrastructure for electronic
-identification and electronic signature requires various types of
-identifiers to represent objects in protocols and data structures.</p>
-<p>This document defines the structure for identifiers assigned by the Swedish eID Framework
-and provides a registry for assigned identifiers.</p>
-<p>The following types of identifiers are assigned in this document:</p>
-<ul class="list">
-<li><p>  URI (Uniform Resource Identifier)</p>
-</li>
-<li><p>  OID (Object Identifier)</p>
-</li>
-</ul>
-<p>This registry is limited to registering assigned identifiers.
-Identifiers in this registry are typically defined within the context of
-a separate specification, which defines the semantic meaning of the
-identifier within the context of a particular protocol and/or data
-structure. Where applicable, this registry provides references to the
-documents where the exact meaning of each identifier is defined.</p>
-<p><a name="structure"></a></p>
-<h2 id="2-structure">2. Structure</h2>
-<p>The basic structure of identifiers assigned by the Swedish eID Framework is based on the following components:</p>
-<table>
-<thead>
-<tr>
-<th><strong>Parameter</strong></th>
-<th><strong>Description</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td><strong>Prefix</strong></td>
-<td>The leading portion of the identifier that associates the identifier with this registry and identifies the Swedish e-identification board or Sweden Connect as the assigner of the identifier.</td>
-</tr>
-<tr>
-<td><strong>Category</strong></td>
-<td>A code for the category of an identifier. Each category is a defined context for a collection of identifiers within the scope of a protocol, service or object type.</td>
-</tr>
-<tr>
-<td><strong>Version</strong> (optional)</td>
-<td>An indicator of the version of the object represented by this identifier. The exact semantic of the version indicator, if present, is defined within each category.</td>
-</tr>
-<tr>
-<td><strong>Identifier</strong></td>
-<td>A sequence of characters or numbers (according to the syntax of the identifier type), which distinguish this identifier among all other identifiers within a particular prefix, category and version.</td>
-</tr>
-</tbody></table>
-<p><a name="uri-identifiers"></a></p>
-<h3 id="21-uri-identifiers">2.1. URI Identifiers</h3>
-<p>All URI identifiers in this registry are of URL type (Uniform Resource
-Locator), assigned under the prefixes <code>http://id.elegnamnden.se</code> and <code>http://id.swedenconnect.se</code>.</p>
-<p>These URL identifiers are defined using the following structure:</p>
-<ul class="list">
-<li><strong><code>http://id.elegnamnden.se/{category}[/{version}]/{identifier}</code></strong>, or,</li>
-<li><strong><code>http://id.swedenconnect.se/{category}[/{version}]/{identifier}</code></strong>.</li>
-</ul>
-<p><a name="oid-identifiers"></a></p>
-<h3 id="22-oid-identifiers">2.2. OID Identifiers</h3>
-<p>An object identifier consists of a node in a hierarchically-assigned
-namespace, formally defined using the ITU-T&#39;s ASN.1 standard, X.690.
-Successive numbers of the nodes, starting at the root of the tree,
-identify each node in the tree. Designers set up new nodes by
-registering them under the node&#39;s registration authority. The root of
-the tree contains the following three arcs:</p>
-<ul class="list">
-<li>  0: ITU-T</li>
-<li>  1: ISO</li>
-<li>  2: joint-iso-itu-t</li>
-</ul>
-<p>Object identifiers are in this document represented as a string
-containing a sequence of integers separated by a dot (“.”), e.g.
-2.3.4.25, where each integer represents a node in the hierarchy.</p>
-<p>The node assigned to the Swedish E-identification Board/Sweden Connect is: <strong>1.2.752.201</strong>.</p>
-<p>This represents a hierarchical structure of nodes in the following
-sequence:</p>
-<ul class="list">
-<li>  1 = ISO</li>
-<li>  2 = ISO member body</li>
-<li>  752 = The Swedish Standardization Institute (SIS-ITS)</li>
-<li>  201 = Swedish E-identification Board (see note below)</li>
-</ul>
-<p>This node is used as the Prefix (root node) for all OID identifiers in
-this registry, using the following structure:</p>
-<p><strong>1.2.752.201.{category}.{identifier}</strong></p>
-<p>OID identifiers according to this structure assign a node for each
-category and an identifier node under this category node. No node in
-this structure is assigned as version node. Version is handled, when
-necessary, within the identifier portion of the OID, typically by
-assigning a new identifier.</p>
-<p><strong>Note</strong>: The OID 1.2.752.201 was assigned to the Swedish E-identification Board, but
-this organisation has been overtaken by the Swedish Agency for Digital Government (DIGG) who 
-now uses this OID arc for the Sweden Connect Technical Framework.</p>
-<p><a name="assigned-identifiers"></a></p>
-<h2 id="3-assigned-identifiers">3. Assigned Identifiers</h2>
-<p><a name="url-identifiers"></a></p>
-<h3 id="31-url-identifiers">3.1. URL Identifiers</h3>
-<p>The following category codes are defined:</p>
-<table>
-<thead>
-<tr>
-<th><strong>Code</strong></th>
-<th><strong>Category</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td><strong>loa</strong></td>
-<td>Level of Assurance. Identifiers representing level of assurance for federated identity (Tillitsnivå).</td>
-</tr>
-<tr>
-<td><strong>ac</strong></td>
-<td>Attribute profile.</td>
-</tr>
-<tr>
-<td><strong>ec</strong></td>
-<td>Entity Category. Generic service type declarations for service matching.</td>
-</tr>
-<tr>
-<td><strong>sprop</strong></td>
-<td>Service Property. Specific entity category identifiers for specific service property.</td>
-</tr>
-<tr>
-<td><strong>st</strong></td>
-<td>Service Type. Specific entity category identifiers for defined types of services in the federation.</td>
-</tr>
-<tr>
-<td><strong>contract</strong></td>
-<td>Service contract. Specific entity category identifiers for declaring contract, or business agreement, affiliation within a federation.</td>
-</tr>
-<tr>
-<td><strong>csig</strong></td>
-<td>Central Signing Service – Identifiers used by the central signing service infrastructure.</td>
-</tr>
-<tr>
-<td><strong>auth-cont</strong></td>
-<td>Authentication context information schema.</td>
-</tr>
-<tr>
-<td><strong>status</strong></td>
-<td>SAML Protocol status codes.</td>
-</tr>
-<tr>
-<td><strong>sig-status</strong></td>
-<td>Sign response status codes.</td>
-</tr>
-<tr>
-<td><strong>eidas</strong></td>
-<td>Identifiers used for integration with the eIDAS Framework.</td>
-</tr>
-<tr>
-<td><strong>ns</strong></td>
-<td>XML Schema namespaces.</td>
-</tr>
-</tbody></table>
-<p><a name="authentication-context-uris"></a></p>
-<h4 id="311-authentication-context-uris">3.1.1. Authentication Context URIs</h4>
-<p>Authentication Context URIs representing assurance levels (Tillitsnivåer) relevant to
-[<a href="#tillitramv">TillitRamv</a>] and [<a href="#eiddeploy">EidDeploy</a>].</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa1</code></td>
-<td align="left">Assurance level 1.</td>
-<td align="left">[<a href="#tillitramv">TillitRamv</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa2</code></td>
-<td align="left">Assurance level 2.</td>
-<td align="left">[<a href="#tillitramv">TillitRamv</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa3</code></td>
-<td align="left">Assurance level 3.</td>
-<td align="left">[<a href="#tillitramv">TillitRamv</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/loa4</code></td>
-<td align="left">Assurance level 4.</td>
-<td align="left">[<a href="#tillitramv">TillitRamv</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-low</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level low for non-notified and notified eID schemes.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-sub</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level substantial for non-notified and notified eID schemes.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-high</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level high for non-notified and notified eID schemes.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level low using an eID scheme that MUST be notified.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-sub</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level substantial using an eID scheme that MUST be notified.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/loa/1.0/eidas-nf-high</code><sup>*</sup></td>
-<td align="left">Authentication accordance to eIDAS assurance level high using an eID scheme that MUST be notified.</td>
-<td align="left">[<a href="#eidas">eIDAS</a>]</td>
-</tr>
-</tbody></table>
-<p><strong>NOTE:</strong> eIDAS assurance levels low, substantial and high have the
-following <code>AuthnContextClassRef</code> URI:s defined by the EU commission:</p>
-<ul class="list">
-<li><p>  <code>http://eidas.europa.eu/LoA/low</code></p>
-</li>
-<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/low</code> (for non-notified eID schemes)</p>
-</li>
-<li><p>  <code>http://eidas.europa.eu/LoA/substantial</code></p>
-</li>
-<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/substantial</code> (for non-notified eID schemes)</p>
-</li>
-<li><p>  <code>http://eidas.europa.eu/LoA/high</code></p>
-</li>
-<li><p>  <code>http://eidas.europa.eu/NotNotified/LoA/high</code> (for non-notified eID schemes)</p>
-</li>
-</ul>
-<blockquote>
-<p>[*]: The authentication context URI:s are intended to be used to represent authentication
-over the eIDAS authentication framework using an official eIDAS-connector. Authorization to 
-issue assertions using these authentication context URI:s is determined by declaration of the
-&quot;assurance certification&quot; for the connector (see section 2.1.3 of [<a href="#eiddeploy">EidDeploy</a>]).</p>
-</blockquote>
-<p><a name="authentication-context-uris-for-swedish-non-residents"></a></p>
-<h5 id="3111-authentication-context-uris-for-swedish-non-residents">3.1.1.1. Authentication Context URIs for Swedish Non-residents</h5>
-<p>The Swedish assurance framework, [<a href="#tillitramv">TillitRamv</a>], states that a Swedish eID
-according to any of the defined assurance levels must only be issued to an individual holding
-a Swedish personal identity number (personnummer) or a Swedish coordination number 
-(samordningsnummer).</p>
-<p>In some cases, a certified eID-issuer may also issue eIDs to persons that do not hold
-a Swedish identity number (non-residents). If this is the case, and the original 
-identification of the person has a strength that corresponds to the requirements 
-put in [<a href="#tillitramv">TillitRamv</a>], a certified Identity Provider MAY use the URIs
-defined below:</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa2-nonresident</code></td>
-<td align="left">A URI that is indented to be used by a level 2-certified providers that authenticate a non-resident eID holder according to assurance level 2 - <code>http://id.elegnamnden.se/loa/1.0/loa2</code>.</td>
-<td align="left">This document</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa3-nonresident</code></td>
-<td align="left">A URI that is indented to be used by a level 3-certified providers that authenticate a non-resident eID holder according to assurance level 3 - <code>http://id.elegnamnden.se/loa/1.0/loa3</code>.</td>
-<td align="left">This document</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>loa4-nonresident</code></td>
-<td align="left">A URI that is indented to be used by a level 4-certified providers that authenticate a non-resident eID holder according to assurance level 4 - <code>http://id.elegnamnden.se/loa/1.0/loa4</code>.</td>
-<td align="left">This document</td>
-</tr>
-</tbody></table>
-<p><strong>Note:</strong> An Identity Provider that includes any of the above URIs in an issued assertion
-MUST NOT provide the <code>personalIdentityNumber</code> attribute in the assertion. This is per
-definition since these URIs are intended to be used for non-residents (i.e., they do not hold
-a Swedish identity number).</p>
-<p><a name="authentication-context-uris-for-uncertified-providers"></a></p>
-<h5 id="3112-authentication-context-uris-for-uncertified-providers">3.1.1.2. Authentication Context URIs for Uncertified Providers</h5>
-<p>The assurance levels defined in section <a href="#authentication-context-uris">3.1.1</a> may only be 
-used by Identity Providers that have been reviewed and approved by the Swedish Agency for 
-Digital Government (DIGG) according to [<a href="#tillitramv">TillitRamv</a>]. For Identity Providers 
-that have not undergone a review process but make a self declaration to be compliant 
-with [<a href="#tillitramv">TillitRamv</a>] this specification defines the following authentication
-context URIs:</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>uncertified-loa2</code></td>
-<td align="left">URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 2 - <code>http://id.elegnamnden.se/loa/1.0/loa2</code>.</td>
-<td align="left">This document</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br/><code>uncertified-loa3</code></td>
-<td align="left">URI that is indented to be used by uncertified providers that make a self declaration of providing an assurance level comparable to Assurance level 3 - <code>http://id.elegnamnden.se/loa/1.0/loa3</code>.</td>
-<td align="left">This document</td>
-</tr>
-</tbody></table>
-<p>Proxy Identity Providers that have eIDAS authentication as an option MUST NOT use the eIDAS
-authentication context URIs defined in section <a href="#authentication-context-uris">3.1.1</a>. 
-Instead they should use:</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-low</code></td>
-<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-low</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code> in an assertion from the official Swedish eIDAS-connector.</td>
-<td align="left">This document</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-sub</code></td>
-<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-sub</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-sub</code> in an assertion from the official Swedish eIDAS-connector.</td>
-<td align="left">This document</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/loa/1.0/</code><br /><code>uncertified-eidas-high</code></td>
-<td align="left">Should be used if a proxy IdP receives <code>http://id.elegnamnden.se/loa/1.0/eidas-high</code> or <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-high</code> in an assertion from the official Swedish eIDAS-connector.</td>
-<td align="left">This document</td>
-</tr>
-</tbody></table>
-<p><a name="attribute-sets"></a></p>
-<h4 id="312-attribute-sets">3.1.2. Attribute Sets</h4>
-<p>Identifiers for attribute sets defined in the Attribute Profile
-Specification for the Swedish eID Framework.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>Identifier</strong></th>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left">ELN-AP-Pseudonym-01</td>
-<td align="left"><code>http://id.elegnamnden.se/ap/1.0/pseudonym-01</code></td>
-<td align="left">Pseudonym identity attribute set.</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">ELN-AP-NaturalPerson-01</td>
-<td align="left"><code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></td>
-<td align="left">Personal identity without civic registration number attribute set.</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">ELN-AP-Pnr-01</td>
-<td align="left"><code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></td>
-<td align="left">Personal identity with civic registration number attribute set.</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">ELN-AP-OrgPerson-01</td>
-<td align="left"><code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></td>
-<td align="left">Organizational identity attribute set.</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">ELN-AP-eIDAS-NatPer-01</td>
-<td align="left"><code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></td>
-<td align="left">Natural person identity for the eIDAS Framework.</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">DIGG-AP-HSAid-01</td>
-<td align="left"><code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code></td>
-<td align="left">Natural Person Identity with HSA-ID</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="entity-category-identifiers"></a></p>
-<h4 id="313-entity-category-identifiers">3.1.3. Entity Category Identifiers</h4>
-<p>Identifiers for categories of service entities, specified as an “Entity Attribute” in the federation metadata.</p>
-<p><a name="service-entity-categories"></a></p>
-<h5 id="3131-service-entity-categories">3.1.3.1. Service Entity Categories</h5>
-<p>Identifiers for entity categories representing alternative sets of requirements.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa2-pnr</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa3-pnr</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/sc/uncertified-loa3-pnr</code></td>
-<td align="left">Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/loa4-pnr</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/eidas-naturalperson</code></td>
-<td align="left">Service consuming/providing assertions based on any eIDAS assurance level, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/</code><br /><code>ec/1.0/eidas-pnr-delivery</code></td>
-<td align="left">Service providing assertions to eIDAS services via Swedish eIDAS-node</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-hsaid</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code>.</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/sc/uncertified-loa3-hsaid</code></td>
-<td align="left">Service consuming/providing assertions based on uncertified-loa3, as defined above, implementing the attribute set <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code>.</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa2-orgid</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-orgid</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa4-orgid</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa2-name</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 2, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa3-name</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 3, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>ec/1.0/loa4-name</code></td>
-<td align="left">Service consuming/providing assertions based on assurance level 4, implementing the attribute set <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="entity-categories-for-service-properties"></a></p>
-<h5 id="3132-entity-categories-for-service-properties">3.1.3.2. Entity Categories for Service Properties</h5>
-<p>Identifiers for defined service properties.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/sprop/1.0/mobile-auth</code></td>
-<td align="left">Service adapted to require/provide user authentication based on mobile devices.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/sprop/1.0/scal2</code></td>
-<td align="left">Service adapted to support authentication requests from signature services supporting Sole Control Assurance Level 2 (SCAL2).</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="entity-categories-for-service-type"></a></p>
-<h5 id="3133-entity-categories-for-service-type">3.1.3.3. Entity Categories for Service Type</h5>
-<p>Identifiers for defined service types.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/st/1.0/sigservice</code></td>
-<td align="left">Electronic signature service</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code></td>
-<td align="left">Public sector Service Provider</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code></td>
-<td align="left">Private sector Service Provider</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="entity-categories-for-service-contract"></a></p>
-<h5 id="3134-entity-categories-for-service-contract">3.1.3.4. Entity Categories for Service Contract</h5>
-<p>Service Contract Entity Category identifiers are indented for performing service matching based on contracts, or business agreements, between providing and consuming services.</p>
-<p>All Service Contract identifiers are prefixed with <code>http://id.swedenconnect.se/contract/&lt;org&gt;</code>, where <code>org</code> is the identifier for the defining organization.</p>
-<p>The Swedish eID Framework specifications do not define any Service Contract identifiers. Instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.</p>
-<p><a name="general-entity-categories"></a></p>
-<h5 id="3135-general-entity-categories">3.1.3.5. General Entity Categories</h5>
-<p>An entity category of the General Entity Category type is a category that does not fit into any of the other category types regarding definitions and matching rules.</p>
-<p>General category identifiers are prefixed with <code>http://id.swedenconnect.se/general-ec</code>.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/secure-authenticator-binding</code></td>
-<td align="left">Indicator that a secure authenticator binding is required, or supported.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/accepts-coordination-number</code></td>
-<td align="left">Category for opt-in for the acceptance of Swedish coordination numbers in the personalIdentityNumber attribute.</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/general-ec/</code><br /><code>1.0/supports-user-message</code></td>
-<td align="left">Indicator that an Identity Provider supports the <code>UserMessage</code> authentication request extension, see [<a href="#user-message-ext">UserMessageExt</a>].</td>
-<td align="left">[<a href="#eidentitycat">EidEntityCat</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="saml-protocol-status-codes"></a></p>
-<h4 id="314-saml-protocol-status-codes">3.1.4. SAML Protocol Status Codes</h4>
-<p>Status code identifiers for use in SAML Response messages. The list
-below extends the list of second-level status codes defined in section
-3.2.2.2 of [<a href="#saml2core">SAML2Core</a>].</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/status/1.0/cancel</code></td>
-<td align="left">Status code representing a cancelled operation.</td>
-<td align="left">[<a href="#eiddeploy">EidDeploy</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/status/1.0/fraud</code></td>
-<td align="left">Status code indicating a fraudulent request.</td>
-<td align="left">[<a href="#eiddeploy">EidDeploy</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/status/1.0/possibleFraud</code></td>
-<td align="left">Status code indicating a possible fraudulent request.</td>
-<td align="left">[<a href="#eiddeploy">EidDeploy</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="central-signing"></a></p>
-<h4 id="315-central-signing">3.1.5. Central Signing</h4>
-<p>Identifiers used in the protocol for requesting services form a central signing service.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/csig/1.0/dss-ext/ns</code></td>
-<td align="left"><strong>Deprecated</strong>. XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.0).</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/csig/1.0/eid2-dss/profile</code></td>
-<td align="left"><strong>Deprecated</strong>. Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.0).</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/csig/1.1/dss-ext/ns</code></td>
-<td align="left">XML schema name space for the protocol extensions to the OASIS DSS protocol (version 1.1).</td>
-<td align="left">[<a href="#eiddssext">EidDSSExt</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/csig/1.1/dss-ext/profile</code></td>
-<td align="left">Implementation profile identifier for the protocol extensions to the OASIS DSS protocol (version 1.1).</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/csig/1.1/sap/ns</code></td>
-<td align="left">XML schema name space for the Signature Activation Protocol, extending version 1.1 of the DSS protocol extension</td>
-<td align="left">[<a href="#eidsigsap">EidSigSAP</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="authentication-context"></a></p>
-<h4 id="316-authentication-context">3.1.6. Authentication Context</h4>
-<p>Identifiers associated with the Authentication Context X.509 extension</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/auth-cont/1.0/saci</code></td>
-<td align="left">XML schema namespace for SAML Authentication Context Information in the Authentication Context X.509 certificate extension</td>
-<td align="left">[<a href="#rfc7773">RFC7773</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info</code></td>
-<td align="left">XML schema namespace for Extended Authentication Information in the Authentication Context X.509 certificate extension</td>
-<td align="left">[<a href="#certprof">CertProf</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="sign-response-status-codes"></a></p>
-<h4 id="317-sign-response-status-codes">3.1.7. Sign Response Status Codes</h4>
-<p>Status code identifiers for the DSS Extension for SAML based Central Signing service. The following identifiers provide defined status codes
-for inclusion in a <code>&lt;ResultMinor&gt;</code> element of the <code>&lt;Result&gt;</code> element of a sign response message according to the OASIS standard “Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0” [<a href="#oasis-dss">OASIS-DSS</a>].</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/req-expired</code></td>
-<td align="left">The time window for the signature request has expired.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/user-mismatch</code></td>
-<td align="left">The authenticated user does not match the signer identity attributes in the request.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/unsupported-loa</code></td>
-<td align="left">The requested level of assurance for user authentication is not supported.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/sigmessage-error</code></td>
-<td align="left">A requirement to display sign message was included in the sign request, but the sign service could not establish that the sign message was displayed to the user.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.elegnamnden.se/sig-status/1.0/user-cancel</code></td>
-<td align="left">The end user cancelled the signature operation.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/sig-status/1.1/authn-failed</code></td>
-<td align="left">The authentication during the signature operation failed.</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/sig-status/1.1/security-violation</code></td>
-<td align="left">The Signature Service, or Identity Provider authenticating the end user, has detected a security violation (such as a possible fraud).</td>
-<td align="left">[<a href="#eidcsignprof">EidCSignProf</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="name-registration-authorities"></a></p>
-<h4 id="318-name-registration-authorities">3.1.8. Name Registration Authorities</h4>
-<p>Some protocols require a URI identifier to uniquely identify the entity responsible for a particular namespace.</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URL</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.elegnamnden.se/eln/name-registration-authority</code></td>
-<td align="left">Identifying the Swedish e-Identification Board<sup>*</sup> as name registration authority, responsible for a particular namespace.</td>
-<td align="left">[<a href="#certprof">CertProf</a>]</td>
-</tr>
-</tbody></table>
-<blockquote>
-<p>[*]: This also covers the Swedish Agency for Digital Government (DIGG) which has overtaken the Swedish E-identification Board&#39;s assignments.</p>
-</blockquote>
-<p><a name="eidas-identifiers"></a></p>
-<h4 id="319-eidas-identifiers">3.1.9. eIDAS Identifiers</h4>
-<p>This section defines identifiers used within the Swedish eID Framework to integrate with the eIDAS Framework.</p>
-<p><a name="eidas-proxy-service-aliases"></a></p>
-<h5 id="3191-eidas-proxy-service-aliases">3.1.9.1. eIDAS Proxy Service Aliases</h5>
-<p>Each country within the eIDAS federation provides an eIDAS Proxy Service that is a Proxy Identity Provider for the authentication services within that specific country. The entityID identifier for an eIDAS Proxy Service in another country is not known to a Swedish Service Provider, but there are cases in which the Swedish Service Provider needs to refer to a specific eIDAS Proxy Service. Therefore, this specification defines an URI identifier format for eIDAS Proxy Service aliases. The format is as follows:</p>
-<p><strong><code>http://id.swedenconnect.se/eidas/1.0/proxy-service/{country-code}</code></strong></p>
-<p>where <code>{country-code}</code> is the country identifier in ISO 3166-1 alpha-2 format [<a href="#iso3166">ISO 3166</a>].</p>
-<blockquote>
-<p>A consumer of an eIDAS Proxy Service alias URI MUST accept the country code part of the URI in both lower and upper case letters.</p>
-</blockquote>
-<p><a name="eidas-connector-aliases"></a></p>
-<h5 id="3192-eidas-connector-aliases">3.1.9.2. eIDAS Connector Aliases</h5>
-<p>A Swedish Identity Provider that delivers authentication services to eIDAS, via the Swedish eIDAS Proxy Service, will receive the entityID of the Service Provider from another country that has requested user authentication in a <code>&lt;saml2p:RequesterID&gt;</code> element of the authentication request. Along with this information, the Swedish Proxy Service will also include another <code>RequesterID</code> element that holds the &quot;eIDAS Connector alias&quot; URI, telling from which country the requesting Service Provider resides.</p>
-<p>The format of this alias is as follows:</p>
-<p><strong><code>http://id.swedenconnect.se/eidas/1.0/connector/{country-code}</code></strong></p>
-<p>where <code>{country-code}</code> is the country identifier in ISO 3166-1 alpha-2 format [<a href="#iso3166">ISO 3166</a>].</p>
-<blockquote>
-<p>A consumer of an eIDAS Connector alias URI MUST accept the country code part of the URI in both lower and upper case letters.</p>
-</blockquote>
-<p><a name="identity-binding-processes"></a></p>
-<h5 id="3193-identity-binding-processes">3.1.9.3. Identity Binding Processes</h5>
-<p>Section 3.3.2 of [<a href="#eidattributes">EidAttributes</a>] describes how the <code>personalIdentityNumberBinding</code> attribute is assigned with one or more &quot;Identity Binding Process URI:s&quot; after an identity binding. The possible values are: </p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>URI</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/populationregister</code></td>
-<td align="left">Unique match of name and birth date between eIDAS identity and the Swedish Population register.</td>
-<td align="left">[<a href="#id-binding">ID-Binding</a>]</td>
-</tr>
-<tr>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/swedish-eid</code></td>
-<td align="left">Digitally signed attestation using a Swedish eID.</td>
-<td align="left">[<a href="#id-binding">ID-Binding</a>]</td>
-</tr>
-</tbody></table>
-<p>The <a href="#id-binding">Binding eIDAS Identities to Records in the Swedish Population Register</a> ([<a href="#id-binding">ID-Binding</a>]) document defines the above processes in detail. </p>
-<p><a name="oid-identifiers3"></a></p>
-<h3 id="32-oid-identifiers">3.2. OID Identifiers</h3>
-<p>Defined categories:</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>Code</strong></th>
-<th align="left"><strong>Category</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>0</strong></td>
-<td align="left">ASN.1 modules</td>
-</tr>
-<tr>
-<td align="left"><strong>1</strong></td>
-<td align="left">Test identifiers</td>
-</tr>
-<tr>
-<td align="left"><strong>2</strong></td>
-<td align="left">Policy identifiers</td>
-</tr>
-<tr>
-<td align="left"><strong>3</strong></td>
-<td align="left">Attribute identifiers</td>
-</tr>
-<tr>
-<td align="left"><strong>4</strong></td>
-<td align="left">”Qualified Certificate” Statement identifiers (RFC 3739)</td>
-</tr>
-<tr>
-<td align="left"><strong>5</strong></td>
-<td align="left">X.509 certificate extension identifiers</td>
-</tr>
-</tbody></table>
-<p>The following OIDs are defined in the ASN.1 declarations in <a href="#asn1-declarations">3.2.1</a>:</p>
-<table>
-<thead>
-<tr>
-<th align="left"><strong>OID</strong></th>
-<th align="left"><strong>Object</strong></th>
-<th align="left"><strong>Reference</strong></th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left">1.2.752.201.5.1</td>
-<td align="left">Authentication Context Extension</td>
-<td align="left">[<a href="#rfc7773">RFC7773</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.5.2</td>
-<td align="left">Signature Validation Token Extension</td>
-<td align="left">[<a href="#svt-pdf">SVT-PDF</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.2.1</td>
-<td align="left">Object identifier for the Signature Validation Token RFC 3161 timestamp policy</td>
-<td align="left"></td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.1</td>
-<td align="left">Organization Affiliation Attribute</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.2</td>
-<td align="left">Transaction Identifier</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.3</td>
-<td align="left">Authentication Context Parameters</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.4</td>
-<td align="left">Provisional ID</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.5</td>
-<td align="left">Provisional ID Persistence Indicator</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.6</td>
-<td align="left">Personal Identity Number Binding URI</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.7</td>
-<td align="left">eIDAS Person Identifier</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.8</td>
-<td align="left">Birth name</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.9</td>
-<td align="left">eIDAS Natural Person Address</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.10</td>
-<td align="left">User Certificate</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.11</td>
-<td align="left">User Signature</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.12</td>
-<td align="left">Signature Activation Data</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.13</td>
-<td align="left">Authentication Server Signature</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.14</td>
-<td align="left">Sign Message Digest</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.15</td>
-<td align="left">Previous Personal Identity Number</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-<tr>
-<td align="left">1.2.752.201.3.16</td>
-<td align="left">Mapped Personal Identity Number</td>
-<td align="left">[<a href="#eidattributes">EidAttributes</a>]</td>
-</tr>
-</tbody></table>
-<p><a name="asn1-declarations"></a></p>
-<h4 id="321-asn1-declarations">3.2.1. ASN.1 Declarations</h4>
-<p>Object Identifier Registry for Sweden Connect<sup>*</sup></p>
-<pre class="hljs"><code><span class="hljs-built_in">id</span>-eleg OBJECT IDENTIFIER ::= {iso(<span class="hljs-number">1</span>) member-body(<span class="hljs-number">2</span>) se(<span class="hljs-number">752</span>) e-legitimationsnamnden(<span class="hljs-number">201</span>)}
-
-<span class="hljs-comment">-- Sweden Connect arcs</span>
-<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">0</span> }    <span class="hljs-comment">-- ASN.1 modules</span>
-<span class="hljs-built_in">id</span>-test   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">1</span> }    <span class="hljs-comment">-- OIDs for test</span>
-<span class="hljs-built_in">id</span>-pol    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Policy</span>
-<span class="hljs-built_in">id</span>-attr   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">3</span> }    <span class="hljs-comment">-- Attributes</span>
-<span class="hljs-built_in">id</span>-qcs    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">4</span> }    <span class="hljs-comment">-- QC Statement</span>
-<span class="hljs-built_in">id</span>-ce     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-eleg <span class="hljs-number">5</span> }    <span class="hljs-comment">-- Cert Extensions</span>
-
-<span class="hljs-comment">-- Sweden Connect Modules</span>
-<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>-auth-context<span class="hljs-number">-88</span> OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span> <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Used in RFC 7773</span>
-<span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span>-auth-context<span class="hljs-number">-08</span> OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-<span class="hljs-keyword">mod</span> <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Used in RFC 7773</span>
-
-<span class="hljs-comment">-- Sweden Connect OIDs for test</span>
-
-<span class="hljs-comment">-- Sweden Connect Policies</span>
-<span class="hljs-built_in">id</span>-pol-svt-ts-policy         OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-pol <span class="hljs-number">1</span> }     <span class="hljs-comment">-- SVT RFC 3161 timestamp policy</span>
-
-<span class="hljs-comment">-- Sweden Connect Attributes</span>
-<span class="hljs-built_in">id</span>-attr-org-affiliation      OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Organizational affiliation</span>
-<span class="hljs-built_in">id</span>-attr-<span class="hljs-keyword">transaction</span>-<span class="hljs-built_in">id</span>       OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Transaction identifier</span>
-<span class="hljs-built_in">id</span>-attr-auth-context-params  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">3</span> }    <span class="hljs-comment">-- Authentication context parameters</span>
-<span class="hljs-built_in">id</span>-attr-prid                 OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">4</span> }    <span class="hljs-comment">-- Provisional ID</span>
-<span class="hljs-built_in">id</span>-attr-prid-persistence     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">5</span> }    <span class="hljs-comment">-- Provisional ID persistence indicator</span>
-<span class="hljs-built_in">id</span>-attr-pnr-binding          OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">6</span> }    <span class="hljs-comment">-- Personal Identity Number binding URI</span>
-<span class="hljs-built_in">id</span>-attr-eidas-pid            OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">7</span> }    <span class="hljs-comment">-- eIDAS Person Identifier</span>
-<span class="hljs-built_in">id</span>-attr-birth-<span class="hljs-built_in">name</span>           OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">8</span> }    <span class="hljs-comment">-- Birth name</span>
-<span class="hljs-built_in">id</span>-attr-eidas-np-address     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">9</span> }    <span class="hljs-comment">-- eIDAS Natural Person Address</span>
-<span class="hljs-built_in">id</span>-attr-user-certificate     OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">10</span> }   <span class="hljs-comment">-- User certificate</span>
-<span class="hljs-built_in">id</span>-attr-user-signature       OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">11</span> }   <span class="hljs-comment">-- User signature</span>
-<span class="hljs-built_in">id</span>-attr-sad                  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">12</span> }   <span class="hljs-comment">-- Signature activation data</span>
-<span class="hljs-built_in">id</span>-attr-auth-srv-signature   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">13</span> }   <span class="hljs-comment">-- Authentication server signature</span>
-<span class="hljs-built_in">id</span>-attr-sign-message-digest  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">14</span> }   <span class="hljs-comment">-- Sign message digest</span>
-<span class="hljs-built_in">id</span>-attr-previous-pid-<span class="hljs-built_in">number</span>  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">15</span> }   <span class="hljs-comment">-- Previous personal identity number</span>
-<span class="hljs-built_in">id</span>-attr-mapped-pid-<span class="hljs-built_in">number</span>    OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-attr <span class="hljs-number">16</span> }   <span class="hljs-comment">-- Mapped personal identity number</span>
-
-<span class="hljs-comment">-- Sweden Connect QC Statement extension</span>
-<span class="hljs-built_in">id</span>-qcs-sid         OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-qcs <span class="hljs-number">1</span> }   <span class="hljs-comment">-- Semantics Identifiers</span>
-<span class="hljs-built_in">id</span>-qcs-statement   OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-qcs <span class="hljs-number">2</span> }   <span class="hljs-comment">-- QC statements</span>
-
-<span class="hljs-comment">-- Sweden Connect Certificate Extensions</span>
-<span class="hljs-built_in">id</span>-ce-authContext  OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-ce <span class="hljs-number">1</span> }    <span class="hljs-comment">-- Auth context extension used in RFC 7773</span>
-<span class="hljs-built_in">id</span>-ce-svt          OBJECT IDENTIFIER ::= { <span class="hljs-built_in">id</span>-ce <span class="hljs-number">2</span> }    <span class="hljs-comment">-- Signature Validation Token extension</span></code></pre><blockquote>
-<p>[*]: The OID 1.2.752.201 was assigned to the Swedish E-identification Board, but this organisation has been overtaken by the Swedish Agency for Digital Government (DIGG) who now uses this OID arc for the Sweden Connect Technical Framework.</p>
-</blockquote>
-<p><a name="references"></a></p>
-<h2 id="4-references">4. References</h2>
-<p><a name="saml2core"></a>
-<strong>[SAML2Core]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
-Assertion Markup Language (SAML) V2.0, March 2005</a></p>
-</blockquote>
-<p><a name="oasis-dss"></a>
-<strong>[OASIS-DSS]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html">Digital Signature Service Core Protocols, Elements, and Bindings
-Version 1.0.</a></p>
-</blockquote>
-<p><a name="tillitramv"></a>
-<strong>[TillitRamv]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digital-identitet/e-legitimering/tillitsnivaer/tillitsramverket">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="rfc7773"></a>
-<strong>[RFC7773]</strong></p>
-<blockquote>
-<p><a href="https://tools.ietf.org/html/rfc7773">RFC7773: Authentication Context Certificate Extension</a>.</p>
-</blockquote>
-<p><a name="eiddeploy"></a>
-<strong>[EidDeploy]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidentitycat"></a>
-<strong>[EidEntityCat]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eiddssext"></a>
-<strong>[EidDSSExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="eidsigsap"></a>
-<strong>[EidSigSAP]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="eidcsignprof"></a>
-<strong>[EidCSignProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html">Implementation Profile for Using OASIS DSS in Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="certprof"></a>
-<strong>[CertProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/08_-_Certificate_Profile_for_Central_Signing_Services.html">Certificate profile for certificates issued by Central Signing services</a></p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="user-message-ext"></a>
-<strong>[UserMessageExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
-</blockquote>
-<p><a name="id-binding"></a>
-<strong>[ID-Binding]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding eIDAS Identities to Records in the Swedish Population Register</a></p>
-</blockquote>
-<p><a name="svt-pdf"></a>
-<strong>[SVT-PDF]</strong></p>
-<blockquote>
-<p><a href="https://datatracker.ietf.org/doc/draft-santesson-svt-pdf/">PDF Signature Validation Token</a>.</p>
-</blockquote>
-<p><a name="eidas"></a>
-<strong>[eIDAS]</strong></p>
-<blockquote>
-<p>REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE
-COUNCIL of 23 July 2014 on electronic identification and trust
-services for electronic transactions in the internal market and
-repealing Directive 1999/93/EC. Including implementation acts of the
-regulation and associated technical specifications.</p>
-</blockquote>
-<p><a name="iso3166"></a>
-<strong>[ISO 3166]</strong></p>
-<blockquote>
-<p>Country Codes - ISO 3166, <a href="https://www.iso.org/iso-3166-country-codes.html">https://www.iso.org/iso-3166-country-codes.html</a>.</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="5-changes-between-versions">5. Changes between versions</h2>
-<p><strong>Changes between version 1.7 and version 1.b:</strong></p>
-<ul class="list">
-<li><p>Section 3.1.7, &quot;Sign Response Status Codes&quot;, were extended with error codes for <code>authn-failed</code> and <code>security-violation</code>.</p>
-</li>
-<li><p>Section 3.1.9.3, &quot;Identity Binding Processes&quot;, was introduced where binding process URI:s for matching eIDAS identities to Swedish identity numbers are listed.</p>
-</li>
-<li><p>The <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category was added to section, 3.1.3.5, &quot;General Entity Categories&quot;.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
-<ul class="list">
-<li><p>Section, 3.1.3.5, &quot;General Entity Categories&quot;, was introduced and <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> and <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> was added.</p>
-</li>
-<li><p>In section 3.2, an object identifier (OID) for Signature Validation Token extension was added and one OID for a SVT timestamp policy.</p>
-</li>
-<li><p>Added service entity categories <code>http://id.swedenconnect.se/ec/1.0/loa3-orgid</code> and <code>http://id.swedenconnect.se/ec/1.0/loa3-name</code> to section 3.1.3.1.</p>
-</li>
-<li><p>In section 3.2, the attributes for &quot;previous personal identity number&quot; (<code>1.2.752.201.3.15</code>) and  &quot;mapped personal identity number&quot; (<code>1.2.752.201.3.16</code>) were added.</p>
-</li>
-<li><p>Section 3.1.3.1, &quot;Service Entity Categories&quot;, was updated with categories for loaX-name and loaX-orgid.</p>
-</li>
-<li><p>Authentication context URIs for non-residents and uncertified providers were added to sections 3.1.1.1 and 3.1.1.2.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
-<ul class="list">
-<li><p>The specification was renamed from &quot;Registry for identifiers assigned by the Swedish e-identification board&quot; to &quot;Swedish eID Framework - Registry for identifiers&quot;.</p>
-</li>
-<li><p>The authentication context URIs <code>http://id.swedenconnect.se/loa/1.0/uncertified-loa3</code> and <code>http://id.swedenconnect.se/loa/1.0/uncertified-loa3-sigmessage</code> were introduced in sections 3.1.1 and 3.1.1.1, and the service entity category <code>http://id.swedenconnect.se/ec/sc/uncertified-loa3-pnr</code> was added to section 3.1.3.1.</p>
-</li>
-<li><p>A description of Service Contract Entity Categories was added to section 3.1.3.4.</p>
-</li>
-<li><p>In section 3.1.1, the EU commission <code>AuthnContextClassRef</code> URI:s for non-notified schemes were changed.</p>
-</li>
-<li><p>Section 3.1.9.2, &quot;eIDAS Connector Aliases&quot;, defining the URI format for representing country affiliation of eIDAS connector services, was added.</p>
-</li>
-<li><p>The link for the &quot;Tillitsramverk för Svensk e-legitimation&quot; specification was updated.</p>
-</li>
-<li><p>Added the attribute SignMessageDigest (1.2.752.201.3.14) to section 3.2.</p>
-</li>
-<li><p>The Sign Message Authentication Context URIs defined in section 3.1.1.1 are deprecated.</p>
-</li>
-<li><p>The XML Schema namespace identifier <code>http://id.swedenconnect.se/auth-cont/1.0/ext-auth-info</code> was added. This XML Schema defines an XML extension for the Authentication Context Extension to provide extended authentication information.</p>
-</li>
-<li><p>Associating the OID registry with Sweden Connect.</p>
-</li>
-<li><p>Aligned registered module OID:s with RFC 7773.</p>
-</li>
-<li><p>Adding a new extension OID for Signature Validation Tokens in timestamp extensions.</p>
-</li>
-<li><p>Added attribute set and service entity categories for HSA-ID.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
-<ul class="list">
-<li><p>Added identifier for the service property entity category <code>http://id.elegnamnden.se/sprop/1.0/scal2</code></p>
-</li>
-<li><p>Added XML Schema name space identifier <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code>. This XML Schema defines XML elements related to the Signature Activation Protocol.</p>
-</li>
-<li><p>Added Semantics Identifiers section 3.1.8 to define a name registration authority URI necessary to express a provisional ID attribute in an X.509 certificate according to ETSI EN 319 412-1.</p>
-</li>
-<li><p>Added Authentication Context URI:s <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low</code> and <code>http://id.elegnamnden.se/loa/1.0/eidas-nf-low-sigm</code> to section 3.1.1.</p>
-</li>
-<li><p>Added section 3.1.9, &quot;eIDAS Identifiers&quot;, that describes the format for eIDAS Proxy Service Alias URI identifiers.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
-<ul class="list">
-<li><p>  Attributes and URI:s for the eIDAS Framework was added.</p>
-</li>
-<li><p>The SAML status code identifier
-  <code>http://id.elegnamnden.se/status/1.0/cancel</code> was added to be used in SAML
-  Response messages to indicate a cancelled operation.</p>
-</li>
-<li><p>Added the SAML status code identifiers <code>http://id.elegnamnden.se/status/1.0/fraud</code> and <code>http://id.elegnamnden.se/status/1.0/possibleFraud</code> were added to be used in SAML Response messages to alert fraudulent requests.</p>
-</li>
-<li><p>Added attribute definitions for “Birth name”, “User certificate”,
-  “User signature”, &quot;Authentication Server Signature&quot; and “Signature activation data”. See chapter 3.2.</p>
-</li>
-<li><p> Added the Service Type Entity Categories <code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code> and <code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code> to section 3.1.3.3.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
-<ul class="list">
-<li><p>Object identifiers for the attributes “Transaction identifier”,
-  “Authentication Context Parameters”, “Provisional ID” and
-  “Provisional ID quality indicator” were defined and added to section
-  3.2.</p>
-</li>
-<li><p>Chapter 3.1.7, “XML Schema namespaces”, was removed since the “Level
-  of Assurance context class declarations” are deprecated and thus,
-  the namespace <code>http://id.elegnamnden.se/ns/1.0/loa-context-params</code>
-  is no longer part of the Swedish eID Framework.</p>
-</li>
-<li><p>Authentication Context URIs for use by signature services during
-  authentication was added to section 3.1.1.</p>
-</li>
-<li><p>Service entity categories for future use within the eIDAS Framework
-  were added to section 3.1.3.1.</p>
-</li>
-<li><p>The status code identifier
-  <code>http://id.elegnamnden.se/sig-status/1.0/sigmessage-error</code> was added
-  to section 3.1.6 and the signature response status code <code>http://id.elegnamnden.se/sig-status/1.0/user-cancel</code> was added to section 3.1.7.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
-<ul class="list">
-<li>URI identifiers for Attribute Profiles as specified in [AttrProf]
-  were introduced.</li>
-</ul>
-<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
-<ul class="list">
-<li><p>In chapter 3.1.3.1, “Service Entity Categories”, service entity
-  categories for Level of Assurance 2 and 4 were introduced.</p>
-</li>
-<li><p>  Chapter 3.1.7, “XML Schema namespaces”, was added.</p>
-</li>
-<li><p>  Typos were fixed.</p>
-</li>
-</ul>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/03_-_Registry_for_Identifiers.html b/docs/updates/03_-_Registry_for_Identifiers.html
new file mode 120000
index 0000000..6487b0e
--- /dev/null
+++ b/docs/updates/03_-_Registry_for_Identifiers.html
@@ -0,0 +1 @@
+../december-2024/03_-_Registry_for_Identifiers.html
\ No newline at end of file
diff --git a/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html b/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
deleted file mode 100644
index eeeab56..0000000
--- a/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1,1227 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Attribute Specification for the Swedish eID Framework</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-landscape.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="attribute-specification-for-the-swedish-eid-framework">Attribute Specification for the Swedish eID Framework</h1>
-<h3 id="version-18---2024-11-25---draft-version">Version 1.8 - 2024-11-25 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2019-310</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#terminology">Terminology</a></p>
-<p> 1.2. <a href="#requirement-key-words">Requirement key words</a></p>
-<p> 1.3. <a href="#name-space-references">Name space references</a></p>
-<p> 1.4. <a href="#structure">Structure</a></p>
-</li>
-<li><p><a href="#attribute-sets"><strong>Attribute Sets</strong></a></p>
-<p> 2.1. <a href="#pseudonym-identity">Pseudonym Identity</a></p>
-<p> 2.2. <a href="#natural-personal-identity-without-civic-registration-number">Natural Personal Identity without Civic Registration Number</a></p>
-<p> 2.3. <a href="#natural-personal-identity-with-civic-registration-number">Natural Personal Identity with Civic Registration Number</a></p>
-<p> 2.4. <a href="#organizational-identity-for-natural-persons">Organizational Identity for Natural Persons</a></p>
-<p> 2.5. <a href="#eidas-natural-person-attribute-set">eIDAS Natural Person Attribute Set</a></p>
-<p> 2.6. <a href="#natural-person-identity-with-hsa-id">Natural Person Identity with HSA-ID</a></p>
-</li>
-<li><p><a href="#attribute-definitions"><strong>Attribute Definitions</strong></a></p>
-<p> 3.1. <a href="#attributes">Attributes</a></p>
-<p> 3.1.1. <a href="#attribute-string-values">Attribute String Values</a></p>
-<p> 3.1.2. <a href="#multi-valued-attributes">Multi-valued Attributes</a></p>
-<p> 3.1.3. <a href="#scoped-attributes">Scoped Attributes</a></p>
-<p> 3.2. <a href="#saml-attribute-format">SAML Attribute Format</a></p>
-<p> 3.2.1. <a href="#the-authcontextparams-attribute">The authContextParams Attribute</a></p>
-<p> 3.2.2. <a href="#the-usercertificate-and-usersignature-attributes">The userCertificate, userSignature and authServerSignature Attributes</a></p>
-<p> 3.2.3. <a href="#the-sad-attribute">The sad Attribute</a></p>
-<p> 3.2.4. <a href="#the-signmessagedigest-attribute">The signMessageDigest Attribute</a></p>
-<p> 3.2.5. <a href="#the-orgaffiliation-attribute">The orgAffiliation Attribute</a></p>
-<p> 3.2.6. <a href="#the-previouspersonalidentitynumber-attribute">The previousPersonalIdentityNumber Attribute</a></p>
-<p> 3.3. <a href="#attributes-for-the-eidas-framework">Attributes for the eIDAS Framework</a></p>
-<p> 3.3.1. <a href="#the-prid-and-pridpersistence-attributes">The prid and pridPersistence Attributes</a></p>
-<p> 3.3.2. <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes</a></p>
-<p> 3.3.3. <a href="#conversion-of-eidas-attributes">Conversion of eIDAS Attributes</a></p>
-<p> 3.3.3.1. <a href="#conversion-of-eidas-currentaddress">Conversion of eIDAS CurrentAddress</a></p>
-</li>
-<li><p><a href="#references"><strong>References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1-introduction">1. Introduction</h2>
-<p>This document specifies an attribute profile for the Swedish eID
-Framework. The attribute profile defines attributes for use within the
-Swedish eID Framework, and a number of defined attribute sets that may
-be referenced by other documents as means to specify specific attribute
-release requirements.</p>
-<p><a name="terminology"></a></p>
-<h3 id="11-terminology">1.1. Terminology</h3>
-<table>
-<thead>
-<tr>
-<th align="left">Term</th>
-<th align="left">Defined meaning</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>Attribute</strong></td>
-<td align="left">A property, quality or characteristic of a person, thing or object. This term is used in general in this specification to denote an attribute of a person/entity that is represented by a set of attributes in a SAML attribute statement (see SAML Attribute). This term is also used in this specification when describing XML syntax to denote an attribute (property) of an XML element.</td>
-</tr>
-<tr>
-<td align="left"><strong>SAML attribute</strong></td>
-<td align="left">An attribute of an entity represented by a set of attributes in a SAML attribute statement (<code>&lt;saml:AttributeStatement&gt;</code> element).</td>
-</tr>
-<tr>
-<td align="left"><strong>IDP</strong></td>
-<td align="left">Identity Provider</td>
-</tr>
-<tr>
-<td align="left"><strong>SP</strong></td>
-<td align="left">Service Provider</td>
-</tr>
-<tr>
-<td align="left"><strong>Natural person</strong></td>
-<td align="left">Natural person is legal term for a real human being, as opposed to a legal person, which may be a private (i.e., business entity) or public (i.e., government) organization.</td>
-</tr>
-<tr>
-<td align="left"><strong>Civic registration number</strong></td>
-<td align="left">A unique identifier assigned to each natural person in a national population register. Within the context of this specification this is a Swedish ”personnummer” or ”samordningsnummer” according to [SKV704] and [SKV707].</td>
-</tr>
-</tbody></table>
-<p><a name="requirement-key-words"></a></p>
-<h3 id="12-requirement-key-words">1.2. Requirement key words</h3>
-<p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
-“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
-interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
-<p>These keywords are capitalized when used to unambiguously specify
-requirements over protocol features and behavior that affect the
-interoperability and security of implementations. When these words are
-not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="name-space-references"></a></p>
-<h3 id="13-name-space-references">1.3. Name space references</h3>
-<p>Conventional XML namespace prefixes are used throughout the listings in
-this specification to stand for their respective namespaces as follows,
-whether or not a namespace declaration is present in the example:</p>
-<table>
-<thead>
-<tr>
-<th align="left">Prefix</th>
-<th align="left">XML Namespace</th>
-<th align="left">Comments</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><code>saml</code></td>
-<td align="left"><code>urn:oasis:names:tc:SAML:2.0:assertion</code></td>
-<td align="left">The SAML V2.0 assertion namespace, defined in the schema [<a href="#saml-xsd">SAML-XSD</a>].</td>
-</tr>
-<tr>
-<td align="left"><code>xs</code></td>
-<td align="left"><code>http://www.w3.org/2001/XMLSchema</code></td>
-<td align="left">The XML Schema namespace, representing definitions of data types in [<a href="#xml-schema">XML-Schema</a>].</td>
-</tr>
-</tbody></table>
-<p><a name="structure"></a></p>
-<h3 id="14-structure">1.4. Structure</h3>
-<p>This specification uses the following typographical conventions in text: <code>&lt;ns:Element&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>, <code>OtherCode</code>.</p>
-<p><a name="attribute-sets"></a></p>
-<h2 id="2-attribute-sets">2. Attribute Sets</h2>
-<p>This section defines attribute sets based on attribute definitions in
-<a href="#attribute-definitions">section 3</a>. Common to all attribute sets is that each attribute MUST NOT
-be present more than once. An attribute that has more than one value
-MUST be provided as one attribute with multiple <code>&lt;AttributeValue&gt;</code>
-sub-elements in accordance with <a href="#attributes">section 3.1</a>.</p>
-<p>An identifier, named “Attribute Set Identifier”, and an URI, are defined
-for each attribute set as means for other documents to reference
-specific attribute sets.</p>
-<p>Each attribute set defines a number of mandatory attributes that MUST be
-released by an Attribute Provider<sup>*</sup> that provides attributes according
-to the given attribute set, and optionally recommended attributes that
-SHOULD be released as part of the attribute set if they are available to
-the provider.</p>
-<p><strong>Note</strong>: An Attribute Provider may also release other attributes, not
-specified by the defined attribute sets it supports. See further section
-6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish
-eID Framework” ([<a href="#eiddeployprof">EidDeployProf</a>]).</p>
-<p>In order to comply with a defined attribute set, the following attribute
-requirements apply:</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Definition</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong></td>
-<td align="left">Attributes that MUST be present.</td>
-</tr>
-<tr>
-<td align="left"><strong>RECOMMENDED</strong></td>
-<td align="left">Attributes that SHOULD be present, if available.</td>
-</tr>
-</tbody></table>
-<p>A defined attribute set does not define any rules for attributes other
-than those listed as required or recommended.</p>
-<blockquote>
-<p>[*]: An Attribute Provider is an entity that releases attributes to a requesting entity. In all practical cases within the Swedish eID Framework this entity is an Identity Provider or an Attribute Authority. Within the eIDAS Framework, the Swedish eIDAS node acts as the Attribute Provider for the Service Providers.</p>
-</blockquote>
-<p><a name="pseudonym-identity"></a></p>
-<h3 id="21-pseudonym-identity">2.1. Pseudonym Identity</h3>
-<p>Attribute set identifier: <strong>ELN-AP-Pseudonym-01</strong></p>
-<p>URI: <code>http://id.elegnamnden.se/ap/1.0/pseudonym-01</code></p>
-<p>This attribute set specifies the condition where there are no mandatory or recommended attributes.</p>
-<p><strong>Typical use</strong>: In a pseudonym attribute release policy that just provides a persistent <code>NameID</code> identifier in the assertion but no attributes.</p>
-<p><a name="natural-personal-identity-without-civic-registration-number"></a></p>
-<h3 id="22-natural-personal-identity-without-civic-registration-number">2.2. Natural Personal Identity without Civic Registration Number</h3>
-<p>Attribute set identifier: <strong>ELN-AP-NaturalPerson-01</strong></p>
-<p>URI: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
-<p>The “Personal Identity without Civic Registration Number” attribute set provides basic natural person information without revealing the civic registration number of the subject.</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Attributes</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong></td>
-<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name)</td>
-</tr>
-</tbody></table>
-<p><strong>Typical use</strong>: In an attribute release policy that provides basic user name information together with a persistent <code>NameID</code> identifier in the assertion.</p>
-<p><a name="natural-personal-identity-with-civic-registration-number"></a></p>
-<h3 id="23-natural-personal-identity-with-civic-registration-number">2.3. Natural Personal Identity with Civic Registration Number</h3>
-<p>Attribute set identifier: <strong>ELN-AP-Pnr-01</strong></p>
-<p>URI: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
-<p>The “Personal Identity with Civic Registration Number” attribute set provides basic personal identity information including a Swedish civic registration number of the subject.</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Attributes</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong></td>
-<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name) <br /> <code>personalIdentityNumber</code> (National civic registration number)</td>
-</tr>
-<tr>
-<td align="left"><strong>RECOMMENDED</strong></td>
-<td align="left"><code>dateOfBirth</code> (Date of birth)</td>
-</tr>
-</tbody></table>
-<p><strong>Typical use</strong>: In an attribute release policy that provides basic user name information together with the person’s Swedish civic registration number.</p>
-<p><a name="organizational-identity-for-natural-persons"></a></p>
-<h3 id="24-organizational-identity-for-natural-persons">2.4. Organizational Identity for Natural Persons</h3>
-<p>Attribute set identifier: <strong>ELN-AP-OrgPerson-01</strong></p>
-<p>URI: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
-<p>The “Organizational Identity for Natural Persons” attribute set provides basic organizational identity information about a person. The organizational identity does not necessarily imply that the subject has any particular relationship with or standing within the organization, but rather that this identity has been issued/provided by that organization for any particular reason (employee, customer, consultant, etc.).</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Attributes</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong></td>
-<td align="left"><code>displayName</code> (Display name)<sup>*</sup> <br /> <code>orgAffiliation</code> (Personal identifier and organizational identifier code)<sup>**</sup> <br /> <code>o</code> (Organization name)</td>
-</tr>
-<tr>
-<td align="left"><strong>RECOMMENDED</strong></td>
-<td align="left"><code>organizationIdentifier</code> (Organizational identifier code)<sup>***</sup></td>
-</tr>
-</tbody></table>
-<p><strong>Typical use</strong>: In an attribute release policy that provides basic organizational identity information about a natural person.</p>
-<p>The &quot;Organizational Identity for Natural Persons&quot; attribute set defines a minimum set of attributes needed to provide organizational identity information about a person. Should an attribute consumer require additional attributes, such as surname and given name, the personal identity number or an organizational unit name, this can be achieved by either requesting other attribute sets or by explicitly requesting individual attributes. See further section 6.2.1, “Attribute Release and Consuming Rules”, of “Deployment Profile for the Swedish eID Framework” ([<a href="#eiddeployprof">EidDeployProf</a>]).</p>
-<blockquote>
-<p>[*]: The <code>displayName</code> attribute MAY contain personal information such as the given name or surname, but it MAY also be used as an anonymized display name, for example, &quot;Administrator 123&quot;. This is decided by the issuing organization.</p>
-</blockquote>
-<blockquote>
-<p>[**]: See section <a href="#the-orgaffiliation-attribute">3.2.5</a>.</p>
-</blockquote>
-<blockquote>
-<p>[***]: The organizational identifier can always be derived from the mandatory <code>orgAffiliation</code> attribute, but an attribute provider supporting the &quot;Organizational Identity for Natural Persons&quot; attribute set SHOULD also release the <code>organizationIdentifier</code> attribute individually. </p>
-</blockquote>
-<p><a name="eidas-natural-person-attribute-set"></a></p>
-<h3 id="25-eidas-natural-person-attribute-set">2.5. eIDAS Natural Person Attribute Set</h3>
-<p>Attribute set identifier: <strong>ELN-AP-eIDAS-NatPer-01</strong></p>
-<p>URI: <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></p>
-<p>The “eIDAS Natural Person Attribute Set” provides personal identity
-information for a subject that has been authenticated via the eIDAS
-Framework.</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Attributes</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong><sup>*</sup></td>
-<td align="left"><code>prid</code> (Provisional ID) <br /> <code>pridPersistence</code> (Provisional ID persistence indicator) <br /> <code>eidasPersonIdentifier</code> (Mapping of the eIDAS PersonIdentifier attribute) <br /> <code>dateOfBirth</code> (Date of birth) <br /> <code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>c</code> (Country code for the eIDAS country that authenticated the subject) <br /><code>transactionIdentifier</code> (ID of assertion issued by the member state node)<sup>**</sup></td>
-</tr>
-<tr>
-<td align="left"><strong>REQUIRED</strong><br />(if available)<sup>***</sup></td>
-<td align="left"><code>birthName</code> (Birth name) <br /> <code>placeOfBirth</code> (Place of birth) <br /> <code>eidasNaturalPersonAddress</code> (Address for natural person) <br /> <code>gender</code> (Gender)</td>
-</tr>
-<tr>
-<td align="left"><strong>RECOMMENDED</strong></td>
-<td align="left"><code>mappedPersonalIdentityNumber</code> (Mapped national civic registration number) <br /> <code>personalIdentityNumberBinding</code> (National civic registration number Binding(s))</td>
-</tr>
-</tbody></table>
-<p><strong>Typical use</strong>: In an attribute release policy implemented by an eIDAS
-connector that provides a complete set of attributes to a requesting
-Service Provider.</p>
-<p><strong>Note</strong>: The <code>mappedPersonalIdentityNumber</code> and <code>personalIdentityNumberBinding</code>
-attributes will be part of the attribute release if the attribute
-provider has access to enough information to provide a binding
-between eIDAS attributes and a Swedish identity number (see <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section
-3.3.2</a>).</p>
-<p>The eIDAS attribute set comprises of “added” and “converted” attributes.</p>
-<p><strong>Added attributes</strong>: Attributes that are not provided by the member
-state node, but added by the
-Swedish eIDAS node in order to provide additional information about
-the authenticated subject obtained from relevant domestic attribute
-sources. The <code>prid</code>, <code>pridPersistence</code> and <code>personalIdentityNumber</code>
-attributes are “added attributes”.</p>
-<p><strong>Converted attributes</strong>: Attributes that are the result of a
-conversion process where an eIDAS attribute is converted into a
-single-value string type attribute defined within the Swedish eID
-Framework (see section <a href="#conversion-of-eidas-attributes">3.3.3</a>, “<a href="#conversion-of-eidas-attributes">Conversion of eIDAS Attributes</a>”). The
-reason for the conversion is to facilitate processing for attribute
-consumers. The eIDAS attributes are not simple string types, and this
-affects interoperability in a negative way since standard SAML
-software need to be modified to support these attributes. Therefore,
-the Swedish eID node will convert eIDAS attributes to their
-corresponding string value-typed attributes. The
-<code>eidasPersonIdentifier</code>, <code>sn</code>, <code>givenName</code> and <code>dateOfBirth</code> attributes are
-examples of “converted attributes”.</p>
-<blockquote>
-<p>[*]: Attributes “added” by the Swedish eID node and converted attributes for the mandatory attributes of the eIDAS minimum data set for natural persons.</p>
-</blockquote>
-<blockquote>
-<p>[**]: The transaction identifier attribute will contain the unique ID of the assertion that was issued by the member state node. This information together with the entityID of the member state node (found in the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element of an assertion) give a reference to the original assertion and authentication process.</p>
-</blockquote>
-<blockquote>
-<p>[***]: Converted attributes for the optional attributes of the eIDAS minimum data set for natural persons.</p>
-</blockquote>
-<p><a name="natural-person-identity-with-hsa-id"></a></p>
-<h3 id="26-natural-person-identity-with-hsa-id">2.6. Natural Person Identity with HSA-ID</h3>
-<p>Attribute set identifier: <strong>DIGG-AP-HSAid-01</strong></p>
-<p>URI: <code>http://id.swedenconnect.se/ap/1.0/hsaid-01</code></p>
-<p>The “Natural Person Identity with HSA-ID” attribute set provides basic personal identity information including a HSA-ID of the subject (see [<a href="#sambiattr">SambiAttr</a>]).</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute requirement</th>
-<th align="left">Attributes</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>REQUIRED</strong></td>
-<td align="left"><code>sn</code> (Surname) <br /> <code>givenName</code> (Given name) <br /> <code>displayName</code> (Display name) <br /> <code>employeeHsaId</code> (HSA-ID)</td>
-</tr>
-<tr>
-<td align="left"><strong>RECOMMENDED</strong></td>
-<td align="left"><code>dateOfBirth</code> (Date of birth)</td>
-</tr>
-</tbody></table>
-<p><strong>Typical use</strong>: In an attribute release policy that provides basic user name information together with the person’s HSA-ID.</p>
-<p><a name="attribute-definitions"></a></p>
-<h2 id="3-attribute-definitions">3. Attribute Definitions</h2>
-<p><a name="attributes"></a></p>
-<h3 id="31-attributes">3.1. Attributes</h3>
-<p>The following attributes are defined for use within the attribute profile for the Swedish eID Framework:</p>
-<table>
-<thead>
-<tr>
-<th align="left">Attribute abbreviation</th>
-<th align="left">SAML attribute name</th>
-<th align="left">Description</th>
-<th align="left">Use within this specification</th>
-<th align="center">Multi-valued</th>
-<th align="left">Scoped</th>
-<th align="left">Example</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left">sn</td>
-<td align="left">urn:oid:2.5.4.4</td>
-<td align="left">Surname</td>
-<td align="left">Registered surname.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Lindeman</td>
-</tr>
-<tr>
-<td align="left">givenName</td>
-<td align="left">urn:oid:2.5.4.42</td>
-<td align="left">Given Name</td>
-<td align="left">Registered given name.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Valfrid</td>
-</tr>
-<tr>
-<td align="left">displayName</td>
-<td align="left">urn:oid:2.16.840.1.<br/>113730.3.1.241</td>
-<td align="left">Display Name</td>
-<td align="left">A name in any preferred presentation format.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Valfrid Lindeman</td>
-</tr>
-<tr>
-<td align="left">gender</td>
-<td align="left">urn:oid:1.3.6.1.5.5.7.9.3</td>
-<td align="left">Gender</td>
-<td align="left">A one letter representation (“M”/”F”/”U” or “m”/“f”/”u”) representing the subject’s gender, where “M” represents male, “F” represents female and “U” is used for unspecified, or unknown, gender.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">M</td>
-</tr>
-<tr>
-<td align="left">personalIdentity-<br/>Number</td>
-<td align="left">urn:oid:1.2.752.29.4.13</td>
-<td align="left">National civic registration number/code</td>
-<td align="left">Swedish ”personnummer” or ”samordningsnummer” according to <a href="#skv704">SKV 704</a> and <a href="#skv707">SKV 707</a>. 12 digits without hyphen.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">195006262546</td>
-</tr>
-<tr>
-<td align="left">previousPersonal-<br/>IdentityNumber</td>
-<td align="left">urn:oid:1.2.752.201.3.15</td>
-<td align="left">A user&#39;s previous national civic registration number, see <a href="#the-previouspersonalidentitynumber-attribute">section 3.2.6</a> below.</td>
-<td align="left">See <code>personalIdentityNumber</code> above.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">197010632391</td>
-</tr>
-<tr>
-<td align="left">dateOfBirth</td>
-<td align="left">urn:oid:1.3.6.1.5.5.7.9.1</td>
-<td align="left">Date of birth</td>
-<td align="left">Date of birth expressed using the format YYYY-MM-DD.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">1950-06-26</td>
-</tr>
-<tr>
-<td align="left">birthName</td>
-<td align="left">urn:oid:1.2.752.201.3.8</td>
-<td align="left">Name at the time of birth</td>
-<td align="left">Full name of a person at birth.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Valfrid Danielsson</td>
-</tr>
-<tr>
-<td align="left">street</td>
-<td align="left">urn:oid:2.5.4.9</td>
-<td align="left">Street address</td>
-<td align="left">Street address.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Mosebacke torg 3</td>
-</tr>
-<tr>
-<td align="left">postOfficeBox</td>
-<td align="left">urn:oid:2.5.4.18</td>
-<td align="left">Post box</td>
-<td align="left">Post box.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Box 1122</td>
-</tr>
-<tr>
-<td align="left">postalCode</td>
-<td align="left">urn:oid:2.5.4.17</td>
-<td align="left">Postal code</td>
-<td align="left">Postal code.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">11826</td>
-</tr>
-<tr>
-<td align="left">l</td>
-<td align="left">urn:oid:2.5.4.7</td>
-<td align="left">Locality</td>
-<td align="left">Locality.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Stockholm</td>
-</tr>
-<tr>
-<td align="left">c</td>
-<td align="left">urn:oid:2.5.4.6</td>
-<td align="left">Country</td>
-<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">SE</td>
-</tr>
-<tr>
-<td align="left">placeOfBirth</td>
-<td align="left">urn:oid:1.3.6.1.5.5.7.9.2</td>
-<td align="left">Place of birth</td>
-<td align="left">A string representing the place of birth.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Stockholm</td>
-</tr>
-<tr>
-<td align="left">countryOfCitizenship</td>
-<td align="left">urn:oid:1.3.6.1.5.5.7.9.4</td>
-<td align="left">Country of citizenship</td>
-<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code representing a country of citizenship.</td>
-<td align="center">Yes</td>
-<td align="left">No</td>
-<td align="left">SE</td>
-</tr>
-<tr>
-<td align="left">countryOfResidence</td>
-<td align="left">urn:oid:1.3.6.1.5.5.7.9.5</td>
-<td align="left">Country of Residence</td>
-<td align="left">ISO 3166-1 alpha-2 [ISO3166] two letter country code representing the country of residence.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">SE</td>
-</tr>
-<tr>
-<td align="left">telephoneNumber</td>
-<td align="left">urn:oid:2.5.4.20</td>
-<td align="left">Telephone number</td>
-<td align="left">Telephone number.</td>
-<td align="center">Yes</td>
-<td align="left">No</td>
-<td align="left">+46890510</td>
-</tr>
-<tr>
-<td align="left">mobile</td>
-<td align="left">urn:oid:0.9.2342.<br/>19200300.100.1.41</td>
-<td align="left">Mobile number</td>
-<td align="left">Mobile number.</td>
-<td align="center">Yes</td>
-<td align="left">No</td>
-<td align="left">+46703419886</td>
-</tr>
-<tr>
-<td align="left">mail</td>
-<td align="left">urn:oid:0.9.2342.<br/>19200300.100.1.3</td>
-<td align="left">E-mail address</td>
-<td align="left">E-mail address.</td>
-<td align="center">Yes</td>
-<td align="left">Yes/No<sup>*</sup></td>
-<td align="left"><a href="mailto:&#x76;&#x66;&#x6c;&#64;&#x6d;&#x6f;&#115;&#x65;&#x62;&#x61;&#99;&#107;&#101;&#109;&#111;&#110;&#x61;&#x72;&#107;&#105;&#x2e;&#115;&#x65;">&#x76;&#x66;&#x6c;&#64;&#x6d;&#x6f;&#115;&#x65;&#x62;&#x61;&#99;&#107;&#101;&#109;&#111;&#110;&#x61;&#x72;&#107;&#105;&#x2e;&#115;&#x65;</a></td>
-</tr>
-<tr>
-<td align="left">o</td>
-<td align="left">urn:oid:2.5.4.10</td>
-<td align="left">Organization name</td>
-<td align="left">Registered organization name.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">Skatteverket</td>
-</tr>
-<tr>
-<td align="left">ou</td>
-<td align="left">urn:oid:2.5.4.11</td>
-<td align="left">Organizational unit name</td>
-<td align="left">Organizational unit name.</td>
-<td align="center">Yes</td>
-<td align="left">No</td>
-<td align="left">IT-Avdelningen</td>
-</tr>
-<tr>
-<td align="left">organizationIdentifier</td>
-<td align="left">urn:oid:2.5.4.97</td>
-<td align="left">Organizational identifier code</td>
-<td align="left">Swedish “organisationsnummer” according to <a href="#skv709">SKV 709</a>. 10 digits without hyphen.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">5562265719</td>
-</tr>
-<tr>
-<td align="left">orgAffiliation</td>
-<td align="left">urn:oid:1.2.752.201.3.1</td>
-<td align="left">&lt;uid&gt;@&lt;orgnr&gt;</td>
-<td align="left"><em>Personal ID</em> @ Swedish ”organisationsnummer” according to <a href="#skv709">SKV 709</a>. 10 digits without hyphen.</td>
-<td align="center">Yes</td>
-<td align="left">Yes</td>
-<td align="left">vlindman@5562265719<br />See <a href="#the-orgaffiliation-attribute">section 3.2.5</a> below.</td>
-</tr>
-<tr>
-<td align="left">transactionIdentifier</td>
-<td align="left">urn:oid:1.2.752.201.3.2</td>
-<td align="left">Transaction identifier</td>
-<td align="left">Transaction identifier for an event, e.g. an authentication process.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left"><em>9878HJ6687 (arbitrary string)</em></td>
-</tr>
-<tr>
-<td align="left">authContextParams</td>
-<td align="left">urn:oid:1.2.752.201.3.3</td>
-<td align="left">Authentication Context Parameters.</td>
-<td align="left">Key-value pairs from an authentication process. Defined by issuing entity.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-authcontextparams-attribute">section 3.2.1</a> below.</td>
-</tr>
-<tr>
-<td align="left">userCertificate</td>
-<td align="left">urn:oid:1.2.752.201.3.10</td>
-<td align="left">User certificate</td>
-<td align="left">Base64-encoding of a user certificate.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
-</tr>
-<tr>
-<td align="left">userSignature</td>
-<td align="left">urn:oid:1.2.752.201.3.11</td>
-<td align="left">User signature</td>
-<td align="left">Base64-encoding of a signature object applied by the user.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
-</tr>
-<tr>
-<td align="left">authServerSignature</td>
-<td align="left">urn:oid:1.2.752.201.3.13</td>
-<td align="left">Authentication server signature</td>
-<td align="left">Base64-encoding of a authentication server signature.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-usercertificate-and-usersignature-attributes">section 3.2.2</a> below.</td>
-</tr>
-<tr>
-<td align="left">sad</td>
-<td align="left">urn:oid:1.2.752.201.3.12</td>
-<td align="left">Signature activation data</td>
-<td align="left">Signature activation data required by signature services.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-sad-attribute">section 3.2.3</a> below.</td>
-</tr>
-<tr>
-<td align="left">signMessageDigest</td>
-<td align="left">urn:oid:1.2.752.201.3.14</td>
-<td align="left">Sign message digest</td>
-<td align="left">Included in assertions as a proof that a user sign message was displayed.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#the-signmessagedigest-attribute">section 3.2.4</a> below.</td>
-</tr>
-<tr>
-<td align="left">prid</td>
-<td align="left">urn:oid:1.2.752.201.3.4</td>
-<td align="left">Provisional identifier</td>
-<td align="left">Unique identifier for an authentication performed against the eIDAS Framework. See <a href="#the-prid-and-pridpersistence-attributes">section 3.3.1</a> below.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">NO:5068907693</td>
-</tr>
-<tr>
-<td align="left">pridPersistence</td>
-<td align="left">urn:oid:1.2.752.201.3.5</td>
-<td align="left">Provisional identifier persistence indicator</td>
-<td align="left">Indicator for the expected persistence of the prid attribute. See <a href="#the-prid-and-pridpersistence-attributes">section 3.3.1</a> below.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">A</td>
-</tr>
-<tr>
-<td align="left">personalIdentity-<br/>NumberBinding</td>
-<td align="left">urn:oid:1.2.752.201.3.6</td>
-<td align="left">National civic registration number/code binding URI</td>
-<td align="left">URI(s) identifying the binding process(es) performed of the <code>mappedPersonalIdentityNumber</code> attribute added by eIDAS connector. See <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section 3.3.2</a> below.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left"><code>http://id.swedenconnect.se/</code><br /><code>id-binding/process/populationregister</code></td>
-</tr>
-<tr>
-<td align="left">mappedPersonal-<br />IdentityNumber</td>
-<td align="left">urn:oid:1.2.752.201.3.16</td>
-<td align="left">Mapped national civic registration number</td>
-<td align="left">A &quot;mapped&quot; personalIdentityNumber, see <a href="#the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute">section 3.3.2</a>.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">195006262546</td>
-</tr>
-<tr>
-<td align="left">eidasPersonIdentifier</td>
-<td align="left">urn:oid:1.2.752.201.3.7</td>
-<td align="left">eIDAS uniqueness identifier for natural persons</td>
-<td align="left">Maps the eIDAS PersonIdentifier attribute to a string attribute within the scope of the Swedish eID Framework attribute set.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">ES/AT/02635542Y (Spanish eID number for an Austrian SP)</td>
-</tr>
-<tr>
-<td align="left">eidasNatural-<br/>PersonAddress</td>
-<td align="left">urn:oid:1.2.752.201.3.9</td>
-<td align="left">eIDAS Natural Person Address</td>
-<td align="left">Attribute for converting the eIDAS CurrentAddress attribute into an attribute having a string type value.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See <a href="#conversion-of-eidas-currentaddress">section 3.3.3.1</a> below.</td>
-</tr>
-<tr>
-<td align="left">employeeHsaId</td>
-<td align="left">urn:oid:1.2.752.29.6.2.1</td>
-<td align="left">HSA-ID</td>
-<td align="left">Person identifier used by Swedish health care organizations.</td>
-<td align="center">No</td>
-<td align="left">No</td>
-<td align="left">See [<a href="#sambiattr">SambiAttr</a>].</td>
-</tr>
-</tbody></table>
-<blockquote>
-<p>[*]: The <code>mail</code> attribute should be regarded as a scoped attribute (see <a href="#scoped-attributes">3.1.3</a> below) if the attribute release policy in use has stated it as scoped. Such a policy can for example be that the attribute is part of an attribute set (see <a href="#attribute-sets">section 2</a>) that documents the attribute as scoped. In all other cases the attribute is regarded as non-scoped.</p>
-</blockquote>
-<p><a name="attribute-string-values"></a></p>
-<h4 id="311-attribute-string-values">3.1.1. Attribute String Values</h4>
-<p>All attributes, unless stated otherwise in this table, holds string values using the UTF-8 character set using the <code>xs:string</code> data type. Certain attributes such as <code>mail</code>, <code>personalIdentityNumber</code>, <code>organizationIdentifier</code>, <code>telephoneNumber</code> and <code>mobile</code> use a restricted character set according to its defined usage within this specification.</p>
-<p>All attributes use the “caseIgnoreMatch” matching rule as defined by X.520 [<a href="#x520">X.520</a>]. That is, case-insensitive comparison where insignificant spaces are ignored.</p>
-<p><a name="multi-valued-attributes"></a></p>
-<h4 id="312-multi-valued-attributes">3.1.2. Multi-valued Attributes</h4>
-<p>Attributes with a “No” value in the column &quot;Multi-valued&quot; MUST NOT have more than one <code>&lt;AttributeValue&gt;</code> sub-element. Attributes with a “Yes” value in the column &quot;Multi-valued&quot; MAY have one or more <code>&lt;AttributeValue&gt;</code> sub-elements.</p>
-<p><a name="scoped-attributes"></a></p>
-<h4 id="313-scoped-attributes">3.1.3. Scoped Attributes</h4>
-<p>Attributes with a &quot;Yes&quot; value in the column &quot;Scoped&quot; are scoped attributes. A scoped attribute expresses values in a string-valued attribute of the form <code>value@scope</code>, where <code>scope</code> takes the form of a domain name or something similar such as an organizational identifier.</p>
-<p>An Identity Provider wishing to release scoped attributes must register the scopes with the federation operator. After the federation operator has authorized the Identity Provider for the given scopes, they are declared in the Identity Provider&#39;s metadata entry. See section 2.1.3.1 of [<a href="#eiddeployprof">EidDeployProf</a>] for details.    </p>
-<p>A Service Provider consuming a scoped attribute SHOULD assert that the issuing Identity Provider is authorized to issue attributes with the given scope by checking the Identity Provider&#39;s metadata entry as described in section 6.2.1 of [<a href="#eiddeployprof">EidDeployProf</a>].</p>
-<p><strong>Note:</strong> The <code>value</code> part of a scoped attribute MAY contain a <code>@</code>-character, for example when the value part is an email address, or a User Principal Name (UPN). Therefore, consumers of scoped attributes MUST use the last <code>@</code>-character as a delimiting character when splitting a scoped attribute into its <code>value</code> and <code>scope</code> parts.</p>
-<p><a name="saml-attribute-format"></a></p>
-<h3 id="32-saml-attribute-format">3.2. SAML Attribute Format</h3>
-<p>The <code>&lt;saml:Attribute&gt;</code> element representing an attribute in <a href="#attributes">3.1</a> SHALL comply with the following requirements:</p>
-<ul class="list">
-<li><p>The <code>NameFormat</code> attribute SHALL have the value <code>urn:oasis:names:tc:SAML:2.0:attrname-format:uri</code>.</p>
-</li>
-<li><p>The <code>Name</code> attribute SHALL hold a URI according to the table in <a href="#attributes">section 3.1</a>.</p>
-</li>
-<li><p>The <code>FriendlyName</code> attribute is OPTIONAL.</p>
-</li>
-<li><p>All <code>&lt;AttributeValue&gt;</code> sub-elements SHALL, unless stated otherwise in the table in <a href="#attributes">section 3.1</a>, have an <code>xsi:type</code> attribute specifying the type <code>&quot;xs:string&quot;</code>.</p>
-</li>
-</ul>
-<p>The following is an example of the surname attribute. Its name is “urn:oid:2.5.4.4”, its friendly name is “sn” and the value is represented using a string type.</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">xmlns:xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
-                           <span class="hljs-attr">FriendlyName</span>=<span class="hljs-string">&quot;sn&quot;</span>
-                           <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:2.5.4.4&quot;</span>
-                           <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>Eriksson<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span></code></pre><p><a name="the-authcontextparams-attribute"></a></p>
-<h4 id="321-the-authcontextparams-attribute">3.2.1. The authContextParams Attribute</h4>
-<p>The attribute <code>authContextParams</code> holds key-value pairs. Its purpose is to store key-value pairs representing data from an authentication process. The data stored in this attribute is generally not defined by the Swedish eID Framework, but instead by the issuing party (i.e., the Identity Provider).</p>
-<p>The <code>authContextParams</code> attribute is a non-empty single-value attribute where the attribute value contains the key-value pairs separated by semicolons. The key and value of each pair is separated by a ‘=’ character and both the key and value MUST be URL-encoded.</p>
-<p>Below follows an example of how the authContextParams attribute is populated with two key-value pairs, &quot;foo&quot; that stores the value &quot;ÅÄÖ&quot;, and &quot;bar&quot; that stores the value &quot;123&quot;.</p>
-<pre class="hljs"><code>...
-&lt;saml<span class="hljs-number">2</span>:Attribute xmlns:xsi<span class="hljs-operator">=</span><span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>    
-                           FriendlyName<span class="hljs-operator">=</span><span class="hljs-string">&quot;authContextParams&quot;</span>
-                           Name<span class="hljs-operator">=</span><span class="hljs-string">&quot;urn:oid:1.2.752.201.3.3&quot;</span>
-                           NameFormat<span class="hljs-operator">=</span><span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;
-  &lt;saml<span class="hljs-number">2</span>:AttributeValue xsi:<span class="hljs-keyword">type</span><span class="hljs-operator">=</span><span class="hljs-string">&quot;xs:string&quot;</span>&gt;foo<span class="hljs-operator">=</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%85</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%84</span><span class="hljs-variable">%C3</span><span class="hljs-variable">%96</span><span class="hljs-comment">;bar=123&lt;/saml2:AttributeValue&gt;</span>
-&lt;/saml<span class="hljs-number">2</span>:Attribute&gt;
-...</code></pre><p><a name="the-usercertificate-and-usersignature-attributes"></a></p>
-<h4 id="322-the-usercertificate-usersignature-and-authserversignature-attributes">3.2.2. The userCertificate, userSignature and authServerSignature Attributes</h4>
-<p>Identity Providers that implement a PKI-based authentication method may
-make use of the <code>userCertificate</code> and <code>userSignature</code> attributes.</p>
-<p>The <code>userCertificate</code> attribute holds, as its value, a base64-encoding of
-the X.509 certificate presented by the subject during authentication.</p>
-<p>The <code>userSignature</code> attribute contains a base64-encoding of a signature
-object that was created by the subject during the authentication<sup>*</sup>
-process.</p>
-<p>The <code>authServerSignature</code> may be included in assertions in cases where there are requirements to include a digitally signed proof from the authentication server at which the end user authenticated. This is mainly useful in cases where the SAML Identity Provider delegates end user authentication to a subordinate authentication server.</p>
-<blockquote>
-<p>[*]: Note that an authentication process, may be “authentication for signature” as specified in section 7 of [<a href="#eiddeployprof">EidDeployProf</a>].</p>
-</blockquote>
-<p><a name="the-sad-attribute"></a></p>
-<h4 id="323-the-sad-attribute">3.2.3. The sad Attribute</h4>
-<p>The <code>sad</code> attribute holds Signature Activation Data that is required by a
-signature service in order to service a signature request in accordance
-with CEN EN 419 241-2. The <code>sad</code> attribute holds a single string
-attribute value. The format of the string value is defined in the &quot;Signature Activation Protocol 
-for Federated Signing&quot; specification [<a href="#sigsap">SigSAP</a>].</p>
-<p><a name="the-signmessagedigest-attribute"></a></p>
-<h4 id="324-the-signmessagedigest-attribute">3.2.4. The signMessageDigest Attribute</h4>
-<p>The <code>signMessageDigest</code> attribute is included in an assertion as a proof that an Identity Provider displayed
-a sign message for the user and that the user actively confirmed acceptance of this sign message. This sign 
-message is the <code>SignMessage</code> extension that may be included in an authentication request by Signature Service 
-Service Providers. See section 7 of [<a href="#eiddeployprof">EidDeployProf</a>] for details.</p>
-<p>The attribute value format for the <code>signMessageDigest</code> attribute is <code>digest-algorithm-identifier;sign-message-digest</code>, where
-<code>digest-algorithm-identifier</code> is the XML Security algorithm URI identifier of the selected digest algorithm and
-<code>sign-message-digest</code> is <code>base64(digest(msg))</code>. The <code>msg</code> is the UTF-8 encoded bytes of the sign message that was displayed. It equals the <code>csig:Message</code> element value of the <code>csig:SignMessage</code> ([<a href="#dssext">DSSExt</a>]). Thus, if the <code>csig:Message</code> element is encrypted into a <code>csig:EncryptedMessage</code>, the element value after decryption should be used.</p>
-<p>Entities compliant with this specification MUST use <code>http://www.w3.org/2001/04/xmlenc#sha256</code> as the digest algorithm, 
-unless the recipient of the <code>signMessageDigest</code> attribute has declared another digest algorithm as preferred in its
-metadata entry (see section 2.1.1.3 of [<a href="#eiddeployprof">EidDeployProf</a>]). In those cases this algorithm MAY be used.</p>
-<p><strong>Example:</strong></p>
-<p>Suppose that the unencrypted message is &quot;I hereby confirm that I want to join example.com as a customer&quot;. This is
-represented as:</p>
-<pre class="hljs"><code><span class="hljs-section">&lt;csig:Message&gt;</span>
-  <span class="hljs-attribute">SSBoZXJlYnkgY29uZmlybSB0aGF0IEkgd2FudCB0byBqb2luIGV4YW1wbGUuY29tIGFzIGEgY3VzdG9tZXI</span>=
-<span class="hljs-section">&lt;/csig:Message&gt;</span></code></pre><p>The input to the digesting operation is the value bytes of the <code>csig:Message</code> element which is UTF-8 encoded bytes
-of the actual sign message<sup>*</sup>.</p>
-<p>The <code>signMessageDigest</code> attribute for the above example will then be:</p>
-<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute FriendlyName=<span class="hljs-string">&quot;signMessageDigest&quot;</span> Name=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.14&quot;</span>
-  NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
-  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;xsd:string&quot;</span>&gt;</span>
-    <span class="hljs-attribute">http</span>://www.w<span class="hljs-number">3</span>.org/<span class="hljs-number">2001</span>/<span class="hljs-number">04</span>/xmlenc#sha<span class="hljs-number">256</span>;<span class="hljs-number">0</span>yKaSVsYeh+PX<span class="hljs-number">2</span>Q<span class="hljs-number">6</span>diqO<span class="hljs-number">2</span>w<span class="hljs-number">89</span>+a<span class="hljs-number">3</span>Dm<span class="hljs-number">303</span>tp<span class="hljs-number">3</span>AVjgxwj<span class="hljs-number">0</span>=
-  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
-<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p><a name="the-orgaffiliation-attribute"></a></p>
-<h4 id="325-the-orgaffiliation-attribute">3.2.5. The orgAffiliation Attribute</h4>
-<p>The <code>orgAffiliation</code> attribute is intended to be used as a primary identity attribute for personal organizational identities. It consists of a personal identifier <strong>and</strong> an organizational identifier code (<code>organizationIdentifier</code>). </p>
-<p>This specification does not impose any specific requirements concerning the personal identifier part of the attribute other than that it MUST be unique for the given organization.</p>
-<p><strong>Note</strong>: In the general case, an attribute consumer MUST NOT assume a particular format or meaning of the personal identifier part since different organizations may use different formats. An attribute consumer should also be aware that a personal identifier separated from its organizational identifier code can not be regarded as unique. </p>
-<p><strong>Note</strong>: The <code>orgAffiliation</code> is a <a href="#scoped-attributes">scoped attribute</a> meaning that producing and consuming such an attribute MUST follow the rules given in sections 2.1.3.1 and 6.2.1 of [<a href="#eiddeployprof">EidDeployProf</a>].</p>
-<p><a name="the-previouspersonalidentitynumber-attribute"></a></p>
-<h4 id="326-the-previouspersonalidentitynumber-attribute">3.2.6. The previousPersonalIdentityNumber Attribute</h4>
-<p>The <code>personalIdentityNumber</code> attribute can contain a Swedish personal identity number (personnummer), [<a href="#skv704">SKV704</a>], or a Swedish coordination number (samordningsnummer), [<a href="#skv707">SKV707</a>]. All individuals born in Sweden or moving to Sweden with the intention 
-of staying one year or longer is assigned a personal identity number and registered in the
-population register. A coordination number may be assigned to a person that is not registered, 
-but has the need to communicate with various government authorities, healthcare institutions,
-higher education and banks.</p>
-<p>In some cases a person may hold a coordination number during a period before he or she is
-assigned a personal identity number. A typical use case is a person that seeks asylum and
-later is given a residence permit. In this case the person first may hold a coordination number
-and if a residence permit is given a personal identity number will be assigned.</p>
-<p>For a service provider this may lead to problems since the primary identifier for a person
-has changed. A login with the newly assigned identifier will not match the user account
-previously used by this individual.</p>
-<p>This profile defines the <code>previousPersonalIdentityNumber</code> attribute to enable matching a
-previously held identity number to a newly assigned identity number. The <code>previousPersonalIdentityNumber</code> attribute is typically released together with the &quot;new&quot; 
-<code>personalIdentityNumber</code> attribute in order to facilitate account matching at a service provider.</p>
-<p>This attribute is not part of any attribute sets defined in the profile. Attribute consumers
-wishing to receive the attribute should declare the these requirement in their metadata entries
-(using a <code>&lt;md:RequestedAttribute&gt;</code> element).</p>
-<p><a name="attributes-for-the-eidas-framework"></a></p>
-<h3 id="33-attributes-for-the-eidas-framework">3.3. Attributes for the eIDAS Framework</h3>
-<p><a name="the-prid-and-pridpersistence-attributes"></a></p>
-<h4 id="331-the-prid-and-pridpersistence-attributes">3.3.1. The prid and pridPersistence Attributes</h4>
-<p>Assertions (with attribute statements) issued from a member state eIDAS
-node contain a set of attributes identifying the authenticated subject.
-Attributes obtained from other conformant eIDAS nodes will provide an
-eIDAS unique identifier but it can not be ruled out that the Swedish
-eIDAS node may be adopted to accept authentication from non eIDAS
-compliant nodes, such as when accepting authentication from countries
-outside of EU such as the USA.</p>
-<p>Therefore, the Swedish eIDAS connector enriches attribute statements
-with the provisional ID (<code>prid</code>) and provisional ID persistence
-(<code>pridPersistence</code>) attributes.</p>
-<p>The <code>prid</code> attribute is designed to provide one common unique attribute of
-the user in a common format regardless of the composition of the
-original attributes received from the authenticating source. The <code>prid</code>
-attribute value is not stored in any registry, but derived from the
-received attributes at each authentication instant according to defined
-algorithms specified in [<a href="#constructedattr">ConstructedAttr</a>]. The algorithm ensures that
-each <code>prid</code> is unique for each authenticated entity, but does not ensure
-persistence. If the attributes received for an entity changes over time,
-the <code>prid</code> attribute may also change dependent on the defined <code>prid</code>
-generation algorithm for that attribute source.</p>
-<p>The <code>pridPersistence</code> attribute provides an indication of the expected
-persistence over time for a present <code>prid</code> attribute value. The value of
-this attribute is determined from the selected <code>prid</code> generation algorithm
-in combination with the attribute source. For example, a <code>prid</code> derived
-from a Norwegian eIDAS unique identifier has longer persistence
-expectancy than a <code>prid</code> derived from the same attribute from the UK or
-Germany. This attribute helps Service Providers to apply different UI
-and service functions for users with different persistence expectancy.
-This may assist users with low persistence expectancy to regain control
-of their user account, should their <code>prid</code> change in the future.</p>
-<p>The specification “eIDAS Constructed Attributes Specification for the
-Swedish eID Framework”, [<a href="#constructedattr">ConstructedAttr</a>], declares the details for
-how the <code>prid</code> and <code>pridPersistence</code> attributes are generated and how they
-should be processed.</p>
-<p><a name="the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attribute"></a></p>
-<h4 id="332-the-mappedpersonalidentitynumber-and-personalidentitynumberbinding-attributes">3.3.2. The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes</h4>
-<p>When an authentication for a natural person is performed against the
-eIDAS Framework, the Swedish eIDAS connector will query the Identity Binding Service
-for a binding between the attributes found in the assertion received from the foreign
-eIDAS-node and a Swedish personal identity number.  If such a mapping exists, and the user consents to it being used, the assertion will be extended with a <code>mappedPersonalIdentityNumber</code> attribute holding the &quot;mapped&quot; Swedish civic registration number (&quot;personnummer&quot; or &quot;samordningsnummer&quot;).</p>
-<p>This mapping, or binding, can be performed using a number of different processes,
-each identified by a URI. Therefore, if the eIDAS connector extends an assertion with a 
-<code>mappedPersonalIdentityNumber</code> attribute, it MUST also include the <code>personalIdentityNumberBinding</code> attribute. This attribute contains a semicolon separated list of URI:s that identify the binding process applied to obtain the binding. See [<a href="#id-binding">ID-Binding</a>] for the possible values.</p>
-<p>If these bindings are acceptable for a Service Provider processing an assertion (containing the <code>mappedPersonalIdentityNumber</code> attribute), the Service Provider MAY treat the contents of the <code>mappedPersonalIdentityNumber</code> attribute as it would have received the <code>personalIdentityNumber</code> attribute, otherwise the Service Provider SHOULD NOT use the identity found in the <code>mappedPersonalIdentityNumber</code> attribute to login the user.</p>
-<blockquote>
-<p><strong>Note</strong>: The reason that an ordinary <code>personalIdentityNumber</code> attribute is not
-used to represent a mapped civic registration number is that it is essential that
-the consuming entity always verifies that the binding process under which the 
-mapping was performed is acceptable, before proceeding with the authentication 
-process.</p>
-</blockquote>
-<p><a name="conversion-of-eidas-attributes"></a></p>
-<h4 id="333-conversion-of-eidas-attributes">3.3.3. Conversion of eIDAS Attributes</h4>
-<p>The attributes specified within eIDAS ([<a href="#eidas-attr">eIDAS_Attr</a>]) does not use
-simple string type values. Instead each attribute is represented using
-its own dedicated XML data type. This affects interoperability in a
-negative way since most standard SAML software need to be modified to
-support these attributes. Therefore, the Swedish eID Framework defines
-mappings for all eIDAS attributes to attributes having definitions that
-are more suitable for processing using standard SAML software.</p>
-<p>Below follows a listing of how the attributes for the eIDAS minimum data
-set for Natural Persons are converted into attributes supported by the
-Swedish eID Framework.</p>
-<table>
-<thead>
-<tr>
-<th align="left">eIDAS attribute</th>
-<th align="left">Swedish eID attribute</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left">PersonIdentifier <br /> <code>http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier</code></td>
-<td align="left">eidasPersonIdentifier <br /> urn:oid:1.2.752.201.3.7</td>
-</tr>
-<tr>
-<td align="left">FamilyName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentFamilyName</code></td>
-<td align="left">sn <br /> urn:oid:2.5.4.4</td>
-</tr>
-<tr>
-<td align="left">FirstName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentGivenName</code></td>
-<td align="left">givenName <br /> urn:oid:2.5.4.42</td>
-</tr>
-<tr>
-<td align="left">DateOfBirth <br /> <code>http://eidas.europa.eu/attributes/naturalperson/DateOfBirth</code></td>
-<td align="left">dateOfBirth <br /> urn:oid:1.3.6.1.5.5.7.9.1</td>
-</tr>
-<tr>
-<td align="left">BirthName <br /> <code>http://eidas.europa.eu/attributes/naturalperson/BirthName</code></td>
-<td align="left">birthName <br /> urn:oid:1.2.752.201.3.8</td>
-</tr>
-<tr>
-<td align="left">PlaceOfBirth <br /> <code>http://eidas.europa.eu/attributes/naturalperson/PlaceOfBirth</code></td>
-<td align="left">placeOfBirth <br /> urn:oid:1.3.6.1.5.5.7.9.2</td>
-</tr>
-<tr>
-<td align="left">CurrentAddress <br /> <code>http://eidas.europa.eu/attributes/naturalperson/CurrentAddress</code></td>
-<td align="left">eidasNaturalPersonAddress <br /> urn:oid:1.2.752.201.3.9 <br /> See <a href="#conversion-of-eidas-currentaddress">section 3.3.3.1</a> below.</td>
-</tr>
-<tr>
-<td align="left">Gender <br /> <code>http://eidas.europa.eu/attributes/naturalperson/Gender</code></td>
-<td align="left">gender <br /> urn:oid:1.3.6.1.5.5.7.9.3</td>
-</tr>
-<tr>
-<td align="left">Nationality<br /><code>http://eidas.europa.eu/attributes/naturalperson/Nationality</code></td>
-<td align="left">countryOfCitizenship<br />urn:oid:1.3.6.1.5.5.7.9.4</td>
-</tr>
-<tr>
-<td align="left">CountryOfBirth<br /><code>http://eidas.europa.eu/attributes/naturalperson/CountryOfBirth</code></td>
-<td align="left">Will be added as the last element of placeOfBirth (see above)</td>
-</tr>
-<tr>
-<td align="left">TownOfBirth<br /><code>http://eidas.europa.eu/attributes/naturalperson/TownOfBirth</code></td>
-<td align="left">Ignored if the eIDAS attribute PlaceOfBirth is assigned. Otherwise placed as first element of placeOfBirth.</td>
-</tr>
-<tr>
-<td align="left">CountryOfResidence<br /><code>http://eidas.europa.eu/attributes/naturalperson/CountryOfResidence</code></td>
-<td align="left">countryOfResidence<br />urn:oid:1.3.6.1.5.5.7.9.5</td>
-</tr>
-<tr>
-<td align="left">PhoneNumber<br /><code>http://eidas.europa.eu/attributes/naturalperson/PhoneNumber</code></td>
-<td align="left">telephoneNumber<br />urn:oid:2.5.4.20</td>
-</tr>
-<tr>
-<td align="left">EmailAddress<br /><code>http://eidas.europa.eu/attributes/naturalperson/EmailAddress</code></td>
-<td align="left">mail<br />urn:oid:0.9.2342.19200300.100.1.3</td>
-</tr>
-</tbody></table>
-<p><strong>Note</strong>: When converting an eIDAS attribute that makes use of
-“transliteration” (as described in section 2.4 of [<a href="#eidas-attr">eIDAS_Attr</a>])
-attribute values having the <code>LatinScript</code> attribute set to <code>false</code> will not
-be part of the resulting attribute.</p>
-<p><a name="conversion-of-eidas-currentaddress"></a></p>
-<h5 id="3331-conversion-of-eidas-currentaddress">3.3.3.1. Conversion of eIDAS CurrentAddress</h5>
-<p>The eIDAS attribute <code>CurrentAddress</code> is defined in section 2.2.9 of
-[<a href="#eidas-attr">eIDAS_Attr</a>]. Its value is a Base64-encoding of an XML-structure of
-the type CurrentAddressStructuredType.</p>
-<pre class="hljs"><code>&lt;xsd:complexType <span class="hljs-type">name</span>=&quot;CurrentAddressStructuredType&quot;&gt;
-  &lt;xsd:annotation&gt;
-    &lt;xsd:documentation&gt;
-      <span class="hljs-keyword">Current</span> address <span class="hljs-keyword">of</span> the <span class="hljs-keyword">natural</span> person.
-    &lt;/xsd:documentation&gt;
-  &lt;/xsd:annotation&gt;
-  &lt;xsd:<span class="hljs-keyword">sequence</span>&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PoBox&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;LocatorDesignator&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;LocatorName&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;CvaddressArea&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;Thoroughfare&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PostName&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;AdminunitFirstline&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;AdminunitSecondline&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-    &lt;xsd:element <span class="hljs-type">name</span>=&quot;PostCode&quot; <span class="hljs-keyword">type</span>=&quot;xsd:string&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
-  &lt;/xsd:<span class="hljs-keyword">sequence</span>&gt;
-&lt;/xsd:complexType&gt;</code></pre><p>An example of an instance of a CurrentAddress attribute would look as
-follows:</p>
-<pre class="hljs"><code><span class="hljs-section">&lt;saml2:Attribute xmlns:xsi=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
-                           FriendlyName=<span class="hljs-string">&quot;CurrentAddress&quot;</span>
-                           Name=<span class="hljs-string">&quot;http://eidas.europa.eu/attributes/naturalperson/CurrentAddress&quot;</span>
-                           NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
-  <span class="hljs-section">&lt;saml2:AttributeValue xsi:type=<span class="hljs-string">&quot;eidas:CurrentAddressType&quot;</span>&gt;</span>
-    <span class="hljs-attribute">PGVpZGFzOkxvY2F0b3JEZXNpZ25hdG9yPjIyPC9laWRhczpMb2NhdG9yRGVzaWduYX</span>
-    <span class="hljs-attribute">Rvcj48ZWlkYXM6VGhvcm91Z2hmYXJlPkFyY2FjaWEgQXZlbnVlPC9laWRhczpUaG9y</span>
-    <span class="hljs-attribute">b3VnaGZhcmU</span>+DQo<span class="hljs-number">8</span>ZWlkYXM<span class="hljs-number">6</span>UG<span class="hljs-number">9</span>zdE<span class="hljs-number">5</span>hbWU+TG<span class="hljs-number">9</span>uZG<span class="hljs-number">9</span>uPC<span class="hljs-number">9</span>laWRhczpQb<span class="hljs-number">3</span>N<span class="hljs-number">0</span>TmFtZT
-    <span class="hljs-attribute">4NCjxlaWRhczpQb3N0Q29kZT5TVzFBIDFBQTwvZWlkYXM6UG9zdENvZGU</span>+
-  <span class="hljs-section">&lt;/saml2:AttributeValue&gt;</span>
-<span class="hljs-section">&lt;/saml2:Attribute&gt;</span></code></pre><p>The value is the Base64-encoding of the following XML-snippet:</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">eidas:LocatorDesignator</span>&gt;</span>22<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:LocatorDesignator</span>&gt;</span>
-<span class="hljs-tag">&lt;<span class="hljs-name">eidas:Thoroughfare</span>&gt;</span>Arcacia Avenue<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:Thoroughfare</span>&gt;</span>
-<span class="hljs-tag">&lt;<span class="hljs-name">eidas:PostName</span>&gt;</span>London<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:PostName</span>&gt;</span>
-<span class="hljs-tag">&lt;<span class="hljs-name">eidas:PostCode</span>&gt;</span>SW1A 1AA<span class="hljs-tag">&lt;/<span class="hljs-name">eidas:Postcode</span>&gt;</span></code></pre><p>This is not easily processed by standard SAML-software, and requires
-several steps including XML-decoding of an incomplete XML-snippet.
-Therefore, the Swedish eID Framework defines the
-<code>eidasNaturalPersonAddress</code> attribute to be used when the Swedish eIDAS
-node converts the eIDAS <code>CurrentAddress</code> attribute.</p>
-<p>The <code>eidasNaturalPersonAddress</code> attribute is defined to be a non-empty
-single-value attribute containing key-value pairs separated by
-semicolons. The keys are element names from the
-<code>CurrentAddressStructuredType</code> type and the value-parts are their
-corresponding values. The key and value of each pair is separated by a
-‘=’ character and both the key and value MUST be URL-encoded.</p>
-<p>The eIDAS-attribute <code>CurrentAddress</code> above will thus be converted to the
-following attribute:</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">saml2:Attribute</span> <span class="hljs-attr">xmlns:xsi</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema-instance&quot;</span>
-                           <span class="hljs-attr">FriendlyName</span>=<span class="hljs-string">&quot;eidasNaturalPersonAddress&quot;</span>
-                           <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;urn:oid:1.2.752.201.3.9&quot;</span>
-                           <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">saml2:AttributeValue</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
-    LocatorDesignator=22;Thoroughfare=Arcacia%20Avenue;PostName=London;PostCode=SW1A%201AA
-  <span class="hljs-tag">&lt;/<span class="hljs-name">saml2:AttributeValue</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">saml2:Attribute</span>&gt;</span></code></pre><p><a name="references"></a></p>
-<h2 id="4-references">4. References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="saml2core"></a>
-<strong>[SAML2Core]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
-Assertion Markup Language (SAML) V2.0, March
-2005</a>.</p>
-</blockquote>
-<p><a name="saml2subjattr"></a>
-<strong>[SAML2SubjAttr]</strong></p>
-<blockquote>
-<p><a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.pdf">OASIS Standard, SAML V2.0 Subject Identifier Attributes Profile Version 1.0, January 2019</a>.</p>
-</blockquote>
-<p><a name="skv704"></a>
-<strong>[SKV704]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv704-8.pdf">Skatteverket, SKV 704 Utgåva 8,
-Personnummer</a>.</p>
-</blockquote>
-<p><a name="skv707"></a>
-<strong>[SKV707]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf">Skatteverket, SKV 707, Utgåva 2,
-Samordningsnummer</a>.</p>
-</blockquote>
-<p><a name="skv709"></a>
-<strong>[SKV709]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf">Skatteverket, SKV 709, Utgåva 8, Organisationsnummer</a>.</p>
-</blockquote>
-<p><a name="id-binding"></a>
-<strong>[ID-Binding]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/Identity_Binding.html">Binding of eIDAS Attributes to Swedish Personal Identity Numbers</a></p>
-</blockquote>
-<p><a name="x520"></a>
-<strong>[X.520]</strong></p>
-<blockquote>
-<p><a href="https://www.itu.int/rec/T-REC-X.520-201610-I/en">ITU-T X.520 - Open Systems Interconnection – The Directory: Selected attribute types</a>.</p>
-</blockquote>
-<p><a name="saml-xsd"></a>
-<strong>[SAML-XSD]</strong></p>
-<blockquote>
-<p>S. Cantor et al., SAML assertions schema. OASIS SSTC, March 2005.
-Document ID saml-schema-assertion-2.0. See
-<a href="http://www.oasisopen.org/committees/security/">http://www.oasisopen.org/committees/security/</a>.</p>
-</blockquote>
-<p><a name="xml-schema"></a>
-<strong>[XML-Schema]</strong></p>
-<blockquote>
-<p>XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28
-October 2004. See <a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>.</p>
-</blockquote>
-<p><a name="iso3166"></a>
-<strong>[ISO3166]</strong></p>
-<blockquote>
-<p>Codes for the representation of names of countries and their
-subdivisions Part 1: Country codes, ISO standard, ISO 3166-1.</p>
-</blockquote>
-<p><a name="sambiattr"></a>
-<strong>[SambiAttr]</strong></p>
-<blockquote>
-<p><a href="https://wiki.federationer.internetstiftelsen.se/pages/viewpage.action?pageId=46465316">Sambi Attributspecifikation</a>.</p>
-</blockquote>
-<p><a name="tillitramv"></a>
-<strong>[TillitRamv]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digital-identitet/e-legitimering/tillitsnivaer/tillitsramverket">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="eiddeployprof"></a>
-<strong>[EidDeployProf]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="constructedattr"></a>
-<strong>[ConstructedAttr]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html">eIDAS Constructed Attributes Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidas-attr"></a>
-<strong>[eIDAS_Attr]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/eidas/eIDAS_SAML_Attribute_Profile_v1.2-FINAL.pdf">eIDAS SAML Attribute Profile, version 1.2, 21 May 2019</a>.</p>
-</blockquote>
-<p><a name="sigsap"></a>
-<strong>[SigSAP]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="dssext"></a>
-<strong>[DSSExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="5-changes-between-versions">5. Changes between versions</h2>
-<p><strong>Changes between version 1.7 and version 1.8:</strong></p>
-<ul class="list">
-<li><p>In section 3.1.3, &quot;Scoped Attributes&quot;, a note about <code>@</code>-characters in scoped values was added.</p>
-</li>
-<li><p>Updated link to Sambi attribute specification.</p>
-</li>
-<li><p>Section 3.3.2, &quot;The mappedPersonalIdentityNumber and personalIdentityNumberBinding Attributes&quot;, was updated.</p>
-</li>
-<li><p>Section 3.3.3, &quot;Conversion of eIDAS Attributes&quot;, was extended to contain mappings for the optional eIDAS attributes: Nationality, CountryOfBirth, TownOfBirth, CountryOfResidence, PhoneNumber and EmailAddress.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
-<ul class="list">
-<li><p>Section 2.4, &quot;Organizational Identity for Natural Persons&quot;, was updated to define a minimum set of attributes for providing personal orgazational identity information.</p>
-</li>
-<li><p>Section 3.2.5, &quot;The orgAffiliation Attribute&quot;, was introduced.</p>
-</li>
-<li><p>The concept of &quot;scoped attributes&quot; was introduced, see section 3.1.3.</p>
-</li>
-<li><p>The <code>previousPersonalIdentityNumber</code> attribute was added, see section 3.2.6.</p>
-</li>
-<li><p>The <code>mappedPersonalIdentityNumber</code> attribute was added (see section 3.3.2), and the
-attribute set &quot;eIDAS Natural Person Attribute Set&quot; (section 2.5) was changed so that
-a <code>mappedPersonalIdentityNumber</code> attribute is delivered instead of a 
-<code>personalIdentityNumber</code> attribute if the eIDAS identity can be mapped to a Swedish 
-identity number.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
-<ul class="list">
-<li><p>References were updated to point at the latest versions of the &quot;Tillitsramverk för Svensk e-legitimation&quot; and &quot;eIDAS SAML Attribute Profile&quot; specifications.</p>
-</li>
-<li><p>Section 2.5, &quot;eIDAS Natural Person Attribute Set&quot;, was updated so that the <code>c</code> (country) attribute is a required attribute for this attribute set.</p>
-</li>
-<li><p>The attribute <code>signMessageDigest</code> was introduced (see section 3.2.4).</p>
-</li>
-<li><p>The HSA-ID attribute was specified.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
-<ul class="list">
-<li>Section 3.2.3 was updated with a reference to the SAP specification as source for defining the content of the <code>sad</code> attribute.</li>
-<li>Fix of invalid links for SKV704 and SKV707.</li>
-<li>Section 2.3, &quot;Natural Personal Identity with Civic Registration Number (Personnummer)&quot;, was updated so that the <code>dateOfBirth</code>-attribute is listed as a recommended attribute for the attribute set <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>.</li>
-</ul>
-<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
-<ul class="list">
-<li><p>Attributes for mapping eIDAS-attributes have been defined (section
-  3.1 and 3.3).</p>
-</li>
-<li><p>The eIDAS Natural Person Attribute Set has been defined (section
-  2.5).</p>
-</li>
-<li><p>The definition of the <code>gender</code>-attribute was extended to also include
-  “U” (for unspecified or unknown).</p>
-</li>
-<li><p>For interoperability and implementations reasons, the definition of
-  the <code>dateOfBirth</code>-attribute has been changed so that it is represented
-  as an <code>xs:string</code> type on the format YYYY-MM-DD, instead of the
-  <code>xs:date</code> type.</p>
-</li>
-<li><p>  Attributes <code>userCertificate</code>, <code>userSignature</code>, <code>authServerSignature</code> and <code>sad</code> were added.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
-<ul class="list">
-<li><p>This specification no longer uses the term “attribute profile” for
-  named collections of attributes for different scenarios. Instead the
-  term “attribute set” is used.</p>
-</li>
-<li><p>Definitions of attribute sets (profiles) have been changed to be
-  more flexible and to focus only on which attributes that should be
-  included in an attribute release. Attribute set requirements now
-  include “required” and “recommended” attributes instead of
-  “required”, “allowed”, “if requested” and “prohibited”. See
-  section 2.</p>
-</li>
-<li><p>The contents of the previous chapter 2, “NameID”, were moved to the
-  “Deployment Profile for the Swedish eID Framework” document.</p>
-</li>
-<li><p>The attribute <code>displayName</code> is now specified as “required” for the
-  “Natural Personal Identity with Civic Registration Number
-  (Personnummer)” (ELN-AP-NaturalPerson-01) attribute set (profile).
-  See section 2.3.</p>
-</li>
-<li><p>The attributes <code>o</code> (Organization) and <code>displayName</code> are now specified as
-  “required” for the “Organizational Identity for Natural Persons”
-  (ELN-AP-OrgPerson-01) attribute set (profile). See section 2.4.</p>
-</li>
-<li><p>The attributes <code>givenName</code> and <code>sn</code> (surname) are now specified as
-  “required” for the “Natural Personal Identity without Civic
-  Registration Number” (ELN-AP-NaturalPerson-01) attribute set
-  (profile). See section 2.2.</p>
-</li>
-<li><p>The attributes <code>transactionIdentifier</code> and <code>authContextParams</code> were
-  introduced (see sections 3.1 and 3.2.1).</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
-<ul class="list">
-<li>Attribute Profiles are now also represented with valid URIs as well
-  as their textual identifiers.</li>
-</ul>
-<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
-<ul class="list">
-<li>In chapter 3.4, “Organizational Identity for Natural Persons”, some
-  attributes were listed as both prohibited and allowed. This has been
-  fixed.</li>
-</ul>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html b/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
new file mode 120000
index 0000000..2841068
--- /dev/null
+++ b/docs/updates/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
@@ -0,0 +1 @@
+../december-2024/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html b/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
deleted file mode 100644
index 48ba5df..0000000
--- a/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
+++ /dev/null
@@ -1,689 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Entity Categories for the Swedish eID Framework</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="entity-categories-for-the-swedish-eid-framework">Entity Categories for the Swedish eID Framework</h1>
-<h3 id="version-19---2024-11-25---draft-version">Version 1.9 - 2024-11-25 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2019-311</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (Digg)</a>, 2015-2024. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#references-to-saml-20-standards-and-profiles">References to SAML 2.0 Standards and Profiles</a></p>
-<p> 1.3. <a href="#consuming-and-providing-services">Consuming and Providing Services</a></p>
-<p> 1.4. <a href="#use-in-discovery">Use in Discovery</a></p>
-<p> 1.5. <a href="#representation-of-entity-categories-in-metadata">Representation of Entity Categories in Metadata</a></p>
-</li>
-<li><p><a href="#definitions-for-service-entity-categories"><strong>Definitions for Service Entity Categories</strong></a></p>
-<p> 2.1. <a href="#natural-personal-identity-with-civic-registration-number">Natural Personal Identity with Civic Registration Number</a></p>
-<p> 2.1.1. <a href="#loa2-pnr">loa2-pnr</a></p>
-<p> 2.1.2. <a href="#loa3-pnr">loa3-pnr</a></p>
-<p> 2.1.3. <a href="#loa4-pnr">loa4-pnr</a></p>
-<p> 2.1.4. <a href="#eidas-pnr-delivery">eidas-pnr-delivery</a></p>
-<p> 2.2. <a href="#eidas-natural-person-attribute-set">eIDAS Natural Person Attribute Set</a></p>
-<p> 2.2.1. <a href="#eidas-naturalperson">eidas-naturalperson</a></p>
-<p> 2.3. <a href="#organizational-identity-for-natural-persons">Organizational Identity for Natural Persons</a></p>
-<p> 2.3.1. <a href="#loa2-orgid">loa2-orgid</a></p>
-<p> 2.3.2. <a href="#loa3-orgid">loa3-orgid</a></p>
-<p> 2.3.3. <a href="#loa4-orgid">loa4-orgid</a></p>
-<p> 2.4. <a href="#natural-personal-identity-without-civic-registration-number">Natural Personal Identity without Civic Registration Number</a></p>
-<p> 2.4.1. <a href="#loa2-name">loa2-name</a></p>
-<p> 2.4.2. <a href="#loa3-name">loa3-name</a></p>
-<p> 2.4.3. <a href="#loa4-name">loa4-name</a></p>
-</li>
-<li><p><a href="#definitions-for-service-property-categories"><strong>Definitions for Service Property Categories</strong></a></p>
-<p> 3.1. <a href="#mobile-auth">mobile-auth</a></p>
-<p> 3.2. <a href="#scal2">scal2</a></p>
-</li>
-<li><p><a href="#definitions-for-service-type-entity-categories"><strong>Definitions for Service Type Entity Categories</strong></a></p>
-<p> 4.1. <a href="#sigservice">sigservice</a></p>
-<p> 4.2. <a href="#public-sector-sp">public-sector-sp</a></p>
-<p> 4.3. <a href="#private-sector-sp">private-sector-sp</a></p>
-</li>
-<li><p><a href="#service-contract-categories"><strong>Service Contract Categories</strong></a></p>
-</li>
-<li><p><a href="#general-entity-categories"><strong>General Entity Categories</strong></a></p>
-<p> 6.1. <a href="#secure-authenticator-binding">secure-authenticator-binding</a></p>
-<p> 6.2. <a href="#accepts-coordination-number">accepts-coordination-number</a></p>
-<p> 6.3. <a href="#supports-user-message">supports-user-message</a></p>
-</li>
-<li><p><a href="#references"><strong>References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1-introduction">1. Introduction</h2>
-<p>This specification contains the Entity Category definitions that are
-defined for the Swedish eID Framework and that should be supported by
-Service Providers and Identity Providers that are part of the
-federation.</p>
-<p>The use of Entity Categories for the Swedish eID Framework is restricted
-to SAML metadata where Entity Categories are placed as SAML attributes
-under the <code>&lt;mdattr:EntityAttributes&gt;</code> element
-([<a href="#saml2metaattr">SAML2MetaAttr</a>]) for an <code>&lt;md:Extensions&gt;</code> element
-([<a href="#saml2meta">SAML2Meta</a>]).</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">md:EntityDescriptor</span> <span class="hljs-attr">entityID</span>=<span class="hljs-string">&quot;https://eid.example.com/entityid&quot;</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">md:Extensions</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">mdattr:EntityAttributes</span> <span class="hljs-attr">xmlns:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;</span>
-    ... 
-      <span class="hljs-tag">&lt;<span class="hljs-name">saml:Attribute</span> <span class="hljs-attr">Name</span>=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
-                      <span class="hljs-attr">NameFormat</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;</span>
-        <span class="hljs-tag">&lt;<span class="hljs-name">saml:AttributeValue</span> <span class="hljs-attr">xmlns:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> <span class="hljs-attr">xsi:type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;</span>
-          http://id.elegnamnden.se/ec/1.0/loa3-pnr
-        <span class="hljs-tag">&lt;/<span class="hljs-name">saml:AttributeValue</span>&gt;</span>    
-      <span class="hljs-tag">&lt;/<span class="hljs-name">saml:Attribute</span>&gt;</span>    
-    <span class="hljs-tag">&lt;/<span class="hljs-name">mdattr:EntityAttributes</span>&gt;</span>    
-  <span class="hljs-tag">&lt;/<span class="hljs-name">md:Extensions</span>&gt;</span>    
-  ...</code></pre><p><em>The Entity Category identifier
-<strong><code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></strong> specified as an entity
-attribute for a Service Provider or Identity Provider.</em></p>
-<p>Five types of Entity Categories are used within the federation:</p>
-<ul class="list">
-<li><p>Service entity category – Identifiers for entity categories
-  representing sets of requirements.</p>
-</li>
-<li><p>Service property categories – Identifiers for defined service
-  properties.</p>
-</li>
-<li><p>  Service type categories – Identifiers for defined service types.</p>
-</li>
-<li><p>  Service contract categories - Identifiers for labelling entities based on contracts or business agreements.</p>
-</li>
-<li><p>   General categories - Identifiers defined within the Swedish eID Framework for miscellaneous purposes.</p>
-</li>
-</ul>
-<p><a name="requirements-notation"></a></p>
-<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
-&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
-document are to be interpreted as described in [<a href="#rfc2119">RFC2119</a>].</p>
-<p>The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus
-on deployment practices intended to foster both interoperability and
-guarantees of security and confidentiality needed to satisfy the
-requirements of many organizations that engage in the use of federated
-identity. Deviating may limit a deployment&#39;s ability to technically
-interoperate without additional negotiation, and should be undertaken
-with caution.</p>
-<p><a name="references-to-saml-20-standards-and-profiles"></a></p>
-<h3 id="12-references-to-saml-20-standards-and-profiles">1.2. References to SAML 2.0 Standards and Profiles</h3>
-<p>When referring to elements from the SAML 2.0 core specification
-[<a href="#saml2core">SAML2Core</a>], the following syntax is used:</p>
-<ul class="list">
-<li><p><code>&lt;saml2p:Element&gt;</code> – for elements from the SAML 2.0 Protocol
-  namespace.</p>
-</li>
-<li><p><code>&lt;saml2:Element&gt;</code> – for elements from the SAML 2.0 Assertion
-  namespace.</p>
-</li>
-</ul>
-<p>When referring to elements from the SAML 2.0 metadata specifications,
-the following syntax is used:</p>
-<ul class="list">
-<li><p>  <code>&lt;md:Element&gt;</code> – for elements defined in [<a href="#saml2meta">SAML2Meta</a>].</p>
-</li>
-<li><p>  <code>&lt;mdattr:Element&gt;</code> – for elements defined in [<a href="#saml2metaattr">SAML2MetaAttr</a>].</p>
-</li>
-</ul>
-<p><a name="consuming-and-providing-services"></a></p>
-<h3 id="13-consuming-and-providing-services">1.3. Consuming and Providing Services</h3>
-<p>Entity categories are mainly used for service matching. This allows
-matching of a consuming service with an appropriate providing service. A
-consuming service in this context is an assertion or attribute consuming
-service of a service provider (Service described through an
-<code>&lt;md:SPSSODescriptor&gt;</code> element in the federation metadata). A
-providing service in this context is a service, represented in the
-federation metadata, providing assertions to a service provider.</p>
-<p>The entity categories defined in this document have different meaning
-depending on whether they are declared by a consuming or a providing
-service. Further, different types of entity category identifiers defined
-in this document have different matching rules to determine whether
-particular providing service matches the requirements of a consuming
-service.</p>
-<p>These differences are outlined in the following table:</p>
-<table>
-<thead>
-<tr>
-<th align="left">EC type</th>
-<th align="left">Consuming service</th>
-<th align="left">Providing service</th>
-<th align="left">Service matching rule</th>
-</tr>
-</thead>
-<tbody><tr>
-<td align="left"><strong>Service Entity Category</strong></td>
-<td align="left">Each declared category represents a set of requirements for the service.</td>
-<td align="left">Represents the ability to deliver assertions in accordance with each declared category.</td>
-<td align="left">At least one of the service entity categories declared by the consuming service MUST be declared by the providing service.</td>
-</tr>
-<tr>
-<td align="left"><strong>Service Property</strong></td>
-<td align="left">Represents a property of this service.</td>
-<td align="left">Represents the ability to deliver assertions to a consuming service that has the declared property.</td>
-<td align="left">All properties declared by the consuming service MUST be declared by the providing service.</td>
-</tr>
-<tr>
-<td align="left"><strong>Service Type</strong></td>
-<td align="left">Declares the type of service provided by this consuming service.</td>
-<td align="left">Not applicable.</td>
-<td align="left">No matching rule.</td>
-</tr>
-<tr>
-<td align="left"><strong>Service Contract</strong></td>
-<td align="left">Each declared category represents a contract, or business agreement, that the service is affiliated to.</td>
-<td align="left">Represents the contracts, or business agreements, under which the providing service may deliver services.</td>
-<td align="left">At least one of the service contract identifiers declared by a providing service must be declared by the consuming service. A providing service that does not declare any service contract identifiers match all consuming services regarding service contract matching.</td>
-</tr>
-<tr>
-<td align="left"><strong>General</strong></td>
-<td align="left">An entity category type for miscellaneous purposes.</td>
-<td align="left">An entity category type for miscellaneous purposes.</td>
-<td align="left">No general matching rule.<br />However, the meaning of a general entity category may be such that it affects matching.</td>
-</tr>
-</tbody></table>
-<p><a name="use-in-discovery"></a></p>
-<h3 id="14-use-in-discovery">1.4. Use in Discovery</h3>
-<p>Entity Categories in metadata are declarations of requirements and
-capabilities of Service Providers and Identity Providers. A discovery
-process may make use of these declared Entity Categories when performing
-filtering, i.e., when deciding which Identity Providers to present for
-the end-user. The filtering algorithm is very simple:</p>
-<p>For a Service Provider requesting discovery its metadata entry is
-scanned for Entity Category identifiers of the type Service Entity
-Category, Service Contract and Service Property. The algorithm then iterates over all
-Identity Providers found in the metadata repository for the
-federation. The discovery process SHOULD display Identity Providers as
-a plausible choice, if and only if, the following conditions apply;</p>
-<ul class="list">
-<li><p>the Identity Provider declares at least of the Service Entity Category 
-  identifiers declared by the Service Provider,</p>
-</li>
-<li><p>if the Identity Provider declares at least one Service Contract identifier,
-  the Service Provider must declare at least one of declared identifiers, and,</p>
-</li>
-<li><p>all of the Service Property identifiers declared by the Service
-  Provider must be declared by the Identity Provider.</p>
-</li>
-</ul>
-<p><a name="representation-of-entity-categories-in-metadata"></a></p>
-<h3 id="15-representation-of-entity-categories-in-metadata">1.5. Representation of Entity Categories in Metadata</h3>
-<p>Entity categories defined in this document are placed in an entity’s
-metadata record as an attribute value within an entity category
-attribute (SAML attribute with name <code>http://macedir.org/entity-category</code>).
-If more than one entity category identifier is included in the metadata
-of a service, it MUST be placed as multiple attribute values within a
-single entity category attribute.</p>
-<pre class="hljs"><code>&lt;md:EntityDescriptor entityID=<span class="hljs-string">&quot;https://eid2.example.com/entityid&quot;</span>&gt;    
-  &lt;md:Extensions&gt;    
-    &lt;mdattr:EntityAttributes xmln<span class="hljs-variable">s:mdattr</span>=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:metadata:attribute&quot;</span>&gt;    
-    ...    
-      &lt;sam<span class="hljs-variable">l:Attribute</span> Name=<span class="hljs-string">&quot;http://macedir.org/entity-category&quot;</span>
-                      NameFormat=<span class="hljs-string">&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:uri&quot;</span>&gt;    
-        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
-          http://id.elegnamnden.<span class="hljs-keyword">se</span>/<span class="hljs-keyword">ec</span>/<span class="hljs-number">1.0</span>/loa3-pnr
-        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;
-        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
-          http://id.swedenconnect.<span class="hljs-keyword">se</span>/contract/sc/<span class="hljs-number">1.0</span>/eidas
-        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;    
-        &lt;sam<span class="hljs-variable">l:AttributeValue</span> xsi:<span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span>&gt;
-          http://id.elegnamnden.<span class="hljs-keyword">se</span>/sprop/<span class="hljs-number">1.0</span>/mobile-auth
-        &lt;/sam<span class="hljs-variable">l:AttributeValue</span>&gt;    
-      &lt;/sam<span class="hljs-variable">l:Attribute</span>&gt;    
-    &lt;/mdattr:EntityAttributes&gt;    
-  &lt;/md:Extensions&gt;    
-  ...</code></pre><p><em>Example of how entity categories are represented in metadata.</em></p>
-<p><a name="definitions-for-service-entity-categories"></a></p>
-<h2 id="2-definitions-for-service-entity-categories">2. Definitions for Service Entity Categories</h2>
-<p>This section contains a listing of Service Entity Categories that are defined within 
-the Swedish eID Framework. This listing may not be complete, and the federation operator
-may define additional categories.</p>
-<p>All service entity category identifiers are prefixed with
-<code>http://id.elegnamnden.se/ec</code> or <code>http://id.swedenconnect.se/ec</code> (defined after Aug. 2018).</p>
-<p>A service entity category identifies an arbitrary set of requirements and conditions that is required by the consuming service and provided by the providing service. Each service entity category specifies its own set of requirements and conditions. Typically such requirements and conditions include requirements on level of assurance (LoA) and requirements on mandatory attributes. For contract- or business agreement requirements <a href="#service-contract-categories">Service Contract Categories</a> should be used.</p>
-<p>A providing service declaring a service entity category that consists of both a level of assurance requirement and an attribute set MUST guarantee that the release of the given attributes are consistent with the level of assurance requirement.</p>
-<p>This specification does not impose any other limitations on what requirements or conditions that can be identified by a service entity category and there are no defined technical mechanisms to ensure that any service correctly implement any of these requirements. The main purpose of the service entity category is service matching in accordance with <a href="#consuming-and-providing-services">section 1.3</a> and any requirements and conditions that serves this purpose are considered valid.</p>
-<p><strong>Note</strong>: A providing service that does not comply with any of the defined service entity categories may define its own service entity category identifier in order to utilize the entity category matching rules. Any service entity category identifier defined outside of this specification should use the prefix <code>http://id.swedenconnect.se/ec/&lt;org&gt;</code>, where <code>org</code> is the defining organization&#39;s identifier.</p>
-<p><a name="natural-personal-identity-with-civic-registration-number"></a></p>
-<h3 id="21-natural-personal-identity-with-civic-registration-number">2.1. Natural Personal Identity with Civic Registration Number</h3>
-<p>This section define Service Entity Categories that has attribute requirements 
-according to the &quot;Natural Personal Identity with Civic Registration Number&quot; 
-(<code>http://id.elegnamnden.se/ap/1.0/pnr-01</code>) attribute set as defined in section 2.3 
-of [<a href="#eidattributes">EidAttributes</a>].</p>
-<p><strong>Note</strong>: The <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code> attribute set includes the <code>personalIdentityNumber</code> attribute. See section <a href="#accepts-coordination-number">6.2</a>, &quot;<a href="#accepts-coordination-number">accepts-coordination-number</a>&quot;, for specific requirements concerning delivering a coordination number in this attribute. </p>
-<p><a name="loa2-pnr"></a></p>
-<h4 id="211-loa2-pnr">2.1.1. loa2-pnr</h4>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa2-pnr</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
-<blockquote>
-<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
-<p><a name="loa3-pnr"></a></p>
-<h4 id="212-loa3-pnr">2.1.2. loa3-pnr</h4>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa3-pnr</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
-<blockquote>
-<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
-<p><a name="loa4-pnr"></a></p>
-<h4 id="213-loa4-pnr">2.1.3. loa4-pnr</h4>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/loa4-pnr</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity with Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code></p>
-<p><a name="eidas-pnr-delivery"></a></p>
-<h4 id="214-eidas-pnr-delivery">2.1.4. eidas-pnr-delivery</h4>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/eidas-pnr-delivery</code></p>
-<p><strong>Description</strong>: For asserting a Swedish identity to a foreign service provider via the Swedish eIDAS Proxy Service. This entity category MUST NOT be set by any entities other than Identity Providers providing identity assertions to the Swedish eIDAS Proxy Service and by the Swedish eIDAS Proxy Service itself.</p>
-<p>Attribute release is based on the &quot;Natural Personal Identity with Civic Registration Number&quot; attribute set with the addition of a mandatory <code>dateOfBirth</code>-attribute (<code>urn:oid:1.3.6.1.5.5.7.9.1</code>). The reason for the mandatory <code>dateOfBirth</code>-attribute is that this information is required by the eIDAS minimum dataset and therefore must be obtained by the receiving eIDAS Proxy Service. Date of birth can not always reliably be derived from the <code>personalIdentityNumber</code> attribute.</p>
-<p>It is the responsibility of the Swedish eIDAS Proxy Service to transform these attributes into eIDAS attributes.</p>
-<p><strong>LoA-identifier</strong>: Not applicable</p>
-<blockquote>
-<p>An Identity Provider delivering assertions to the eIDAS framework is obliged to announce which levels that it supports by including the corresponding eIDAS authentication context URIs defined in section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>] as assurance certification attributes in its metadata as described in section 2.1.3 of [<a href="#eiddeploy">EidDeploy</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/pnr-01</code> where the <code>dateOfBirth</code> attribute (<code>urn:oid:1.3.6.1.5.5.7.9.1</code>) is mandatory.</p>
-<p><a name="eidas-natural-person-attribute-set"></a></p>
-<h3 id="22-eidas-natural-person-attribute-set">2.2. eIDAS Natural Person Attribute Set</h3>
-<p><a name="eidas-naturalperson"></a></p>
-<h4 id="221-eidas-naturalperson">2.2.1. eidas-naturalperson</h4>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/ec/1.0/eidas-naturalperson</code></p>
-<p><strong>Description</strong>: User authentication according to any of the eIDAS assurance levels and attribute release according to “eIDAS Natural Person Attribute Set” (see section 2.5 of [<a href="#eidattributes">EidAttributes</a>]).</p>
-<p><strong>LoA-identifier</strong>:   Not applicable</p>
-<blockquote>
-<p>It does not make sense to specify the level of assurance for a Service
-Entity Categories intended for eIDAS since this information is not known
-to the Swedish eIDAS-node.</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code></p>
-<p><strong>Note</strong>: Attribute release according to the <code>http://id.elegnamnden.se/ap/1.0/eidas-natural-person-01</code> attribute set may include the <code>mappedPersonalIdentityNumber</code> attribute. See section <a href="#accepts-coordination-number">6.2</a>, &quot;<a href="#accepts-coordination-number">accepts-coordination-number</a>&quot;, for specific requirements concerning delivering a coordination number in this attribute.</p>
-<p><a name="organizational-identity-for-natural-persons"></a></p>
-<h3 id="23-organizational-identity-for-natural-persons">2.3. Organizational Identity for Natural Persons</h3>
-<p>This section define Service Entity Categories that has attribute requirements 
-according to the &quot;Organizational Identity for Natural Persons&quot; 
-(<code>http://id.elegnamnden.se/ap/1.0/org-person-01</code>) attribute set as defined in section 2.4 
-of [<a href="#eidattributes">EidAttributes</a>].</p>
-<p><a name="loa2-orgid"></a></p>
-<h4 id="231-loa2-orgid">2.3.1. loa2-orgid</h4>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa2-orgid</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
-<blockquote>
-<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
-<p><a name="loa3-orgid"></a></p>
-<h4 id="232-loa3-orgid">2.3.2. loa3-orgid</h4>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa3-orgid</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
-<blockquote>
-<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
-<p><a name="loa4-orgid"></a></p>
-<h4 id="233-loa4-orgid">2.3.3. loa4-orgid</h4>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa4-orgid</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Organizational Identity for Natural Persons”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
-<blockquote>
-<p>Or a corresponding LoA 4 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/org-person-01</code></p>
-<p><a name="natural-personal-identity-without-civic-registration-number"></a></p>
-<h3 id="24-natural-personal-identity-without-civic-registration-number">2.4. Natural Personal Identity without Civic Registration Number</h3>
-<p>This section define Service Entity Categories that has attribute requirements 
-according to the &quot;Natural Personal Identity without Civic Registration Number&quot; 
-(<code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code>) attribute set as defined in section 2.2 
-of [<a href="#eidattributes">EidAttributes</a>].</p>
-<p><a name="loa2-name"></a></p>
-<h3 id="241-loa2-name">2.4.1. loa2-name</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa2-name</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 2 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa2</code></p>
-<blockquote>
-<p>Or a corresponding LoA 2 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
-<p><a name="loa3-name"></a></p>
-<h3 id="242-loa3-name">2.4.2. loa3-name</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa3-name</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 3 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa3</code></p>
-<blockquote>
-<p>Or a corresponding LoA 3 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
-<p><a name="loa4-name"></a></p>
-<h3 id="243-loa4-name">2.4.3. loa4-name</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/ec/1.0/loa4-name</code></p>
-<p><strong>Description</strong>: User authentication according to assurance level 4 [<a href="#eidtillit">EidTillit</a>] and attribute release according to the attribute set “Natural Personal Identity without Civic Registration Number”.</p>
-<p><strong>LoA-identifier</strong>: <code>http://id.elegnamnden.se/loa/1.0/loa4</code></p>
-<blockquote>
-<p>Or a corresponding LoA 4 URI (see section 3.1.1 of [<a href="#eidregistry">EidRegistry</a>].</p>
-</blockquote>
-<p><strong>Attribute requirements</strong>: <code>http://id.elegnamnden.se/ap/1.0/natural-person-01</code></p>
-<p><a name="definitions-for-service-property-categories"></a></p>
-<h2 id="3-definitions-for-service-property-categories">3. Definitions for Service Property Categories</h2>
-<p>A Service Property Entity Category identifier is specified as an
-attribute value in the entity category attribute in the federation
-metadata and has the purpose of representing a particular service
-property.</p>
-<p>All Service Type identifiers are prefixed with
-<strong><code>http://id.elegnamnden.se/sprop</code></strong>.</p>
-<p><a name="mobile-auth"></a></p>
-<h3 id="31-mobile-auth">3.1. mobile-auth</h3>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/sprop/1.0/mobile-auth</code></p>
-<p><strong>Description</strong>: A service property declaring that the service is adapted to mobile clients and MUST allow users to authenticate using a mobile device that is used to access such service.</p>
-<p>For a providing service, i.e. an Identity Provider, inclusion of the
-mobile-auth category states that the Identity Provider supports
-authentication using mobile devices, <strong>and</strong> that the end-user interface
-of the Identity Provider is adapted for mobile clients.</p>
-<p>Note that an Identity Provider may of course support authentication for
-both desktop and mobile users. In these cases the service must be able
-to display end user interfaces for both types of clients.</p>
-<p>A discovery process will use this Service Property when performing
-filtering of possible Identity Providers, as described in <a href="#use-in-discovery-services">1.4</a>, “<a href="#use-in-discovery-services">Use in
-Discovery</a>”. This means that a consuming service may include the
-mobile-auth category in its metadata in order to have the discovery
-process especially displaying Identity Providers that offer
-authentication using mobile devices.</p>
-<p><a name="scal2"></a></p>
-<h3 id="32-scal2">3.2. scal2</h3>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/sprop/1.0/scal2</code></p>
-<p><strong>Description</strong>: A service property declaring that the service is adapted to support Sole Control Assurance Level 2 (SCAL2) in accordance with [<a href="#sigsap">SigSAP</a>]. </p>
-<p>For a providing service, i.e. an Identity Provider, inclusion of the
-scal2 service property states that the Identity Provider will return a &quot;SAD&quot; in response to a <code>SADRequest</code> in an authentication requests from a signing service.</p>
-<p>For consuming services, Signature Services MAY include this service property if all authentication requests from the 
-particular Signature Service include a <code>SADRequest</code> extension. A Service Provider that is not declared as a Signature Service MUST NOT include this service property in its metadata.</p>
-<p><a name="definitions-for-service-type-entity-categories"></a></p>
-<h2 id="4-definitions-for-service-type-entity-categories">4. Definitions for Service Type Entity Categories</h2>
-<p>A Service Type Entity Category identifier is specified as an entity
-attribute in the federation metadata and has the purpose of representing
-a particular service type.</p>
-<p>All Service Type identifiers are prefixed with
-<strong><code>http://id.elegnamnden.se/st</code></strong>.</p>
-<p><a name="sigservice"></a></p>
-<h3 id="41-sigservice">4.1. sigservice</h3>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/sigservice</code></p>
-<p><strong>Description</strong>:  A service type for a Service Provider that provides electronic signature services within the Swedish eID framework.</p>
-<p><a name="public-sector-sp"></a></p>
-<h3 id="42-public-sector-sp">4.2. public-sector-sp</h3>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/public-sector-sp</code></p>
-<p><strong>Description</strong>: A service type that indicates that a Service Provider is a &quot;public sector&quot; SP. This category MUST be used by public sector Service Providers wishing to use eIDAS authentication so that the Swedish eIDAS connector may include this information in the eIDAS authentication request. For other types of Service Providers its use is determined by the federation policy.</p>
-<p><a name="private-sector-sp"></a></p>
-<h3 id="43-private-sector-sp">4.3. private-sector-sp</h3>
-<p><strong>URL</strong>: <code>http://id.elegnamnden.se/st/1.0/private-sector-sp</code></p>
-<p><strong>Description</strong>: A service type that indicates that a Service Provider is a &quot;private sector&quot; SP. This category MUST be used by private sector Service Providers wishing to use eIDAS authentication so that the Swedish eIDAS connector may include this information in the eIDAS authentication request. For other types of Service Providers its use is determined by the federation policy.</p>
-<p><a name="service-contract-categories"></a></p>
-<h2 id="5-service-contract-categories">5. Service Contract Categories</h2>
-<p>Service Contract Entity Category identifiers are indented for performing service matching based on contracts, or business agreements, between providing and consuming services.</p>
-<p>All Service Contract identifiers are prefixed with <code>http://id.swedenconnect.se/contract/&lt;org&gt;</code>, where <code>org</code> is identifier for the defining organization.</p>
-<p>The meaning of different contracts and business agreements are out of scope for this specification. Instead the federation operator, or other parties, may define identifiers suitable for representing how consuming and providing services should be matched based on their respective agreements.</p>
-<p><a name="general-entity-categories"></a></p>
-<h2 id="6-general-entity-categories">6. General Entity Categories</h2>
-<p>An entity category of the General Entity Category type is a category that does not fit into any of the other category types regarding definitions and matching rules.</p>
-<p>General category identifiers are prefixed with <code>http://id.swedenconnect.se/general-ec</code>.</p>
-<p><a name="secure-authenticator-binding"></a></p>
-<h3 id="61-secure-authenticator-binding">6.1. secure-authenticator-binding</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code></p>
-<p><strong>Description</strong>: Some authentication schemes use an authentication device (<em>authenticator</em>) that 
-is external, i.e., not bound to the user agent. These types of authentication schemes may be
-vulnerable to certain types of phishing attacks where a fraudster who controls the user agent can
-trick, or persuade, the user to initiate an operation on the authentication device. </p>
-<p>A typical example of the threat described above is where an Identity Provider implements an
-authentication scheme that uses a mobile app as the authenticator. In those cases the user
-normally enters some input (often the user identity) in the web browser (user agent) that is
-then used by the Identity Provider to initiate an authentication session against the app running
-on the user&#39;s mobile device. The problem here is that there is no way we can now that the
-person initiating the operation in the web browser by entering a user identity is the same 
-person who opens, and performs the authentication in the app. </p>
-<p>In order to prevent attacks of this type many authentication schemes offer alternative ways
-of initiating authentication (or signature) sessions, where some sort of binding between the
-user agent and the authentication device is performed. An good example of this is when 
-Identity Providers prompt the user to scan a QR-code displayed in the web browser using the 
-authentication app instead of prompting for the user identity. This effectively binds the
-user agent to the same physical location as the authentication device, and in practice
-makes the attacks described above impossible.</p>
-<p>This profile defines the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> 
-entity category to be declared by Service Providers that require that a secure authenticator
-binding is performed by the Identity Providers supporting this.</p>
-<p>An Identity Provider that supports different methods of initiating authentication, or signature,
-operations, and where at least one of these methods is a &quot;secure authenticator binding&quot; SHOULD
-declare the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity
-category in its metadata.</p>
-<p>An Identity Provider that has declared the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> category in its metadata MUST perform a secure authenticator binding for requests sent
-from Service Providers that have declared this entity category in their metadata entries.</p>
-<p><a name="accepts-coordination-number"></a></p>
-<h3 id="62-accepts-coordination-number">6.2. accepts-coordination-number</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code></p>
-<p><strong>Description</strong>: A special purpose entity category that is declared by Service Providers
-to announce that they accept a Swedish coordination number (samordningsnummer), [<a href="#skv707">SKV707</a>], being delivered in the <code>personalIdentityNumber</code> (<code>urn:oid:1.2.752.29.4.13</code>) attribute.</p>
-<p>The <code>personalIdentityNumber</code> is defined in section 3.1 of [<a href="#eidattributes">EidAttributes</a>] to contain either a Swedish personal identity number, [<a href="#skv704">SKV704</a>], or a Swedish coordination number, [<a href="#skv707">SKV707</a>]. However, how to utilize coordination numbers in
-electronic services is, or has been, unclear. Not all Service Providers want, or are able to, use these types of identifiers. Therefore, this specification defines the &quot;accepts coordination
-number&quot; category as an opt-in feature for those Service Providers that can accept a <code>personalIdentityNumber</code> attribute to contain a coordination number as well as a personal identity number.</p>
-<p>An Identity Provider conformant with this specification MUST NOT deliver a coordination number
-in the <code>personalIdentityNumber</code> attribute unless the receiving Service Provider has declared 
-the <code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> entity category
-in its metadata.</p>
-<p><strong>Note</strong>: This entity category does <strong>not</strong> apply to the eIDAS specific attribute
-<code>mappedPersonalIdentityNumber</code>, see section 3.3.2 of [<a href="#eidattributes">EidAttributes</a>].
-Thus, a coordination number may be included in this attribute even if the Service Provider
-has not declared the entity category. </p>
-<p><a name="supports-user-message"></a></p>
-<h3 id="63-supports-user-message">6.3. supports-user-message</h3>
-<p><strong>URL</strong>: <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code></p>
-<p><strong>Description</strong>: Service Providers may include the <code>&lt;umsg:UserMessage&gt;</code> extension in authentication requests for the purpose of displaying a custom &quot;user message&quot; for the authentication users, see [<a href="#user-message-ext">UserMessageExt</a>]. An Identity Provider announces support for this extension by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category.</p>
-<p><a name="references"></a></p>
-<h2 id="7-references">7. References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="saml2core"></a>
-<strong>[SAML2Core]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
-Assertion Markup Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2meta"></a>
-<strong>[SAML2Meta]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">OASIS Standard, Metadata for the OASIS Security Assertion Markup
-Language (SAML) V2.0, March
-2005.</a></p>
-</blockquote>
-<p><a name="saml2metaattr"></a>
-<strong>[SAML2MetaAttr]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html">OASIS Committee Specification, SAML V2.0 Metadata Extension for
-Entity Attributes Version 1.0, August
-2009.</a></p>
-</blockquote>
-<p><a name="entcat"></a>
-<strong>[EntCat]</strong></p>
-<blockquote>
-<p><a href="https://tools.ietf.org/html/rfc8409">RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types</a>.</p>
-</blockquote>
-<p><a name="skv704"></a>
-<strong>[SKV704]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv704-8.pdf">Skatteverket, SKV 704 Utgåva 8,
-Personnummer</a>.</p>
-</blockquote>
-<p><a name="skv707"></a>
-<strong>[SKV707]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/mirror/skv/skv707-2.pdf">Skatteverket, SKV 707, Utgåva 2,
-Samordningsnummer</a>.</p>
-</blockquote>
-<p><a name="eidtillit"></a>
-<strong>[EidTillit]</strong></p>
-<blockquote>
-<p><a href="https://www.digg.se/digitala-tjanster/e-legitimering/tillitsnivaer-for-e-legitimering/tillitsramverk-for-svensk-e-legitimation">Tillitsramverket för Svensk e-legitimation</a>.</p>
-</blockquote>
-<p><a name="eiddeploy"></a>
-<strong>[EidDeploy]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/02_-_Deployment_Profile_for_the_Swedish_eID_Framework.html">Deployment Profile for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="sigsap"></a>
-<strong>[SigSAP]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/13_-_Signature_Activation_Protocol.html">Signature Activation Protocol for Federated Signing</a>.</p>
-</blockquote>
-<p><a name="user-message-ext"></a>
-<strong>[UserMessageExt]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html">User Message Extension in SAML Authentication Requests</a>.</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="8-changes-between-versions">8. Changes between versions</h2>
-<p><strong>Changes between version 1.8 and version 1.9:</strong></p>
-<ul class="list">
-<li><p>Fixed some broken links.</p>
-</li>
-<li><p>Section 6.2, &quot;accepts-coordination-number&quot;, was updated with changed logic for
-the <code>mappedPersonalIdentityNumber</code> attribute.</p>
-</li>
-<li><p>Added section 6.3, &quot;supports-user-message&quot;, with a definition for the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.7 and version 1.8:</strong></p>
-<ul class="list">
-<li><p>Section 2 was re-structured where new entity categories for loaX-orgid and loaX-name.</p>
-</li>
-<li><p>The Service Entity Category loa3-hsaid was removed. Its use is out of scope for 
-the Swedish eID Framework. However, it may be defined by the federation operator.</p>
-</li>
-<li><p>Section 6.2, accepts-coordination-number, defining the general entity category 
-<code>http://id.swedenconnect.se/general-ec/1.0/accepts-coordination-number</code> was added.
-This category introduces an opt-in feature for accepting Swedish coordination numbers
-delivered in the <code>personalIdentityNumber</code> attribute.</p>
-</li>
-<li><p>For many services entity categories we have added the following text under the &quot;LoA-identifier&quot; requirement: &quot;Or a corresponding LoA X URI&quot;. This means that the service entity category
-also applies to variants to the official LoA URI (defined in [<a href="#eidregistry">EidRegistry</a>]).</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.6 and version 1.7:</strong></p>
-<ul class="list">
-<li><p>A new entity category type, Service Contract, was added to section 5.</p>
-</li>
-<li><p>The reference [EntCat] now refers to <a href="https://tools.ietf.org/html/rfc8409">RFC-8409</a> instead of 
-<a href="https://tools.ietf.org/html/draft-young-entity-category">https://tools.ietf.org/html/draft-young-entity-category</a>.</p>
-</li>
-<li><p>Chapter 6, &quot;General Entity Categories&quot;, introduced a general entity category type for miscellaneous purposes.</p>
-</li>
-<li><p>Section 6.1, &quot;secure-authenticator-binding&quot;, was added defining the <code>http://id.swedenconnect.se/general-ec/1.0/secure-authenticator-binding</code> entity category.</p>
-</li>
-<li><p>Section 2.6, &quot;loa3-hsaid&quot;, was added. This section defines a service entity category for LoA3 where HSA-ID is the primary identity attribute.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.5 and version 1.6:</strong></p>
-<ul class="list">
-<li><p>The Service Property Category &quot;scal2&quot; was added to section 3.2.</p>
-</li>
-<li><p>Section 2.5, &quot;eidas-pnr-delivery&quot;, was updated to also require attribute release of the <code>dateOfBirth</code>-attribute.</p>
-</li>
-<li><p>Section 2.1, &quot;loa3-pnr&quot;, was updated with a restriction stating that the <code>personalIdentityNumber</code> only may contain a Swedish personal identity number (&quot;personnummer&quot;) and not a coordination number (&quot;samordningsnummer&quot;), if attribute release is made in <code>loa3-pnr</code> scope.</p>
-</li>
-<li><p>The loa3-hsaid Service Entity Category was defined in section 2.6.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.4 and version 1.5:</strong></p>
-<ul class="list">
-<li><p>Introduced the Service Entity Category “eidas-naturalperson”
-  (section 2.4) for support of authentication against the eIDAS
-  Framework.</p>
-</li>
-<li><p>Introduced the Service Entity Category &quot;eidas-pnr-delivery&quot; (section 2.5) for use by Swedish Identity Providers delivering assertions to Service Providers within the eIDAS federation.</p>
-</li>
-<li><p>  Added the Service Type Entity Categories &quot;public-sector-sp&quot; and &quot;private-sector-sp&quot; to section 4.</p>
-</li>
-<li><p>  Minor changes regarding discovery.</p>
-</li>
-<li><p>  Updates to explanatory text in chapter 2 about usage of service entity categories.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.3 and version 1.4:</strong></p>
-<ul class="list">
-<li><p>Version 1.3 of [Eid2Attributes] changed the terms “attribute
-  profiles” to “attribute sets”. This specification has therefore been
-  updated to reflect these changes.</p>
-</li>
-<li><p>Chapter 1.5, “Representation of Entity Categories in Metadata”, was
-  added to illustrate how entity categories are represented in
-  metadata.</p>
-</li>
-<li><p>Clarifications regarding the definition of Service Entity Categories
-  were made to chapter 2.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.2 and version 1.3:</strong></p>
-<ul class="list">
-<li><p>In chapter 1.4, “Use in Discovery Services”, the text that referred
-  to the Discovery Service usage of Service Property Entity Categories
-  when rendering user interfaces was removed.</p>
-</li>
-<li><p>In chapter 3.1, “mobile-auth”, changes were made to reflect that the
-  use of mobile-auth no longer governs which type of end user
-  interface the Discovery Service should render.</p>
-</li>
-<li><p>In chapter 2, “Definitions for Service Entity Categories”, URIs for
-  attribute profiles were added in definitions of the service entity
-  categories.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.1 and version 1.2:</strong></p>
-<ul class="list">
-<li>In chapter 2, “Definitions for Service Entity Categories”, two new
-  service entity categories have been defined, loa2-pnr and loa4-pnr.</li>
-</ul>
-<p><strong>Changes between version 1.0 and version 1.1:</strong></p>
-<ul class="list">
-<li><p>  The service property category mobile-auth was added.</p>
-</li>
-<li><p>Changes was made to chapter 1.4, “Use in Discovery Services”, where
-  mobile-auth was referred.</p>
-</li>
-</ul>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html b/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
new file mode 120000
index 0000000..4cd40cf
--- /dev/null
+++ b/docs/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
@@ -0,0 +1 @@
+../december-2024/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/updates/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html b/docs/updates/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
index f88a8a9..9dca9cc 120000
--- a/docs/updates/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
+++ b/docs/updates/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
@@ -1 +1 @@
-../november-2021/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
\ No newline at end of file
+../december-2024/07_-_Implementation_Profile_for_using_DSS_in_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/updates/08_-_Certificate_Profile_for_Central_Signing_Services.html b/docs/updates/08_-_Certificate_Profile_for_Central_Signing_Services.html
index cf8774d..d4381da 120000
--- a/docs/updates/08_-_Certificate_Profile_for_Central_Signing_Services.html
+++ b/docs/updates/08_-_Certificate_Profile_for_Central_Signing_Services.html
@@ -1 +1 @@
-../november-2021/08_-_Certificate_Profile_for_Central_Signing_Services.html
\ No newline at end of file
+../december-2024/08_-_Certificate_Profile_for_Central_Signing_Services.html
\ No newline at end of file
diff --git a/docs/updates/09_-_DSS_Extension_for_Federated_Signing_Services.html b/docs/updates/09_-_DSS_Extension_for_Federated_Signing_Services.html
index 8682a61..86f50f6 120000
--- a/docs/updates/09_-_DSS_Extension_for_Federated_Signing_Services.html
+++ b/docs/updates/09_-_DSS_Extension_for_Federated_Signing_Services.html
@@ -1 +1 @@
-../november-2021/09_-_DSS_Extension_for_Federated_Signing_Services.html
\ No newline at end of file
+../december-2024/09_-_DSS_Extension_for_Federated_Signing_Services.html
\ No newline at end of file
diff --git a/docs/updates/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html b/docs/updates/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
index d10a54f..8ef2f45 120000
--- a/docs/updates/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
+++ b/docs/updates/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/11_-_eIDAS_Constructed_Attributes_Specification_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/updates/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html b/docs/updates/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
index 79304ff..a02897a 120000
--- a/docs/updates/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
+++ b/docs/updates/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
@@ -1 +1 @@
-../november-2021/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
+../december-2024/12_-_BankID_Profile_for_the_Swedish_eID_Framework.html
\ No newline at end of file
diff --git a/docs/updates/13_-_Signature_Activation_Protocol.html b/docs/updates/13_-_Signature_Activation_Protocol.html
deleted file mode 100644
index 17fd02f..0000000
--- a/docs/updates/13_-_Signature_Activation_Protocol.html
+++ /dev/null
@@ -1,496 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Signature Activation Protocol for Federated Signing</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="signature-activation-protocol-for-federated-signing">Signature Activation Protocol for Federated Signing</h1>
-<h3 id="version-1.2---2022-12-20---*draft-version*">Version 1.2 - 2022-12-20 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2019-317</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2022. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirement-key-words">Requirement key words</a></p>
-<p> 1.2. <a href="#xml-namespace-references">XML namespace references</a></p>
-<p> 1.3. <a href="#structure">Structure</a></p>
-</li>
-<li><p><a href="#signature-activation-protocol"><strong>Signature Activation Protocol</strong></a></p>
-<p> 2.1. <a href="#scope">Scope</a></p>
-<p> 2.2. <a href="#data-exchange">Data Exchange</a></p>
-</li>
-<li><p><a href="#data-elements"><strong>Data elements</strong></a></p>
-<p> 3.1. <a href="#sadrequest">SADRequest</a></p>
-<p> 3.1.1. <a href="#syntax">Syntax</a></p>
-<p> 3.1.2. <a href="#example">Example</a></p>
-<p> 3.2. <a href="#signature-activation-data">Signature Activation Data</a></p>
-<p> 3.2.1. <a href="#sad-json-web-token">SAD JSON Web Token</a></p>
-<p> 3.2.1.1. <a href="#registered-jwt-claims">Registered JWT Claims</a></p>
-<p> 3.2.1.2. <a href="#sad-extension-claim">SAD Extension Claim</a></p>
-<p> 3.2.2. <a href="#example">Example</a></p>
-<p> 3.2.3 <a href="#verification-of-a-sad">Verification of a SAD</a></p>
-</li>
-<li><p><a href="#schemas"><strong>Schemas</strong></a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>This document specifies a <strong>Signature Activation Protocol</strong> (SAP) and its data elements for implementation of <strong>Sole Control Assurance Level 2</strong> (SCAL2) according the European standards prEN 419241 - Trustworthy Systems Supporting Server Signing - Part 1 and 2 (prEN 419 241-1 [<a href="#rsig-pp-1">RSIG-PP-1</a>] and prEN 419 241-2 [<a href="#rsig-pp-2">RSIG-PP-2</a>]).</p>
-<p>The Signature Activation Protocol (SAP) defined in this document is used to exchange data between a signature service and a delegated authenticating authority such as a SAML Identity Provider. The function of the SAP is to authenticate the intent of a signer to sign a particular document, or collection of documents, through exchange of the following data elements.</p>
-<ul class="list">
-<li>Signature Activation Data (SAD) - Signed data, asserting the signer&#39;s agreement to sign specific data.</li>
-<li>SADRequest - Request for a SAD.</li>
-</ul>
-<p>The SAP specified in this document is specifically designed to be used with a signing service operating in accordance with the federated signing specification [<a href="#dss-ext">DSS-Ext</a>].</p>
-<p><a name="requirement-key-words"></a></p>
-<h3 id="1.1.-requirement-key-words">1.1. Requirement key words</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
-<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
-<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
-[<a href="#rfc2119">RFC2119</a>].</p>
-<p>These keywords are capitalized when used to unambiguously specify
-requirements over protocol features and behavior that affect the
-interoperability and security of implementations. When these words are
-not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="xml-namespace-references"></a></p>
-<h3 id="1.2.-xml-namespace-references">1.2. XML namespace references</h3>
-<p>The prefix <strong>sap:</strong> stands for the Signature Activation Protocol XML Schema namespace <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code> (<a href="https://docs.swedenconnect.se/schemas/csig/1.1/EidCsigSAP-1.1.xsd">https://docs.swedenconnect.se/schemas/csig/1.1/EidCsigSAP-1.1.xsd</a>).</p>
-<p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion Schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
-<p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol Schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
-<p><a name="structure"></a></p>
-<h3 id="1.3.-structure">1.3. Structure</h3>
-<p>This specification uses the following typographical conventions in text:
-<code>&lt;Eid2Element&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
-<code>OtherCode</code>.</p>
-<p><a name="signature-activation-protocol"></a></p>
-<h2 id="2.-signature-activation-protocol">2. Signature Activation Protocol</h2>
-<p><a name="scope"></a></p>
-<h3 id="2.1.-scope">2.1. Scope</h3>
-<p>The scope of the Signature Activation Protocol (SAP) is to support request for and delivery of the Signature Activation Data (SAD) to the Signature Activation Module (SAM). The SAM is a tamper resistant module inside the Remote Signing Service which validates the SAD in order to ensure that:</p>
-<ul class="list">
-<li>the signer is properly authenticated,</li>
-<li>the signer agrees to sign the data to be signed, and,</li>
-<li>the correct signing key for this signer and this instance of signing is properly identified.</li>
-</ul>
-<p>The federated signing model does not use pre-assigned signing keys. Instead, a new signing key is generated for each sign request and then permanently deleted. This particular use-case is recognised by prEN 419 241-1 [<a href="#rsig-pp-1">RSIG-PP-1</a>] and prEN 419 241-2 [<a href="#rsig-pp-2">RSIG-PP-2</a>], which under these conditions allows the signature key reference to be implicit and derived from the signer&#39;s identity. For the present implementation of the SAP the following data is included in the SAD:</p>
-<ul class="list">
-<li>the signer&#39;s identity,</li>
-<li>information about how the signer was authenticated and by whom, and,</li>
-<li>reference to the signature request, binding this instance of authentication to the specific instance of signing, the data being signed and the agreement to sign.</li>
-</ul>
-<p>This implements the scenario where the Identity Provider is the sole entity which can verify the signer&#39;s private credentials via the SIC (Signer’s Interaction Component). This instance of authentication is used by the Identity Provider to generate the SAD in accordance with section 5.10 of [<a href="#rsig-pp-1">RSIG-PP-1</a>].</p>
-<p><a name="data-exchange"></a></p>
-<h3 id="2.2.-data-exchange">2.2. Data exchange</h3>
-<p>This document specifies exchange of two data elements:</p>
-<ul class="list">
-<li><code>SADRequest</code></li>
-<li><code>SAD</code></li>
-</ul>
-<p>The <code>SADRequest</code> SHALL have the format defined in section <a href="#sadrequest">3.1</a>. When a Remote Signing Service request a SAD from the Identity Provider, it MUST include the <code>SADRequest</code> element as an request extension by including it as a child element to a <code>&lt;saml2p:Extensions&gt;</code> element in the <code>&lt;saml2p:AuthnRequest&gt;</code>.</p>
-<p>When an Identity Provider returns a SAD, as defined in section <a href="#signature-activation-data">3.2</a>, in a SAML Assertion, it MUST be included as a single string value of a <code>sad</code> attribute identified by the attribute name <code>urn:oid:1.2.752.201.3.12</code> as defined in the attribute specification [<a href="#eidattributes">EidAttributes</a>].</p>
-<p><a name="data-elements"></a></p>
-<h2 id="3.-data-elements">3. Data elements</h2>
-<p>The SAD requested in the SAP binds the documents to be signed to the intent by the signer to sign. This is accomplished by the interaction of a number of independent information attributes and elements as follows:</p>
-<ul class="list">
-<li><strong>Sign request ID</strong>. Identifies the sign request for signing specific documents. This sign request is sent to the signing service from the service provider requesting the signature. The sign request bound by this identifier contains all detailed data about what is being signed.</li>
-<li><strong>LoA</strong>. The level of assurance declaration asserting the level of security used to authenticate the user.</li>
-<li><strong>Number of documents to sign</strong>. Ensures that the user is aware whether more than one document is being signed. This allows adaptations of the signing UI displayed by the Identity Provider.</li>
-<li><strong>Identity of the signer</strong>. Allows verification that the signature is bound to the appropriate signer.</li>
-<li><strong>SAD Request ID</strong>. Unique identifier for the <code>SADRequest</code> element. This identifier is later included in the SAD in order to accomplish a binding between the request and the issued SAD.</li>
-</ul>
-<p>The SAD request and the SAD specified in this section specifies the data that needs to be exchanged in addition to other protocol elements specified by SAML as well as the federated signing specification [<a href="#dss-ext">DSS-Ext</a>].</p>
-<p><a name="sadrequest"></a></p>
-<h3 id="3.1.-sadrequest">3.1. SADRequest</h3>
-<p><a name="syntax"></a></p>
-<h4 id="3.1.1.-syntax">3.1.1. Syntax</h4>
-<p>The SAD Request is provided in a <code>&lt;sap:SADRequest&gt;</code> element. The element has the following elements and attributes:</p>
-<p><code>&lt;RequesterID&gt;</code> [Required]</p>
-<blockquote>
-<p>Specifies the SAML entityID of the requesting entity. The value for this element should be the same identifier as given in the <code>&lt;saml2:Issuer&gt;</code> element of the <code>&lt;saml2p:AuthnRequest&gt;</code> that encapsulates the <code>&lt;sap:SADRequest&gt;</code> extension.</p>
-</blockquote>
-<p><code>&lt;SignRequestID&gt;</code> [Required]</p>
-<blockquote>
-<p>Specifies the value of the <code>RequestID</code> attribute of the associated <code>SignRequest</code>.</p>
-</blockquote>
-<p><code>&lt;DocCount&gt;</code> [Required]</p>
-<blockquote>
-<p>The number of requested signatures in the associated sign request.</p>
-</blockquote>
-<p><code>&lt;RequestedVersion&gt;</code> [Optional Default=&quot;1.0&quot;]</p>
-<blockquote>
-<p>The requested version of the SAD.</p>
-</blockquote>
-<p><code>&lt;RequestParams&gt;</code> [Optional]</p>
-<blockquote>
-<p>Optional parameters provided as name-value pairs. This specification does not define any parameters. The use of parameters may be defined in profiles of this specification or may be negotiated by other means between a remote signing service and an Identity Provider.</p>
-</blockquote>
-<p><code>ID</code> [Required]</p>
-<blockquote>
-<p>Attribute holding an unique identifier for the <code>SADRequest</code>.</p>
-</blockquote>
-<p>The following schema fragment defines the <code>&lt;sap:SADRequest&gt;</code> element:</p>
-<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"SADRequest"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"sap:SADRequestType"</span> /&gt;
-
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"SADRequestType"</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequesterID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> /&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"SignRequestID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> /&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"DocCount"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:int"</span> /&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequestedVersion"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> minOccurs=<span class="hljs-string">"0"</span> default=<span class="hljs-string">"1.0"</span> /&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequestParams"</span> minOccurs=<span class="hljs-string">"0"</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"Parameter"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"sap:ParameterType"</span> minOccurs=<span class="hljs-string">"0"</span> maxOccurs=<span class="hljs-string">"unbounded"</span> /&gt;
-        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"ID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:ID"</span> use=<span class="hljs-string">"required"</span> /&gt;
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"ParameterType"</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"name"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> use=<span class="hljs-string">"required"</span> /&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p><a name="example"></a></p>
-<h4 id="3.1.2.-example">3.1.2. Example</h4>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">sap:SADRequest</span> <span class="hljs-attr">ID</span>=<span class="hljs-string">"_a74a068d0548a919e503e5f9ef901851"</span> <span class="hljs-attr">xmlns:sap</span>=<span class="hljs-string">"http://id.elegnamnden.se/csig/1.1/sap/ns"</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequesterID</span>&gt;</span>http://www.example.com/sigservice<span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequesterID</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">sap:SignRequestID</span>&gt;</span>f6e7d061a23293b0053dc7b038a04dad<span class="hljs-tag">&lt;/<span class="hljs-name">sap:SignRequestID</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">sap:DocCount</span>&gt;</span>1<span class="hljs-tag">&lt;/<span class="hljs-name">sap:DocCount</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequestedVersion</span>&gt;</span>1.0<span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequestedVersion</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">sap:RequestParams</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">sap:Parameter</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"ParamName"</span>&gt;</span>paramValue<span class="hljs-tag">&lt;/<span class="hljs-name">sap:Parameter</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">sap:RequestParams</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">sap:SADRequest</span>&gt;</span></code></pre><p><em>Example of a SADRequest.</em></p>
-<p><a name="signature-activation-data"></a></p>
-<h3 id="3.2.-signature-activation-data">3.2. Signature Activation Data</h3>
-<p><a name="sad-json-web-token"></a></p>
-<h4 id="3.2.1.-sad-json-web-token">3.2.1. SAD JSON Web Token</h4>
-<p>This section specifies a JSON Web Token (JWT) in accordance with [<a href="#rfc7519">RFC7519</a>] as the SAD container, binding the data as defined in section <a href="#scope">2.1</a>.</p>
-<p>The SAD JWT MUST have the form of a signed JWS (JSON Web Signature).</p>
-<p><a name="registered-jwt-claims"></a></p>
-<h5 id="3.2.1.1.-registered-jwt-claims">3.2.1.1. Registered JWT Claims</h5>
-<p>The data signed by the SAD JWT is carried in the JWS payload in the form of JWT claims using registered claim names (as specified in [<a href="#rfc7519">RFC7519</a>]) in addition to one private claim name (<code>seElnSadext</code>) specified in section <a href="#sad-extension-claim">3.2.1.2</a>. The following table defines the use of registered claims.</p>
-<table>
-<thead>
-<tr>
-<th>name</th>
-<th>Content</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>sub</strong></td>
-<td>Subject - holds the attribute value of the signer&#39;s unique identifier.</td>
-</tr>
-<tr>
-<td><strong>aud</strong></td>
-<td>Audience - holds the entityID of the Signature Service which is the legitimate recipient of this SAD. This value corresponds to the <code>&lt;sap:RequesterID&gt;</code> element of the SAD request.</td>
-</tr>
-<tr>
-<td><strong>iss</strong></td>
-<td>Issuer - holds the entityID of the IdP that generated this SAD.</td>
-</tr>
-<tr>
-<td><strong>exp</strong></td>
-<td>Expiry - specifies the time when this SAD is no longer valid (epoch time/seconds since 1970-01-01).</td>
-</tr>
-<tr>
-<td><strong>iat</strong></td>
-<td>Issued At - specifies the time when this SAD was issued (epoch time/seconds since 1970-01-01).</td>
-</tr>
-<tr>
-<td><strong>jti</strong></td>
-<td>Unique identifier of this SAD.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="sad-extension-claim"></a></p>
-<h5 id="3.2.1.2.-sad-extension-claim">3.2.1.2. SAD Extension Claim</h5>
-<p>A private claim name is defined in this specification which extends the registered claims with additional SAD data:</p>
-<blockquote>
-<p><code>seElnSadext</code></p>
-</blockquote>
-<p>The claim identified by this name has the value of a JSON object holding name-value pairs in accordance with the following table:</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Type</th>
-<th>Content</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>ver</strong></td>
-<td>String</td>
-<td>The version of this claim, default 1.0 (Optional).</td>
-</tr>
-<tr>
-<td><strong>irt</strong></td>
-<td>String</td>
-<td>In Response To - holds the identifier of the SAD request (<code>ID</code> attribute) that was used to request this SAD.</td>
-</tr>
-<tr>
-<td><strong>attr</strong></td>
-<td>String</td>
-<td>Attribute - holds the URI identifier of the attribute specifying the users unique identifier value.</td>
-</tr>
-<tr>
-<td><strong>loa</strong></td>
-<td>String</td>
-<td>LevelOfAssurance - holds the URI identifier of the level of assurance (LoA) used to authenticate the signer.</td>
-</tr>
-<tr>
-<td><strong>reqid</strong></td>
-<td>String</td>
-<td>RequestID - holds the ID of the sign request associated with this SAD. Inclusion of this ID assert that the authenticated subject agrees to sign the docuements identified by this sign reqeust.</td>
-</tr>
-<tr>
-<td><strong>docs</strong></td>
-<td>Integer</td>
-<td>Specifies the number of documents to be signed in the associated sign request.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="example"></a></p>
-<h4 id="3.2.2.-example">3.2.2. Example</h4>
-<p>The following example illustrates a claim binding the following claim values:</p>
-<p><strong>Registered Claims</strong></p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>sub</strong></td>
-<td><code>197802031877</code></td>
-</tr>
-<tr>
-<td><strong>aud</strong></td>
-<td><code>https://sandbox.swedenconnect.se/eid2cssp</code></td>
-</tr>
-<tr>
-<td><strong>iss</strong></td>
-<td><code>http://dev.test.swedenconnect.se/idp</code></td>
-</tr>
-<tr>
-<td><strong>exp</strong></td>
-<td><code>1666128029</code> (Oct 18, 2022, 23:20:29 CET)</td>
-</tr>
-<tr>
-<td><strong>iat</strong></td>
-<td><code>1666127729</code> (Oct 18, 2022, 23:15:29 CET)</td>
-</tr>
-<tr>
-<td><strong>jti</strong></td>
-<td><code>NbnmpGA1gwtL3AgtKPfe77Ia</code></td>
-</tr>
-</tbody>
-</table>
-<p><strong>seElnSadext Claim</strong></p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>ver</strong></td>
-<td><code>1.0</code></td>
-</tr>
-<tr>
-<td><strong>irt</strong></td>
-<td><code>752c30b3-30c1-49f0-ab04-a28909dc3b67</code></td>
-</tr>
-<tr>
-<td><strong>attr</strong></td>
-<td><code>urn:oid:1.2.752.29.4.13</code></td>
-</tr>
-<tr>
-<td><strong>loa</strong></td>
-<td><code>http://id.elegnamnden.se/loa/1.0/loa3</code></td>
-</tr>
-<tr>
-<td><strong>reqid</strong></td>
-<td><code>70fabf30-d474-4d21-8463-2c6811005ce0</code></td>
-</tr>
-<tr>
-<td><strong>docs</strong></td>
-<td><code>4</code></td>
-</tr>
-</tbody>
-</table>
-<p><strong>JWS Header</strong></p>
-<p>The Header of the JWS specifies that it is a JWT by the &quot;typ&quot; parameter and the signature algoritm through the &quot;alg&quot; parameter. In this example the header is <code>{&quot;typ&quot;:&quot;JWT&quot;,&quot;alg&quot;:&quot;RS256&quot;}</code>. The Base64 URL-encoded header is:</p>
-<blockquote>
-<p>eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9</p>
-</blockquote>
-<p><strong>JWS Payload</strong></p>
-<p>The JWS payload holding the JWT claims is represented by the following JSON object:</p>
-<pre class="hljs"><code>{
-    <span class="hljs-attr">"sub"</span>: <span class="hljs-string">"197802031877"</span>,
-    <span class="hljs-attr">"aud"</span>: <span class="hljs-string">"https://sandbox.swedenconnect.se/eid2cssp"</span>,
-    <span class="hljs-attr">"iss"</span>: <span class="hljs-string">"http://dev.test.swedenconnect.se/idp"</span>,
-    <span class="hljs-attr">"exp"</span>: <span class="hljs-number">1666128029</span>,
-    <span class="hljs-attr">"iat"</span>: <span class="hljs-number">1666127729</span>,
-    <span class="hljs-attr">"jti"</span>: <span class="hljs-string">"NbnmpGA1gwtL3AgtKPfe77Ia"</span>,
-    <span class="hljs-attr">"seElnSadext"</span>: {
-        <span class="hljs-attr">"ver"</span>: <span class="hljs-string">"1.0"</span>,
-        <span class="hljs-attr">"irt"</span>: <span class="hljs-string">"752c30b3-30c1-49f0-ab04-a28909dc3b67"</span>,
-        <span class="hljs-attr">"attr"</span>: <span class="hljs-string">"urn:oid:1.2.752.29.4.13"</span>,
-        <span class="hljs-attr">"loa"</span>: <span class="hljs-string">"http://id.elegnamnden.se/loa/1.0/loa3"</span>,
-        <span class="hljs-attr">"reqid"</span>: <span class="hljs-string">"70fabf30-d474-4d21-8463-2c6811005ce0"</span>,
-        <span class="hljs-attr">"docs"</span>: <span class="hljs-number">4</span>
-    }
-}</code></pre><p>This payload is represented by the following Base64 URL-encoded string:</p>
-<blockquote>
-<p>eyJzdWIiOiIxOTc4MDIwMzE4NzciLCJhdWQiOiJodHRwczovL3NhbmRib3guc3dlZGVuY29ubmVjdC5zZS9laWQyY3NzcCIsImlzcyI6Imh0dHA6Ly9kZXYudGVzdC5zd2VkZW5jb25uZWN0LnNlL2lkcCIsImV4cCI6MTY2NjEyODAyOSwiaWF0IjoxNjY2MTI3NzI5LCJqdGkiOiJOYm5tcEdBMWd3dEwzQWd0S1BmZTc3SWEiLCJzZUVsblNhZGV4dCI6eyJ2ZXIiOiIxLjAiLCJpcnQiOiI3NTJjMzBiMy0zMGMxLTQ5ZjAtYWIwNC1hMjg5MDlkYzNiNjciLCJhdHRyIjoidXJuOm9pZDoxLjIuNzUyLjI5LjQuMTMiLCJsb2EiOiJodHRwOi8vaWQuZWxlZ25hbW5kZW4uc2UvbG9hLzEuMC9sb2EzIiwicmVxaWQiOiI3MGZhYmYzMC1kNDc0LTRkMjEtODQ2My0yYzY4MTEwMDVjZTAiLCJkb2NzIjo0fX0</p>
-</blockquote>
-<p><strong>JWT</strong></p>
-<p>The complete SAD JWT including signature:</p>
-<blockquote>
-<p>eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxOTc4MDIwMzE4NzciLCJhdWQiOiJodHRwczovL3NhbmRib3guc3dlZGVuY29ubmVjdC5zZS9laWQyY3NzcCIsImlzcyI6Imh0dHA6Ly9kZXYudGVzdC5zd2VkZW5jb25uZWN0LnNlL2lkcCIsImV4cCI6MTY2NjEyODAyOSwiaWF0IjoxNjY2MTI3NzI5LCJqdGkiOiJOYm5tcEdBMWd3dEwzQWd0S1BmZTc3SWEiLCJzZUVsblNhZGV4dCI6eyJ2ZXIiOiIxLjAiLCJpcnQiOiI3NTJjMzBiMy0zMGMxLTQ5ZjAtYWIwNC1hMjg5MDlkYzNiNjciLCJhdHRyIjoidXJuOm9pZDoxLjIuNzUyLjI5LjQuMTMiLCJsb2EiOiJodHRwOi8vaWQuZWxlZ25hbW5kZW4uc2UvbG9hLzEuMC9sb2EzIiwicmVxaWQiOiI3MGZhYmYzMC1kNDc0LTRkMjEtODQ2My0yYzY4MTEwMDVjZTAiLCJkb2NzIjo0fX0.Qn-K-5V5-979GMITVSXgqWOrSVQfYFUMLv0P8PLUMSZzF6s6Zk05SOztH3XGN-4AjmjQeBHcqylpzoqG26eIXW7kuJZB9zodhAyTcvOogQj62XUFsoun5wfWpou8v8-Cpw1G4cwFZdMKt-oRbN43ViZ8u7EIZHBjzYMxfJNgMv2YGmzMQDPQLmtIW-f_O0nE_NPcFsaweYGJXcEWxi7fE3wzNnOR2rPBgQ3L0oehF2mP9dhenlptKrugH6Ru6eLZH66yFaAtR5RRA2m1wh2fXnwXJWO0-8jrvIZiZ9GLDt9W0r1Hs5Le--KPeuPcStli0nIi5YVLoAiGUaHc-Eb_DILwdqYpHS6mxJL3lb8j8u5JsIdEj9FEpqD8MlCbVM4HaWDL_wIiU16QVUOrxPUjoo3wyxLYhW6x3WnQ2an8fhIgahck7m9gS6_rVHKG1OAL_jn4h5jZzP-gX9yZeNcfTmhSiEdwrObydZ4dKx7JGEbmKn4EK1-8Pc65SOj9Zg5jTsRsl6uo9dMoJ-35Tb-x5IKsGs9Y1_94NCuqJH_a7HgC8nORfHBDOTPjzG008FLEFHSRmql6hYSYEd9F3kvR5816KixZpLT_BEED1m4RNdufa8nYEgEroi6X_AvmjpZKiwXCgnJyW6_80IIV89EMViiQ-BjTSSt8AK5KxxpTLkA</p>
-</blockquote>
-<p><a name="verification-of-a-sad"></a></p>
-<h4 id="3.2.3.-verification-of-a-sad">3.2.3. Verification of a SAD</h4>
-<p>The recipient of a requested SAD MUST verify it as part of the SAML response processing by asserting the following:</p>
-<ul class="list">
-<li>That the signature of the SAD JWT verifies correctly using the signature certificate of the issuing Identity Provider (found in the Identity Provider metadata).</li>
-<li>That the version of the SAD (<code>seElnSadext.ver</code>) matches the <code>&lt;sap:RequestedVersion&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>.</li>
-<li>That the audience (<code>aud</code>) matches the entityID of the recipient, i.e., matches the <code>&lt;sap:RequesterID&gt;</code> element from the <code>&lt;sap:SADRequest&gt;</code>.</li>
-<li>That the issuer (<code>iss</code>) value matches the issuer entityID of the assertion containing the SAD (*).</li>
-<li>That the SAD is valid by checking the expiry (<code>exp</code>) and issued-at (<code>iat</code>) values (allowing for a reasonable clock skew).</li>
-<li>That the in-response-to (<code>seElnSadExt.irt</code>) value matches that <code>ID</code> of the corresponding <code>&lt;sap:SADRequest&gt;</code>.</li>
-<li>That the subject (<code>sub</code>) value is also represented in the SAML assertion as an attribute having the name given by the <code>seElnSadExt.attr</code> field.</li>
-<li>That the level of assurance (<code>seElnSadEx.loa</code>) value matches the value given in the <code>&lt;saml2:AuthnContextClassRef&gt;</code> element of the assertion.</li>
-<li>That the request ID (<code>seElnSadEx.reqid</code>) value matches the ID for the sign request (which is passed in the <code>&lt;sap:SignRequestID&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>).</li>
-<li>That the number of documents specified in the SAD (<code>seElnSadEx.docs</code>) matches the <code>&lt;sap:DocCount&gt;</code> element of the <code>&lt;sap:SADRequest&gt;</code>.</li>
-</ul>
-<p>If any of the above verification steps fail, the Signature Service MUST reject the assertion.</p>
-<blockquote>
-<p>[*]: In the case where a Signature Service communicates with a Proxy Identity Provider that forwards requests to an <em>authenticating</em> Identity Provider that issues a SAD, the <code>iss</code>-value of the SAD will differ from the issuer of the assertion that is received by the Signature Service. In these cases the Signature Service should compare the <code>iss</code>-value with the value found in the <code>&lt;saml2:AuthenticatingAuthority&gt;</code> element of the assertion, or with relevant local policy and out-of-band configuration data.</p>
-</blockquote>
-<p><a name="schemas"></a></p>
-<h2 id="4.-schemas">4. Schemas</h2>
-<p>The following XML schema defines the <code>http://id.elegnamnden.se/csig/1.1/sap/ns</code> name space:</p>
-<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">"1.0"</span> encoding=<span class="hljs-string">"UTF-8"</span>?&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">"http://www.w3.org/2001/XMLSchema"</span> elementFormDefault=<span class="hljs-string">"qualified"</span>
-    targetNamespace=<span class="hljs-string">"http://id.elegnamnden.se/csig/1.1/sap/ns"</span>
-    xmln<span class="hljs-variable">s:sap</span>=<span class="hljs-string">"http://id.elegnamnden.se/csig/1.1/sap/ns"</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/csig/<span class="hljs-number">1.1</span>/EidCsigSAP-<span class="hljs-number">1.1</span>.xsd
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"SADRequest"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"sap:SADRequestType"</span> /&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"SADRequestType"</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequesterID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> /&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"SignRequestID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> /&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"DocCount"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:int"</span> /&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"RequestedVersion"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> minOccurs=<span class="hljs-string">"0"</span> default=<span class="hljs-string">"1.0"</span> /&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> minOccurs=<span class="hljs-string">"0"</span> name=<span class="hljs-string">"RequestParams"</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-          &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-            &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"Parameter"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"sap:ParameterType"</span> minOccurs=<span class="hljs-string">"0"</span> maxOccurs=<span class="hljs-string">"unbounded"</span> /&gt;
-          &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-        &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"ID"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:ID"</span> use=<span class="hljs-string">"required"</span> /&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"ParameterType"</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">"name"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"xs:string"</span> use=<span class="hljs-string">"required"</span> /&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
-<h2 id="5.-normative-references">5. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="rfc7519"></a>
-<strong>[RFC7519]</strong></p>
-<blockquote>
-<p><a href="http://www.rfc-editor.org/info/rfc7519">Jones, M., Bradley, J., and N. Sakimura, &quot;JSON Web Token (JWT)&quot;, RFC 7519, DOI 10.17487/RFC7519, May 2015</a>.</p>
-</blockquote>
-<p><a name="eidattributes"></a>
-<strong>[EidAttributes]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html">Attribute Specification for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="dss-ext"></a>
-<strong>[DSS-Ext]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/09_-_DSS_Extension_for_Federated_Signing_Services.html">DSS Extension for Federated Central Signing Services</a>.</p>
-</blockquote>
-<p><a name="rsig-pp-1"></a>
-<strong>[RSIG-PP-1]</strong></p>
-<blockquote>
-<p>European Standard prEN 419241-1 - Trustworthy Systems Supporting Server Signing - Part 1:
-General System Security Requirements</p>
-</blockquote>
-<p><a name="rsig-pp-2"></a>
-<em>*[RSIG-PP-2]</em>s</p>
-<blockquote>
-<p>European Standard prEN 419241-2 - Trustworthy Systems Supporting Server Signing - Part 2:
-Protection profile for QSCD for Server Signing</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="6.-changes-between-versions">6. Changes between versions</h2>
-<p><strong>Changes between version 1.1 and 1.2:</strong></p>
-<ul class="list">
-<li><p>The protocol logic was clarified by removing references to sign message (which was never present in the actual protocol) and replacing this with a clarification of the semantics of including the the Sign Request ID in SAD to assert the acceptance to sign the documents referenced in that Sign Request.</p>
-</li>
-<li><p>Updated examples where the use of &quot;signmessage&quot; LoA URI:s was removed.</p>
-</li>
-<li><p>Updated broken links.</p>
-</li>
-</ul>
-<p><strong>Changes between version 1.0 and 1.1:</strong></p>
-<ul class="list">
-<li>The <code>RequestedVersion</code> element of the <code>SADRequestType</code> is now marked as optional in the schema definition.</li>
-</ul>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/13_-_Signature_Activation_Protocol.html b/docs/updates/13_-_Signature_Activation_Protocol.html
new file mode 120000
index 0000000..0f17b6d
--- /dev/null
+++ b/docs/updates/13_-_Signature_Activation_Protocol.html
@@ -0,0 +1 @@
+../december-2024/13_-_Signature_Activation_Protocol.html
\ No newline at end of file
diff --git a/docs/updates/14_-_Principal_Selection_in_SAML_Authentication_Requests.html b/docs/updates/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
index f80c2ae..c843de4 120000
--- a/docs/updates/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
+++ b/docs/updates/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
@@ -1 +1 @@
-../november-2021/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
\ No newline at end of file
+../december-2024/14_-_Principal_Selection_in_SAML_Authentication_Requests.html
\ No newline at end of file
diff --git a/docs/updates/15_-_Signature_Validation_Token.html b/docs/updates/15_-_Signature_Validation_Token.html
deleted file mode 100644
index be74dc9..0000000
--- a/docs/updates/15_-_Signature_Validation_Token.html
+++ /dev/null
@@ -1,726 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>Signature Validation Token</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="signature-validation-token">Signature Validation Token</h1>
-<h3 id="version-1.0---2020-12-16---*draft-version*">Version 1.0 - 2020-12-16 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2020-60</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2020. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#definitions">Definitions</a></p>
-</li>
-<li><p><a href="#signature-validation-token"><strong>Signature validation token</strong></a></p>
-<p> 2.1. <a href="#function">Function</a></p>
-<p> 2.2. <a href="#signature-validation-token-syntax">Signature Validation Token Syntax</a></p>
-<p> 2.2.1. <a href="#data-types">Data Types</a></p>
-<p> 2.2.2. <a href="#signature-validation-token-jwt-claims">Signature Validation Token JWT Claims</a></p>
-<p> 2.2.3. <a href="#claim-object-classes">Claim Object Classes</a></p>
-<p> 2.2.3.1. <a href="#the-sigvalidation-object">The SigValidation Object</a></p>
-<p> 2.2.3.2. <a href="#the-signature-claims-object">The Signature Claims Object</a></p>
-<p> 2.2.3.3. <a href="#the-sigreference-claims-object">The SigReference Claims Object</a></p>
-<p> 2.2.3.4. <a href="#the-signeddata-claims-object">The SignedData Claims Object</a></p>
-<p> 2.2.3.5. <a href="#the-policyvalidation-claims-object">The PolicyValidation Claims Object</a></p>
-<p> 2.2.3.6. <a href="#the-timevalidation-claims-object">The TimeValidation Claims Object</a></p>
-<p> 2.2.3.7. <a href="#the-certreference-claims-object">The CertReference Claims Object</a></p>
-<p> 2.2.4. <a href="#svt-jose-header">SVT JOSE Header</a></p>
-</li>
-<li><p><a href="#profiles"><strong>Profiles</strong></a></p>
-</li>
-<li><p><a href="#signature-validation-with-signature-validation-token"><strong>Signature Validation with Signature Validation Token</strong></a></p>
-</li>
-<li><p><a href="#examples"><strong>Examples</strong></a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>Electronic signatures have a limited lifespan regarding when they can be validated and determined to be authentic. Many factors make it more difficult to validate electronic signatures over time. For example:</p>
-<ul class="list">
-<li>Trusted information about the validity of the signing certificate is not available.</li>
-<li>No proof of time when the signature was actually created is available.</li>
-<li>Algorithms used to create the signature is no longer considered secure.</li>
-<li>Services necessary to validate the signature are no longer available.</li>
-<li>Inability to verify supporting evidence such as, CA certificates, OCSP responses, revocation lists or timestamps.</li>
-</ul>
-<p>The challenge to validate an electronic signature is increasing over time up until the point when it is simply impossible to verify the signature with a sufficient level of assurance.</p>
-<p>Current existing standards such as the ETSI AdES profiles for CMS, XML and PDF signatures can be used to prolong the lifetime of a signature by storing data that supports validation of the signature beyond the lifetime of the signing certificate. The problem with this approach is that the amount of information that must be stored along with the signature is constantly growing over time. The increasing amount of information and signed objects that must be validated in order to verify the original signature is growing in complexity to the point where it may become infeasible to validate the original signature.</p>
-<p>The Signature Validation Token (SVT) defined in this specification takes a fundamentally different approach to the problem by providing an evidence that asserts the validity of a signature. The SVT is issued by a trusted authority, and asserts that a particular signature was successfully validated according to defined procedures at a certain time. The basic idea and intent behind the SVT is that once the SVT is issued by a trusted authority, any future validation of that signature is satisfied by validating the SVT without any need to also validate the original signature.</p>
-<p>This approach drastically reduces the complexity of signature validation of older signatures for the simple reason that validating the SVT just requires validation of the signature over the SVT. The SVT can be signed with keys and algorithms that makes it valid for a considerable time in the future and it can be re-issued with fresh keys and signatures to extend the lifetime of the original signature validity, if necessary.</p>
-<p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>, <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>, <strong>MAY</strong>, and <strong>OPTIONAL</strong> in this document are to be interpreted as described in BCP 14 [<a href="#rfc2119">RFC2119</a>] [<a href="#rfc8174">RFC8174</a>] when, and only when, they appear in all capitals, as shown here.</p>
-<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="definitions"></a></p>
-<h3 id="1.2.-definitions">1.2. Definitions</h3>
-<p>This document use the following defined terms:</p>
-<table>
-<thead>
-<tr>
-<th>Term</th>
-<th>Meaning</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>Signed Data</td>
-<td>The data covered by a particular signature. This is typically equivalent to the signed document and represents the data that the signer intended to sign. In some cases, such as in some XML signatures, the signed data can be the collection of several data fragments each referenced by the signature. In the case of PDF, this is the data covered by the &quot;ByteRange&quot; parameter in the signature dictionary.</td>
-</tr>
-<tr>
-<td>Signed Bytes</td>
-<td>These are the actual bytes of data that was hashed and signed by the signature algorithm. In most cases this is not the actual Signed Data, but a collection of signature metadata that includes references (hash) of the Signed Data as well as information about algorithms and other data bound to a signature. In XML this is the canonicalized SignedInfo element and in CMS/PDF signatures this is the DER encoded SignedAttributes structure.</td>
-</tr>
-</tbody>
-</table>
-<p>When these terms are used in their defined meaning, they appear with a capitalized first letter as shown in the table.</p>
-<p><a name="signature-validation-token"></a></p>
-<h2 id="2.-signature-validation-token">2. Signature Validation Token</h2>
-<p><a name="function"></a></p>
-<h3 id="2.1.-function">2.1. Function</h3>
-<p>The function of the Signature Validation Token (SVT) is to capture evidence of signature validity at one instance of secure signature validation process and to use that evidence to eliminate the need to perform any repeated cryptographic validation of the original signature value, as well as reliance on any hash values bound to that signature. The SVT achieves this by binding the following information to a specific electronic signature:</p>
-<ul class="list">
-<li>A unique identification of the signature.</li>
-<li>The data and metadata signed by the signature.</li>
-<li>The signer&#39;s certificate that was validated as part of signature validation.</li>
-<li>The certificate chain that was used to validate the signer&#39;s certificate.</li>
-<li>An assertion providing evidence of that the signature was validated, when in time the validation was performed, which procedures that was used to validate the signature, and the outcome of the validation.</li>
-<li>An assertion providing evidence of the point in time at which the signature is known to have existed, which procedures that was used to validate the time of existence and the outcome of the validation.</li>
-</ul>
-<p>Using an SVT is equivalent to validating a signed document in a system once and then using that document multiple times without revalidating the signature for each usage. Such procedures are common in systems where the document is residing in a safe and trusted environment where it is protected against modification. The SVT allows the time and environment where the document can be stored and used to expand beyond a locally controlled environment and a short instance of time.</p>
-<p>Using the SVT, the signed document can be validated once using a reliable trusted service and after that the SVT can be used to extend reliance of that secure validation process. The SVT is therefore not only a valuable tool to extend the lifetime of a signed document, but also useful since a single secure validation service can be deployed, instead of having to maintain close integrations between signature validations and document usage.</p>
-<p><a name="signature-validation-token-syntax"></a></p>
-<h3 id="2.2.-signature-validation-token-syntax">2.2. Signature Validation Token Syntax</h3>
-<p>The SVT is carried in a JSON Web Token (JWT) in accordance with [<a href="#rfc7519">RFC7519</a>].</p>
-<p><a name="data-types"></a></p>
-<h3 id="2.2.1.-data-types">2.2.1. Data Types</h3>
-<p>The contents of claims in an SVT are specified using the claims data types in the following table:</p>
-<table>
-<thead>
-<tr>
-<th>Claims Data Type</th>
-<th>JSON Data Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>String</strong></td>
-<td>string</td>
-<td>An arbitrary case sensitive string value.</td>
-</tr>
-<tr>
-<td><strong>Base64Binary</strong></td>
-<td>string</td>
-<td>String representation of Base64 encoded byte array of binary data.</td>
-</tr>
-<tr>
-<td><strong>StringOrURI</strong></td>
-<td>string</td>
-<td>As defined in [<a href="#rfc7519">RFC7519</a>].<br/> A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a &quot;:&quot; character MUST be a URI.</td>
-</tr>
-<tr>
-<td><strong>URI</strong></td>
-<td>string</td>
-<td>A valid URI.</td>
-</tr>
-<tr>
-<td><strong>Integer</strong></td>
-<td>number</td>
-<td>A 32-bit signed integer value (from -2<sup>31</sup> to 2<sup>31</sup> - 1).</td>
-</tr>
-<tr>
-<td><strong>Long</strong></td>
-<td>number</td>
-<td>A 64-bit signed integer value (from -2<sup>63</sup> to 2<sup>63</sup> - 1).</td>
-</tr>
-<tr>
-<td><strong>NumericDate</strong></td>
-<td>number</td>
-<td>As defined in [<a href="#rfc7519">RFC7519</a>].<br />A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.</td>
-</tr>
-<tr>
-<td><strong>Boolean</strong></td>
-<td>boolean</td>
-<td>The explicit value true or false.</td>
-</tr>
-<tr>
-<td><strong>Object&lt;Class&gt;</strong></td>
-<td>object</td>
-<td>A JSON object holding a claims object of a class defined in this specification (see <a href="#signature-validation-token-jwt-claims">section 2.2.2</a>).</td>
-</tr>
-<tr>
-<td><strong>Map&lt;Type&gt;</strong></td>
-<td>object</td>
-<td>A JSON object with name-value pairs where the value is an object of the specified Type in the notation.<br />Example: Map&lt;String&gt; according to this notation is a JSON object with name value pairs where all values are of type String.</td>
-</tr>
-<tr>
-<td><strong>Array</strong></td>
-<td>array</td>
-<td>An array of values of a specific data type as defined in this table. An array is expressed in this specification by square brackets. For example: <strong>[String]</strong> indicates an array of String values and <strong>[Object&lt;DocHash&gt;]</strong> indicates an array of DocHash objects.</td>
-</tr>
-<tr>
-<td><strong>Null</strong></td>
-<td>null</td>
-<td>Representing an absent value. A claim with a null value is equivalent with an absent claim in this specification.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="signature-validation-token-jwt-claims"></a></p>
-<h4 id="2.2.2.-signature-validation-token-jwt-claims">2.2.2. Signature Validation Token JWT Claims</h4>
-<p>The signature validation token JWT SHALL contain claims according to the following table.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>jti</code></td>
-<td><strong>String</strong></td>
-<td>A &quot;JWT ID&quot; registered claim according to [<a href="#rfc7519">RFC7519</a>]. It is RECOMMENDED that the identifier holds a hexadecimal string representation of a 128-bit unsigned integer.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>iss</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>An &quot;Issuer&quot; registered claim according to [<a href="#rfc7519">RFC7519</a>]. An arbitrary unique identifier of the SVT issuer. This value SHOULD have the value of an URI identifier based on a domain owned by the issuer.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>iat</code></td>
-<td><strong>NumericDate</strong></td>
-<td>An &quot;Issued At&quot; registered claim according to [<a href="#rfc7519">RFC7519</a>] expressing the time when this SVT was issued.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>aud</code></td>
-<td><strong>[StringOrURI]</strong> or <strong>StringOrURI</strong></td>
-<td>An &quot;Audience&quot; registered claim according to [<a href="#rfc7519">RFC7519</a>]. The audience claim is an array of one or more identifiers, identifying intended recipients of the SVT. Each identifier MAY identify a single entity, a group of entities or a common policy adopted by a group of entities. If only one value is provided it MAY be provided as a single <strong>StringOrURI</strong> value instead of as an array of values.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>exp</code></td>
-<td><strong>NumericDate</strong></td>
-<td>An &quot;Expiration Time&quot; registered claim according to [<a href="#rfc7519">RFC7519</a>] expressing the time when services and responsibilities related to this SVT is no longer provided by the SVT issuer. The precise meaning of the expiration time claim is defined by local policies. See implementation note below.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>sig_val_claims</code></td>
-<td><strong>Object&lt;SigValidation&gt;</strong></td>
-<td>Signature validation claims for this SVT extending the standard registered JTW claims above.</td>
-<td>MANDATORY</td>
-</tr>
-</tbody>
-</table>
-<blockquote>
-<p><strong>Note</strong>: An SVT asserts that a certain validation process was undertaken at a certain instance of time. This fact never changes and never expires. However, some aspects of the SVT such as liability for false claims or service provision related to a specific SVT may expire after a certain period of time, such as a service where an old SVT can be upgraded to a new SVT signed with fresh keys and algorithms.</p>
-</blockquote>
-<p><a name="claim-object-classes"></a></p>
-<h4 id="2.2.3.-claim-object-classes">2.2.3. Claim Object Classes</h4>
-<p><a name="the-sigvalidation-object"></a></p>
-<h5 id="2.2.3.1.-the-sigvalidation-object">2.2.3.1. The SigValidation Object</h5>
-<p>The <strong>SigValidation</strong> claims object holds all custom claims of the SVT JWT and contains the following parameters:</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>ver</code></td>
-<td><strong>String</strong></td>
-<td>Version. This version is indicated by the value &quot;1.0&quot;.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>profile</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>Name of a profile applied to this specification that defines conventions of content of specific claims and extension points.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>hash_algo</code></td>
-<td><strong>URI</strong></td>
-<td>The URI identifier of the hash algorithm used to provide hash values within the SVT. The URI identifier SHALL be one defined in [<a href="#rfc6931">RFC6931</a>] or in the IANA registry defined by this RFC.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>sig</code></td>
-<td><strong>[Object&lt;Signature&gt;]</strong></td>
-<td>Information about validated signatures as an array of <strong>Signature</strong> objects. If the SVT contains signature validation evidence for more than one signature, then each signature is represented by a separate <strong>Signature</strong> object. At least one <strong>Signature</strong> object MUST be present.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>ext</code></td>
-<td><strong>Map&lt;String&gt;</strong></td>
-<td>Extension point for additional claims related to the SVT. Extension claims are added at the discretion of the SVT issuer but MUST follow any conventions defined in a profile of this specification (see <a href="#profiles">section 3</a>).</td>
-<td>OPTIONAL</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-signature-claims-object"></a></p>
-<h5 id="2.2.3.2.-the-signature-claims-object">2.2.3.2. The Signature Claims Object</h5>
-<p>The <strong>Signature</strong> object contains claims related to signature validation evidence for one signature and contains the following parameters:</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>sig_ref</code></td>
-<td><strong>Object&lt;SigReference&gt;</strong></td>
-<td>Reference information identifying the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>sig_data</code></td>
-<td><strong>[Object&lt;SignedData&gt;]</strong></td>
-<td>Array of references to Signed Data signed by the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>signer_cert_ref</code></td>
-<td><strong>Object&lt;CertReference&gt;</strong></td>
-<td>Reference to signer certificate and optionally reference to a supporting certificate chain that was used to validate the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>sig_val</code></td>
-<td><strong>[Object&lt;PolicyValidation&gt;]</strong></td>
-<td>Array of results of signature validation according to defined validation procedures.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>time_val</code></td>
-<td><strong>[Object&lt;TimeValidation&gt;]</strong></td>
-<td>Array of results of time verification validating proof that the target signature has existed at specific instances of time in the past.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>ext</code></td>
-<td><strong>MAP&lt;String&gt;</strong></td>
-<td>Extension point for additional claims related to the target signature. Extension claims are added at the discretion of the SVT Issuer but MUST follow any conventions defined in a profile of this specification (see <a href="#profiles">section 3</a>).</td>
-<td>OPTIONAL</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-sigreference-claims-object"></a></p>
-<h5 id="2.2.3.3.-the-sigreference-claims-object">2.2.3.3. The SigReference Claims Object</h5>
-<p>The <strong>SigReference</strong> claims object provides information used to match the <strong>Signature</strong> claims object to a specific target signature and to verify the integrity of the target signature value and Signed Bytes.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>id</code></td>
-<td><strong>String</strong></td>
-<td>Optional identifier assigned to the target signature.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>sig_hash</code></td>
-<td><strong>Base64Binary</strong></td>
-<td>Hash value of the target signature value.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>sb_hash</code></td>
-<td><strong>Base64Binary</strong></td>
-<td>Hash value of the Signed Bytes of the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-signeddata-claims-object"></a></p>
-<h5 id="2.2.3.4.-the-signeddata-claims-object">2.2.3.4. The SignedData Claims Object</h5>
-<p>The <strong>SignedData</strong> claims object provides information used to verify the target signature references to Signed Data as well as to verify the integrity of all data signed by the target signature.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>ref</code></td>
-<td><strong>String</strong></td>
-<td>Reference identifier identifying the data or data fragment covered by the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>hash</code></td>
-<td><strong>Base64Binary</strong></td>
-<td>Hash of the data covered by the target signature.</td>
-<td>MANDATORY</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-policyvalidation-claims-object"></a></p>
-<h5 id="2.2.3.5.-the-policyvalidation-claims-object">2.2.3.5. The PolicyValidation Claims Object</h5>
-<p>The <strong>PolicyValidation</strong> claims object provide information about the result of a validation process according to a spefific policy.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>pol</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>Identifier of the policy governing the validation process.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>res</code></td>
-<td><strong>String</strong></td>
-<td>Result of the validation process. The value MUST be one of &quot;PASSED&quot;, &quot;FAILED&quot; or &quot;INDETERMINATE&quot; as defined by [<a href="#etsi319102-1">ETSI EN 319 102-1</a>].</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>msg</code></td>
-<td><strong>String</strong></td>
-<td>An optional message describing the result.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>ext</code></td>
-<td><strong>Map&lt;String&gt;</strong></td>
-<td>Extension for additional information about the validation result.</td>
-<td>OPTIONAL</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-timevalidation-claims-object"></a></p>
-<h5 id="2.2.3.6.-the-timevalidation-claims-object">2.2.3.6. The TimeValidation Claims Object</h5>
-<p>The <strong>TimeValidation</strong> claims object provide information about the result of validating time evidence asserting that the target signature existed at a particular time in the past.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>time</code></td>
-<td><strong>NumericDate</strong></td>
-<td>The verified time.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>type</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>Identifier of the type of evidence of time.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>iss</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>Identifier of the entity that issued the evidence of time.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>id</code></td>
-<td><strong>String</strong></td>
-<td>Unique identifier assigned to the evidence of time.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>val</code></td>
-<td><strong>[Object&lt;PolicyValidation&gt;]</strong></td>
-<td>Array of results of validation of the time evidence according to defined validation procedures.</td>
-<td>OPTIONAL</td>
-</tr>
-<tr>
-<td><code>ext</code></td>
-<td><strong>Map&lt;String&gt;</strong></td>
-<td>Extension for additional information about the signature validation result.</td>
-<td>OPTIONAL</td>
-</tr>
-</tbody>
-</table>
-<p><a name="the-certreference-claims-object"></a></p>
-<h5 id="2.2.3.7.-the-certreference-claims-object">2.2.3.7. The CertReference Claims Object</h5>
-<p>The <strong>CertReference</strong> claims object allows reference to a single X.509 certificate or a chain of X.509 certificates, either by providing the actual certificate data or by providing a hash reference for certificates that can be located in the target signature.</p>
-<table>
-<thead>
-<tr>
-<th>Name</th>
-<th>Data Type</th>
-<th>Value</th>
-<th>Presence</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>type</code></td>
-<td><strong>StringOrURI</strong></td>
-<td>An identifier of the type of reference provided in the <code>ref</code> claim. The type identifier MUST be either one of the identifiers defined below, an identifier specified by the selected profile, or a URI identifier.</td>
-<td>MANDATORY</td>
-</tr>
-<tr>
-<td><code>ref</code></td>
-<td><strong>[String]</strong></td>
-<td>An array of string parameters according to conventions defined by the type identifier.</td>
-<td>MANDATORY</td>
-</tr>
-</tbody>
-</table>
-<p>The following type identifiers are defined:</p>
-<table>
-<thead>
-<tr>
-<th>Identifer</th>
-<th>Ref Data Content</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>chain</code></td>
-<td>Array of Base64 encoded X.509 certificates [<a href="#rfc5280">RFC5280</a>]. The certificates MUST be stored in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array.</td>
-</tr>
-<tr>
-<td><code>chain_hash</code></td>
-<td>The ref contains an array of one or more Base64 encoded hash values where each hash value is a hash over a X.509 certificate [<a href="#rfc5280">RFC5280</a>] used to validate the signature. The certificates MUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array. This option MUST NOT be used unless all hashed certificates are present in the target electronic signature.</td>
-</tr>
-</tbody>
-</table>
-<blockquote>
-<p><strong>Note</strong>: All certificates referenced using the identifiers above are X.509 certificates. Profiles of this specification MAY define alternative types of public key containers. It should be noted however that a major function of these referenced certificates is not just to reference the public key, but also to provide the identity of the signer. It is therefore important for the full function of an SVT that the referenced public key container also provides the means to identify of the signer.</p>
-</blockquote>
-<p><a name="svt-jose-header"></a></p>
-<h4 id="2.2.4.-svt-jose-header">2.2.4. SVT JOSE Header</h4>
-<p>The SVT JWT MUST contain the following JOSE header parameters in accordance with section 5 of [<a href="#rfc7519">RFC7519</a>].</p>
-<table>
-<thead>
-<tr>
-<th>JOSE Header</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>typ</code></td>
-<td>This parameter MUST have the string value &quot;JWT&quot; (upper case).</td>
-</tr>
-<tr>
-<td><code>alg</code></td>
-<td>Specifying the algorithm used to sign the SVT JWT using a value specified in [<a href="#rfc7518">RFC7518</a>]. The specified signature hash algorithm MUST be identical to the hash algorithm specified in the <strong>SigValAssertion</strong> claims object <code>hash_algo</code> claim.</td>
-</tr>
-</tbody>
-</table>
-<p>The SVT header MUST contain a public key or a reference to a public key used to verify the signature on the SVT in accordance with [<a href="#rfc7515">RFC7515</a>]. Each profile (See section 3.) MUST define the requirements for how the key or key reference is included in the header.</p>
-<p><a name="profiles"></a></p>
-<h2 id="3.-profiles">3. Profiles</h2>
-<p>Each signed document and signature type will have to define the precise content and use of several claims in the SVT.</p>
-<p>Each profile MUST as a minimum define:</p>
-<ul class="list">
-<li>How to specify reference to Signed Data content of the signed document.</li>
-<li>How to make reference to the target signature and the Signed Bytes of the signature.</li>
-<li>How references should be made to certificates supporting each siganture.</li>
-<li>How public keys or reference to public keys supporting validation of the signed SVT is included in the SVT.</li>
-<li>Whether each signature is supported by it&#39;s own SVT, or whether one SVT may support multiple signatures of the same document.</li>
-<li>Explicit information on how to perform signature validation based on an SVT, if applicable.</li>
-<li>How to attach an SVT to a document signature or signed document, if applicable.</li>
-</ul>
-<p><a name="signature-validation-with-signature-validation-token"></a></p>
-<h2 id="4.-signature-validation-with-signature-validation-token">4. Signature Validation with Signature Validation Token</h2>
-<p>Signature validation based on an SVT SHALL follow the following basic steps:</p>
-<ol class="list">
-<li><p>Locate all available tokens available for the signed document that is relevant for the target signature.</p>
-</li>
-<li><p>Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.</p>
-</li>
-<li><p>Verify the integrity of the signature and the Signed Bytes of the target signature using the <code>sig_ref</code> claim.</p>
-</li>
-<li><p>Verify that the Signed Data reference in the original signature matches the reference values in the <code>sig_data_ref</code> claim.</p>
-</li>
-<li><p>Verify the integrity of referenced Signed Data using provided hash values in the <code>sig_data_ref</code> claim.</p>
-</li>
-<li><p>Obtain the verified certificates supporting the asserted signature validation through the <code>signer_cert_ref</code> claim.</p>
-</li>
-<li><p>Verify that signature validation policy results satisfy the requirements of the relying party.</p>
-</li>
-<li><p>Verify that verified time results satisfy the context within which the signed document is used.</p>
-</li>
-</ol>
-<p>After validating these steps, signature validity is established as well as the trusted signer certificate binding the identity of the signer to the signature.</p>
-<p><a name="examples"></a></p>
-<h2 id="5.-examples">5. Examples</h2>
-<p>The following example illustrates a basic SVT according to this specification issued for a signed PDF document.</p>
-<p>Signature validation token JWT:</p>
-<pre class="hljs"><code>eyJraWQiOiJPZW<span class="hljs-number">5</span>JKzQzNEpoYnZmRG<span class="hljs-number">50</span>ZlZcLzhyT<span class="hljs-number">3</span>hHN<span class="hljs-number">0</span>ZrdnlqYUtWSmFWcUlGQlhvaFZoQWU<span class="hljs-number">1</span>Zks<span class="hljs-number">4</span>YW<span class="hljs-number">5</span>vdjFTNjg<span class="hljs-number">4</span>
-cjdLYmFsK<span class="hljs-number">2</span>Z<span class="hljs-number">2</span>cGFIMWo<span class="hljs-number">4</span>aWJnNTJRQnkxUFE<span class="hljs-number">9</span>PSIsInR<span class="hljs-number">5</span>cCI<span class="hljs-number">6</span>IkpXVCIsImFsZyI<span class="hljs-number">6</span>IlJTNTEyIn<span class="hljs-number">0</span>.eyJhdWQiOiJodHRw
-OlwvXC<span class="hljs-number">9</span>leGFtcGxlLmNvbVwvYXVkaWVuY<span class="hljs-number">2</span>UxIiwiaXNzIjoiaHR<span class="hljs-number">0</span>cHM<span class="hljs-number">6</span>XC<span class="hljs-number">9</span>cL<span class="hljs-number">3</span>N<span class="hljs-number">3</span>ZWRlbmNvbm<span class="hljs-number">5</span>lY<span class="hljs-number">3</span>Quc<span class="hljs-number">2</span>VcL<span class="hljs-number">3</span>ZhbGlk
-YXRvciIsImlhdCI<span class="hljs-number">6</span>MTU<span class="hljs-number">4</span>MjczMDY<span class="hljs-number">0</span>NSwianRpIjoiZTIyYzViZTZkZDZjYzZkYjgzNGJjY<span class="hljs-number">2</span>QwNjZmNWUyZTMiLCJzaWdf
-dmFsX<span class="hljs-number">2</span>NsYWltcyI<span class="hljs-number">6</span>eyJzaWciOlt<span class="hljs-number">7</span>ImV<span class="hljs-number">4</span>dCI<span class="hljs-number">6</span>bnVsbCwic<span class="hljs-number">2</span>lnX<span class="hljs-number">3</span>ZhbCI<span class="hljs-number">6</span>W<span class="hljs-number">3</span>sibXNnIjoiSW<span class="hljs-number">52</span>YWxpZCBzaWduYXR<span class="hljs-number">1</span>cmUi
-LCJleHQiOm<span class="hljs-number">51</span>bGwsInJlcyI<span class="hljs-number">6</span>IkZBSUxFRCIsInBvbCI<span class="hljs-number">6</span>Imh<span class="hljs-number">0</span>dHA<span class="hljs-number">6</span>XC<span class="hljs-number">9</span>cL<span class="hljs-number">2</span>lkLnN<span class="hljs-number">3</span>ZWRlbmNvbm<span class="hljs-number">5</span>lY<span class="hljs-number">3</span>Quc<span class="hljs-number">2</span>VcL<span class="hljs-number">3</span>N<span class="hljs-number">2</span>dFwv
-<span class="hljs-keyword">c</span><span class="hljs-number">2</span>lndmFsLXBvbGljeVwvY<span class="hljs-number">2</span>hhaW<span class="hljs-number">5</span>cLzAxIn<span class="hljs-number">1</span>dLCJzaWdfcmVmIjp<span class="hljs-number">7</span>InNpZ<span class="hljs-number">19</span>oYXNoIjoiQmh<span class="hljs-number">1</span>RTlCQ<span class="hljs-number">1</span>lkcUxneW<span class="hljs-number">93</span>bDJQ
-Ym<span class="hljs-number">1</span>uSzlkSkFtaVZ<span class="hljs-number">0</span>VDF<span class="hljs-number">1</span>OVZnaUY<span class="hljs-number">5</span>OWgyaFZQekU<span class="hljs-number">0</span>WExXdmJDUGU<span class="hljs-number">0</span>YUNKM<span class="hljs-number">0</span>l<span class="hljs-number">6</span>RmZvTDlrM<span class="hljs-number">3</span>RXcjBXK<span class="hljs-number">3</span>d<span class="hljs-number">5</span>OUJlcWlyY<span class="hljs-number">1E9</span>
-PSIsImlkIjpudWxsLCJzYl<span class="hljs-number">9</span>oYXNoIjoiYnVlcTVIVE<span class="hljs-number">8</span>xYnRwQ<span class="hljs-number">3</span>JYUlg<span class="hljs-number">3</span>VHpFS<span class="hljs-number">1</span>VyTkpRaEdHOHFCaDR<span class="hljs-number">3</span>eEVTcVJMM<span class="hljs-number">0</span>J<span class="hljs-number">6</span>
-bjRjbHZLMzdqWXUwS<span class="hljs-number">2</span>pNTWtnSlFFTWZBMWIzaW<span class="hljs-number">1</span>peTc<span class="hljs-number">5</span>dDdoK<span class="hljs-number">1</span>loOHc<span class="hljs-number">9</span>PSJ<span class="hljs-number">9</span>LCJzaWduZXJfY<span class="hljs-number">2</span>VydF<span class="hljs-number">9</span>yZWYiOnsicmVm
-IjpbIk<span class="hljs-number">5</span>TdUZNXC<span class="hljs-number">92</span>SitiZUJsUXRRVHptY<span class="hljs-number">1</span>loNXg<span class="hljs-number">3</span>TDhXQzlFMUtQSFJBMWlvTk<span class="hljs-number">9</span>sS<span class="hljs-number">1</span>ZHYmxhOVVSelljc<span class="hljs-number">2</span>lzQXgyYmNz
-cU<span class="hljs-number">9</span>oa<span class="hljs-number">3</span>ZWVGMzbUs<span class="hljs-number">5</span>RTZhZzA<span class="hljs-number">3</span>aGZhdz<span class="hljs-number">09</span>Il<span class="hljs-number">0</span>sInR<span class="hljs-number">5</span>cGUiOiJjaGFpbl<span class="hljs-number">9</span>oYXNoIn<span class="hljs-number">0</span>sInNpZ<span class="hljs-number">19</span>kYXRhX<span class="hljs-number">3</span>JlZiI<span class="hljs-number">6</span>W<span class="hljs-number">3</span>sicmVm
-IjoiMCAxMjI<span class="hljs-number">5</span>MzUgMTI<span class="hljs-number">3</span>OTM<span class="hljs-number">3</span>IDI<span class="hljs-number">3</span>NDMwIiwiaGFzaCI<span class="hljs-number">6</span>Imt<span class="hljs-number">1</span>VWI<span class="hljs-number">4</span>NkZzTU<span class="hljs-number">5</span>tSmwzdjRiUUswOUZrUWd<span class="hljs-number">2</span>bzlReDAxbk<span class="hljs-number">5</span>S
-eVFLVVppaEdFdW<span class="hljs-number">1</span>kVnF<span class="hljs-number">0</span>dUJLTlBxWkkxVHpDUWV<span class="hljs-number">3</span>Nm<span class="hljs-number">44</span>b<span class="hljs-number">0</span>ZNak<span class="hljs-number">5</span>oQjhDMFhNSmxrRE<span class="hljs-number">9</span>RPT<span class="hljs-number">0</span>ifV<span class="hljs-number">0</span>sInRpbWVfdmFsIjpb
-XX<span class="hljs-number">1</span>dLCJleHQiOnsibmFtZTIiOiJ<span class="hljs-number">2</span>YWwyIiwibmFtZTEiOiJ<span class="hljs-number">2</span>YWwxIn<span class="hljs-number">0</span>sInZlciI<span class="hljs-number">6</span>IjEuMCIsInByb<span class="hljs-number">2</span>ZpbGUiOiJQREYi
-LCJoYXNoX<span class="hljs-number">2</span>FsZ<span class="hljs-number">28</span>iOiJodHRwOlwvXC<span class="hljs-number">93</span>d<span class="hljs-number">3</span>cudzMub<span class="hljs-number">3</span>JnXC<span class="hljs-number">8</span>yMDAxXC<span class="hljs-number">8</span>wNFwveG<span class="hljs-number">1</span>sZW<span class="hljs-number">5</span>jI<span class="hljs-number">3</span>NoYTUxMiJ<span class="hljs-number">9</span>fQ.DhrCRxT_U
-<span class="hljs-number">8</span>LeqK<span class="hljs-number">1</span>BU<span class="hljs-number">9</span><span class="hljs-number">-5</span>Bqu<span class="hljs-keyword">i2</span>cs<span class="hljs-number">5</span>n<span class="hljs-number">21</span>PrSqPnDtVa<span class="hljs-number">7</span>mxUtqTnouOXjVfuWR<span class="hljs-number">0</span>lfNAjEkc<span class="hljs-number">1</span>y<span class="hljs-number">2</span>QSX<span class="hljs-number">5</span><span class="hljs-keyword">x</span><span class="hljs-number">2</span>dmMdCpNLWX<span class="hljs-number">127</span>UHYiAm<span class="hljs-number">8</span>NzeY
-uoWqdnxKiy<span class="hljs-number">61</span>hZ<span class="hljs-number">1</span>l<span class="hljs-number">0</span>Jldnk<span class="hljs-number">52</span>ngG_<span class="hljs-number">2</span>UNDnrCGBo<span class="hljs-number">9</span>OgC<span class="hljs-number">90</span>kG<span class="hljs-number">2</span>bFQimZB<span class="hljs-number">3</span>WgVtE<span class="hljs-number">7</span>ad_HAwIXwd-vEHt<span class="hljs-number">6</span>Sf<span class="hljs-number">2</span>yWXlUTYqQ<span class="hljs-number">1</span>Dx
-gq<span class="hljs-number">6</span>pTKQnuf<span class="hljs-number">5</span>ahsHVyeDihgNeix<span class="hljs-number">8</span>-cGx<span class="hljs-number">1</span>MEvvHNUpCcIXBx<span class="hljs-number">67</span>BEcZ-SrqRoIZkVqEcW<span class="hljs-number">83</span>KFMgqKWmWDgp<span class="hljs-number">4</span>z_CKM<span class="hljs-number">5</span>ix<span class="hljs-number">2</span>dV
-zwp<span class="hljs-number">1</span>GvYOM<span class="hljs-number">6</span>M<span class="hljs-number">3</span>QUKYgmiNA<span class="hljs-number">6</span>dMWJvXeJZ-KK<span class="hljs-keyword">i5</span>A<span class="hljs-number">-6</span>gEqfgOsixuZechcDon_<span class="hljs-number">3</span>nMzEeNBSJFXU<span class="hljs-number">7</span>ohkvxIJN<span class="hljs-number">9</span>LXNFAxzAT<span class="hljs-number">2</span>U
-mASxrL<span class="hljs-number">9</span>wvaQMmJHYMeet-vUsOPWcsq<span class="hljs-number">07</span>eKO<span class="hljs-number">5</span>bnsYwrs<span class="hljs-number">9</span>igYeotgcT_Nl<span class="hljs-number">74</span>Rmf<span class="hljs-number">9</span>uMye_IgyzlS_NLL<span class="hljs-number">4</span>xq<span class="hljs-number">9</span>Aaf<span class="hljs-number">6</span>LPXWZ<span class="hljs-number">0</span>S
-_plugvfzv<span class="hljs-number">7</span>HuzXNOY<span class="hljs-number">994</span>voq<span class="hljs-number">8</span>sOpO<span class="hljs-number">9</span>xKYhqYnzbdDFKU</code></pre><p>Decoded JWT Header:</p>
-<pre class="hljs"><code>{
-  <span class="hljs-string">"kid"</span>:<span class="hljs-string">"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov1S688r7Kbal+fvpaH1j8ibg52QB</span>
-         y1PQ==<span class="hljs-string">",</span>
-  <span class="hljs-string">"typ"</span> : <span class="hljs-string">"JWT"</span>,
-  <span class="hljs-string">"alg"</span> : <span class="hljs-string">"RS512"</span>
-}</code></pre><p>Decoded JWT Claims:</p>
-<pre class="hljs"><code>{
-  <span class="hljs-string">"aud"</span> : <span class="hljs-string">"http://example.com/audience1"</span>,
-  <span class="hljs-string">"iss"</span> : <span class="hljs-string">"https://swedenconnect.se/validator"</span>,
-  <span class="hljs-string">"iat"</span> : <span class="hljs-number">1582730645</span>,
-  <span class="hljs-string">"jti"</span> : <span class="hljs-string">"e22c5be6dd6cc6db834bccd066f5e2e3"</span>,
-  <span class="hljs-string">"sig_val_claims"</span> : {
-    <span class="hljs-string">"sig"</span> : [ {
-      <span class="hljs-string">"ext"</span> : null,
-      <span class="hljs-string">"sig_val"</span> : [ {
-        <span class="hljs-string">"msg"</span> : <span class="hljs-string">"Invalid signature"</span>,
-        <span class="hljs-string">"ext"</span> : null,
-        <span class="hljs-string">"res"</span> : <span class="hljs-string">"FAILED"</span>,
-        <span class="hljs-string">"pol"</span> : <span class="hljs-string">"http://id.swedenconnect.se/svt/sigval-policy/chain/01"</span>
-      } ],
-      <span class="hljs-string">"sig_ref"</span> : {
-        <span class="hljs-string">"sig_hash"</span> : <span class="hljs-string">"BhuE9BCYdqLgyowl2PbmnK9dJAmiVtT1u9VgiF99h2hVPzE4XLWvbCPe4aCJ3IzFfoL9k3
-                      tWr0W+wy9BeqircQ=="</span>,
-        <span class="hljs-string">"id"</span> : null,
-        <span class="hljs-string">"sb_hash"</span> : <span class="hljs-string">"bueq5HTO1btpCrXRX7TzEKUrNJQhGG8qBh4wxESqRL3Bzn4clvK37jYu0KjMMkgJQEMfA1b
-                     3imiy79t7h+Yh8w=="</span>
-      },
-      <span class="hljs-string">"signer_cert_ref"</span> : {
-        <span class="hljs-string">"ref"</span> : [ <span class="hljs-string">"NSuFM/vJ+beBlQtQTzmcYh5x7L8WC9E1KPHRA1ioNOlKVGbla9URzYcsisAx2bcsqOhkvVTc3
-                   mK9E6ag07hfaw=="</span> ],
-        <span class="hljs-string">"type"</span> : <span class="hljs-string">"chain_hash"</span>
-      },
-      <span class="hljs-string">"sig_data_ref"</span> : [ {
-        <span class="hljs-string">"ref"</span> : <span class="hljs-string">"0 122935 127937 27430"</span>,
-        <span class="hljs-string">"hash"</span> : <span class="hljs-string">"kuUb86FsMNmJl3v4bQK09FkQgvo9Qx01nNRyQKUZihGEumdVqtuBKNPqZI1TzCQew6n8oFMjNh
-                  B8C0XMJlkDOQ=="</span>
-      } ],
-      <span class="hljs-string">"time_val"</span> : [ ]
-    } ],
-    <span class="hljs-string">"ext"</span> : {
-      <span class="hljs-string">"name2"</span> : <span class="hljs-string">"val2"</span>,
-      <span class="hljs-string">"name1"</span> : <span class="hljs-string">"val1"</span>
-    },
-    <span class="hljs-string">"ver"</span> : <span class="hljs-string">"1.0"</span>,
-    <span class="hljs-string">"profile"</span> : <span class="hljs-string">"PDF"</span>,
-    <span class="hljs-string">"hash_algo"</span> : <span class="hljs-string">"http://www.w3.org/2001/04/xmlenc#sha512"</span>
-  }
-}</code></pre><blockquote>
-<p>Note: Line breaks in the decoded example are inserted for readablilty. These are not allowed in valid JSON data.</p>
-</blockquote>
-<p><a name="normative-references"></a></p>
-<h2 id="6.-normative-references">6. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="rfc5280"></a>
-<strong>[RFC5280]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc5280.txt">D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, Internet
-X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
-Profile, May 2008</a>.</p>
-</blockquote>
-<p><a name="rfc6931"></a>
-<strong>[RFC6931]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc6931.txt">Eastlake 3rd, D., Additional XML Security Uniform Resource Identifiers
-(URIs), April 2013</a>.</p>
-</blockquote>
-<p><a name="rfc7515"></a>
-<strong>[RFC7515]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc7515.txt">Jones, M., Bradley, J., Sakimura, N., JSON Web Signature (JWS), May 2015</a>.</p>
-</blockquote>
-<p><a name="rfc7518"></a>
-<strong>[RFC7518]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc7518.txt">Jones, M., JSON Web Algorithms (JWA), May 2015</a>.</p>
-</blockquote>
-<p><a name="rfc7519"></a>
-<strong>[RFC7519]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc7518.txt">Jones, M., Bradley, J., Sakimura, N., JSON Web Token (JWT), May 2015</a>.</p>
-</blockquote>
-<p><a name="rfc8174"></a>
-<strong>[RFC8174]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc8174.txt">Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, May 2017</a>.</p>
-</blockquote>
-<p><a name="etsi319102-1"></a>
-<strong>[ETSI EN 319 102-1]</strong></p>
-<blockquote>
-<p><a href="https://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf">ETSI - Electronic Signatures and Infrastructures (ESI); Procedures for
-Creation and Validation of AdES Digital Signatures; Part 1: Creation and
-Validation</a>.</p>
-</blockquote>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/16_-_PDF_Profile_for_Signature_Validation_Tokens.html b/docs/updates/16_-_PDF_Profile_for_Signature_Validation_Tokens.html
deleted file mode 100644
index d4f8615..0000000
--- a/docs/updates/16_-_PDF_Profile_for_Signature_Validation_Tokens.html
+++ /dev/null
@@ -1,215 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>PDF Profile for Signature Validation Tokens</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="pdf-profile-for-signature-validation-tokens">PDF Profile for Signature Validation Tokens</h1>
-<h3 id="version-1.0---2020-12-16---*draft-version*">Version 1.0 - 2020-12-16 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2020-61</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2020. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#definitions">Definitions</a></p>
-</li>
-<li><p><a href="#svt-in-pdf-documents"><strong>SVT in PDF Documents</strong></a></p>
-<p> 2.1. <a href="#svt-extension-to-timestamp-tokens">SVT Extension to Timestamp Tokens</a></p>
-</li>
-<li><p><a href="#svt-claims"><strong>SVT Claims</strong></a></p>
-<p> 3.1. <a href="#signature-reference-data">Signature Reference Data</a></p>
-<p> 3.2. <a href="#signed-data-reference-data">Signed Data Reference Data</a></p>
-<p> 3.3. <a href="#signer-certificate-references">Signer Certificate References</a></p>
-</li>
-<li><p><a href="#jose-header"><strong>JOSE Header</strong></a></p>
-<p> 4.1. <a href="#svt-signing-key-reference">SVT Signing Key Reference</a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>The &quot;Signature Validation Token&quot; specification [<a href="#svt">SVT</a>] defines a basic token to support signature validation in a way that can significantly extend the lifetime of a signature.</p>
-<p>This specification defines a profile for implementing SVT with a signed PDF document, and defines the following aspects of SVT usage:</p>
-<ul class="list">
-<li>How to include reference data related to PDF signatures and PDF documents in an SVT.</li>
-<li>How to add an SVT token to a PDF document.</li>
-</ul>
-<p>PDF document signatures are added as incremental updates to the signed PDF document and signs all data of the PDF document up until the current signature. When more than one signature is added to a PDF document the previous signature is signed by the next signature and can not be updated with additional data after this event.</p>
-<p>To minimize the impact on PDF documents with multiple signatures and to stay backwards compatible with PDF software that do not understand SVT, PDF documents add one SVT token for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as an incremental update. This SVT covers all signatures of the signed SVT.</p>
-<p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>, <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>, <strong>MAY</strong>, and <strong>OPTIONAL</strong> in this document are to be interpreted as described in BCP 14 [<a href="#rfc2119">RFC2119</a>] [<a href="#rfc8174">RFC8174</a>] when, and only when, they appear in all capitals, as shown here.</p>
-<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="definitions"></a></p>
-<h3 id="1.2.-definitions">1.2. Definitions</h3>
-<p>The definitions in [<a href="#svt">SVT</a>] apply also to this document.</p>
-<p><a name="svt-in-pdf-documents"></a></p>
-<h2 id="2.-svt-in-pdf-documents">2. SVT in PDF Documents</h2>
-<p>An SVT added to a signed PDF document SHALL be added to a document timestamp accordance with ISO 32000-2:2017 [<a href="pdf">PDF</a>].</p>
-<p>The document timestamp contains an RFC 3161 timestamp token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT SHALL be added to the timestamp token (TSTInfo) as an Extension object as defined in <a href="#svt-extension-to-timestamp-tokens">section 2.1</a>.</p>
-<p><a name="svt-extension-to-timestamp-tokens"></a></p>
-<h3 id="2.1.-svt-extension-to-timestamp-tokens">2.1. SVT Extension to Timestamp Tokens</h3>
-<p>The SVT extension is an Extension suitable to be included in TSTInfo as defined by [<a href="rfc3161">RFC3161</a>]<sup>*</sup>.</p>
-<p>The SVT extension is identified by the Object Identifier (OID) <code>1.2.752.201.5.2</code> as defined in [<a href="eidregistry">EidRegistry</a>].</p>
-<p>This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as a UTF-8 encoded string.</p>
-<p>This extension SHALL NOT be marked critical.</p>
-<blockquote>
-<p>[*]: Extensions in timestamp tokens according to [<a href="rfc3161">RFC3161</a>] are imported from the definition of the X.509 certificate extensions defined in [<a href="rfc5280">RFC5280</a>].</p>
-</blockquote>
-<p><a name="svt-claims"></a></p>
-<h2 id="3.-svt-claims">3. SVT Claims</h2>
-<p><a name="signature-reference-data"></a></p>
-<h3 id="3.1.-signature-reference-data">3.1. Signature Reference Data</h3>
-<p>The SVT SHALL contain a <strong>SigReference</strong> claims object that SHALL contain the following data:</p>
-<table>
-<thead>
-<tr>
-<th>Claim</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>id</code></td>
-<td>Absent or a <strong>Null</strong> value.</td>
-</tr>
-<tr>
-<td><code>sig_hash</code></td>
-<td>The hash over the signature value bytes.</td>
-</tr>
-<tr>
-<td><code>sb_hash</code></td>
-<td>The hash over the DER encoded <code>SignedAttributes</code> in <code>SignerInfo</code>.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="signed-data-reference-data"></a></p>
-<h3 id="3.2.-signed-data-reference-data">3.2. Signed Data Reference Data</h3>
-<p>An SVT according to this profile SHALL contain exactly one instance of the <strong>SignedData</strong> claims object. The <strong>SignedData</strong> claims object shall contain the following data:</p>
-<table>
-<thead>
-<tr>
-<th>Claim</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>ref</code></td>
-<td>The string representation of the <strong>ByteRange</strong> value of the PDF signature dictionary of the target signature. This is a sequence of integers separated by space where each integer pair specifies the start index and length of a byte range.</td>
-</tr>
-<tr>
-<td><code>hash</code></td>
-<td>The hash of all bytes identified by the <strong>ByteRange</strong> value. This is the concatenation of all byte ranges identified by the <strong>ByteRange</strong> value.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="signer-certificate-references"></a></p>
-<h3 id="3.3.-signer-certificate-references">3.3. Signer Certificate References</h3>
-<p>The SVT SHALL contain a <strong>CertReference</strong> claims object. The <code>type</code> claim of the <strong>CertReference</strong> claims object SHALL be either <code>cert</code>, <code>chain</code>, <code>cert_hash</code> or <code>cert_and_chain_hash</code>.</p>
-<ul class="list">
-<li>The <code>chain</code> type SHALL be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.</li>
-<li>The <code>chain_hash</code> type SHALL be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.</li>
-</ul>
-<p><strong>Note:</strong> The <code>cert</code> type MUST NOT be used with a PAdES signatures (SubFiler in the signature dictionary is set to &quot;ETSI.CAdES.detached&quot;) where the signing certificate in the target signature is bound to the signature through ESSCertID or ESSCertIDv2 [<a href="rfc55035">RFC5035</a>].</p>
-<p><a name="jose-header"></a></p>
-<h2 id="4.-jose-header">4. JOSE Header</h2>
-<p><a name="svt-signing-key-reference"></a></p>
-<h3 id="4.1.-svt-signing-key-reference">4.1. SVT Signing Key Reference</h3>
-<p>The SVT JOSE header must contain one of the following header parameters in accordance with [<a href="#rfc7515">RFC7515</a>], for storing a reference to the public key used to verify the signature on the SVT:</p>
-<table>
-<thead>
-<tr>
-<th>Header Parameter</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>x5c</code></td>
-<td>Holds an X.509 certificate [<a href="#rfc5280">RFC5280</a>] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain.</td>
-</tr>
-<tr>
-<td><code>kid</code></td>
-<td>A key identifier holding the Base64 encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT as specified by the <code>alg</code> header parameter. The referenced certificate SHOULD be the same certificate that was used to sign the document timestamp that contains the SVT.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="normative-references"></a></p>
-<h2 id="5.-normative-references">5. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="rfc3161"></a>
-<strong>[RFC3161]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc3161.txt">Adams, C., Cain, P., Pinkas, D., Zuccherato, R., Internet X.509 Public Key
-Infrastructure Time-Stamp Protocol (TSP), August 2001</a>.</p>
-</blockquote>
-<p><a name="rfc5280"></a>
-<strong>[RFC5280]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc5280.txt">D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, Internet
-X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
-Profile, May 2008</a>.</p>
-</blockquote>
-<p><a name="rfc5035"></a>
-<strong>[RFC5035]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc5035.txt">Shaad, J., Enhanced Security Services (ESS) Update: Adding CertID Algorithm
-Agility, August 2007</a>.</p>
-</blockquote>
-<p><a name="rfc7515"></a>
-<strong>[RFC7515]</strong></p>
-<blockquote>
-<p><a href="https://www.ietf.org/rfc/rfc7515.txt">Jones, M., Bradley, J., Sakimura, N., JSON Web Signature (JWS), May 2015</a>.</p>
-</blockquote>
-<p><a name="rfc8174"></a>
-<strong>[RFC8174]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc8174.txt">Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,
-May 2017</a>.</p>
-</blockquote>
-<p><a name="pdf"></a>
-<strong>[PDF]</strong></p>
-<blockquote>
-<p><a href="https://www.iso.org/obp/ui/#iso:std:iso:32000:-2:ed-1:v1:en">ISO 32000-2:2017, Document management - Portable Document Format - Part 2:
-PDF 2.0, July 2017</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="svt"></a>
-<strong>[SVT]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/updates/15_-_Signature_Validation%_Token.html">Signature Validation Token</a>.</p>
-</blockquote>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/17_-_XML_Profile_for_Signature_Validation_Tokens.html b/docs/updates/17_-_XML_Profile_for_Signature_Validation_Tokens.html
deleted file mode 100644
index 12d1a52..0000000
--- a/docs/updates/17_-_XML_Profile_for_Signature_Validation_Tokens.html
+++ /dev/null
@@ -1,247 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>XML Profile for Signature Validation Tokens</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="xml-profile-for-signature-validation-tokens">XML Profile for Signature Validation Tokens</h1>
-<h3 id="version-1.0---2020-12-16---*draft-version*">Version 1.0 - 2020-12-16 - <em>Draft version</em></h3>
-<p>Registration number: <strong>2020-62</strong></p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2015-2020. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#definitions">Definitions</a></p>
-<p> 1.2. <a href="#notation">Notation</a></p>
-<p> 1.2.1 <a href="#references-to-xml-elements-from-xml-schemas">References to XML Elements from XML Schemas</a></p>
-</li>
-<li><p><a href="#svt-in-xml-documents"><strong>SVT in XML Documents</strong></a></p>
-<p> 2.1.1. <a href="#signaturevalidationtoken-signature-property">SignatureValidationToken Signature Property</a></p>
-<p> 2.1.2. <a href="#multiple-svt-tokens">Multiple SVT in a signature</a></p>
-</li>
-<li><p><a href="#svt-claims"><strong>SVT Claims</strong></a></p>
-<p> 3.1. <a href="#signature-reference-data">Signature Reference Data</a></p>
-<p> 3.2. <a href="#signed-data-reference-data">Signed Data Reference Data</a></p>
-<p> 3.3. <a href="#signer-certificate-references">Signer Certificate References</a></p>
-</li>
-<li><p><a href="#jose-header"><strong>JOSE Header</strong></a></p>
-<p> 4.1. <a href="#svt-signing-key-reference">SVT Signing Key Reference</a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-</ol>
-<hr>
-<p><a name="introduction"></a></p>
-<h2 id="1.-introduction">1. Introduction</h2>
-<p>The &quot;Signature Validation Token&quot; specification [<a href="#svt">SVT</a>] defines the basic token to support signature validation in a way that can significantly extend the lifetime of a signature.</p>
-<p>This specification defines a profile for implementing SVT with a signed XML document, and defines the following aspects of SVT usage:</p>
-<ul class="list">
-<li>How to include reference data related to XML signatures and XML documents in an SVT.</li>
-<li>How to add an SVT token to a XML signature.</li>
-</ul>
-<p>XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be included in the signed XML document (enveloped), include the signed data (enveloping) or may be separate from the signed content (detached).</p>
-<p>To provide a generic solution for any type of XML signature an SVT is added to each XML signature element within the XML signature <code>&lt;ds:Object&gt;</code> element.</p>
-<p><a name="requirements-notation"></a></p>
-<h3 id="1.1.-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>, <strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>, <strong>MAY</strong>, and <strong>OPTIONAL</strong> in this document are to be interpreted as described in BCP 14 [<a href="#rfc2119">RFC2119</a>] [<a href="#rfc8174">RFC8174</a>] when, and only when, they appear in all capitals, as shown here.</p>
-<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="definitions"></a></p>
-<h3 id="1.2.-definitions">1.2. Definitions</h3>
-<p>The definitions in [<a href="#svt">SVT</a>] apply also to this document.</p>
-<p><a name="notation"></a></p>
-<h3 id="1.2.-notation">1.2. Notation</h3>
-<p><a name="references-to-xml-elements-from-xml-schemas"></a></p>
-<h4 id="1.2.1-references-to-xml-elements-from-xml-schemas">1.2.1 References to XML Elements from XML Schemas</h4>
-<p>When referring to elements from the W3C XML Signature namespace
-(<code>http://www.w3.org/2000/09/xmldsig\#</code>) the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;ds:Signature&gt;</code></li>
-</ul>
-<p>When referring to elements from the ETSI XAdES XML Signature namespace
-(<code>http://uri.etsi.org/01903/v1.3.2#</code>) the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;xades:CertDigest&gt;</code></li>
-</ul>
-<p>When referring to elements defined in this specification
-(<code>http://id.swedenconnect.se/svt/1.0/sig-prop/ns</code>) the following syntax is used:</p>
-<ul class="list">
-<li><code>&lt;svt:Element&gt;</code></li>
-</ul>
-<p><a name="svt-in-xml-documents"></a></p>
-<h2 id="2.-svt-in-xml-documents">2. SVT in XML Documents</h2>
-<p>When SVT is provided for XML signatures then one SVT SHALL be provided for each XML signature.</p>
-<p>An SVT embedded within the XML signature element SHALL be placed in a  <code>&lt;svt:SignatureValidationToken&gt;</code> element as defined in <a href="#signaturevalidationtoken-signature-property">section 2.1.1</a>.</p>
-<p><a name="signaturevalidationtoken-signature-property"></a></p>
-<h3 id="2.1.1.-signaturevalidationtoken-signature-property">2.1.1. SignatureValidationToken Signature Property</h3>
-<p>The <code>&lt;svt:SignatureValidationToken&gt;</code> element SHALL be placed in a <code>&lt;ds:SignatureProperty&gt;</code> element in accordance with [<a href="#xmldsig">XMLDsig</a>]. The <code>&lt;ds:SignatureProperty&gt;</code> element SHALL be placed inside a <code>&lt;ds:SignatureProperties&gt;</code> element inside a <code>&lt;ds:Object&gt;</code> element inside a <code>&lt;ds:Signature&gt;</code> element.</p>
-<p><strong>Note</strong>: [<a href="#xmldsig">XMLDsig</a>] requires the <code>Target</code> attribute to be present in <code>&lt;ds:SignatureProperty&gt;</code>, referencing the signature targeted by this signature property. If an SVT is added to a signature that do not have an <code>Id</code> attribute, implementations SHOULD add an <code>Id</code> attribute to the <code>&lt;ds:Signature&gt;</code> element and reference that <code>Id</code> in the <code>Target</code> attribute. This <code>Id</code> attribute and <code>Target</code> attribute value matching is required by the [<a href="#xmldsig">XMLDsig</a>] standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications SHOULD not reject an SVT token because of <code>Id</code> and <code>Target</code> attribute mismatch, and MUST rely on matching against signature using signed information in the SVT itself.</p>
-<p>The <code>&lt;svt:SignatureValidationToken&gt;</code> element is defined by the following XML Schema:</p>
-<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">"1.0"</span> encoding=<span class="hljs-string">"UTF-8"</span>?&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">"http://www.w3.org/2001/XMLSchema"</span> elementFormDefault=<span class="hljs-string">"qualified"</span>
-    targetNamespace=<span class="hljs-string">"http://id.swedenconnect.se/svt/1.0/sig-prop/ns"</span>
-    xmln<span class="hljs-variable">s:svt</span>=<span class="hljs-string">"http://id.swedenconnect.se/svt/1.0/sig-prop/ns"</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">"SignatureValidationToken"</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">"svt:SignatureValidationTokenType"</span> /&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">"SignatureValidationTokenType"</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">"xs:string"</span>&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p>The SVT token SHALL be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT MUST NOT be represented by the Base64 encoded bytes of the JWT string.</p>
-<p>Example:</p>
-<pre class="hljs"><code>&lt;d<span class="hljs-variable">s:Signature</span> Id=<span class="hljs-string">"MySignatureId"</span>&gt;
-  ...
-  &lt;d<span class="hljs-variable">s:Object</span>&gt;
-    &lt;d<span class="hljs-variable">s:SignatureProperties</span>&gt;
-      &lt;d<span class="hljs-variable">s:SignatureProperty</span> Target=<span class="hljs-string">"#MySignatureId"</span>&gt;
-        &lt;<span class="hljs-keyword">sv</span><span class="hljs-variable">t:SignatureValidationToken</span>&gt;
-              eyJ0eXAiOiJKV1QiLCJhb...<span class="hljs-number">2</span>aNZ
-        &lt;/<span class="hljs-keyword">sv</span><span class="hljs-variable">t:SignatureValidationToken</span>&gt;
-      &lt;/d<span class="hljs-variable">s:SignatureProperty</span>&gt;
-    &lt;/d<span class="hljs-variable">s:SignatureProperties</span>&gt;
-  &lt;/d<span class="hljs-variable">s:Object</span>&gt;
-&lt;/d<span class="hljs-variable">s:Signature</span>&gt;</code></pre><p><a name="multiple-svt-tokens"></a></p>
-<h3 id="2.1.2-multiple-svt-in-a-signature">2.1.2 Multiple SVT in a signature</h3>
-<p>If a new SVT is stored in a signature which already contains a previously issued SVT, implementations can choose to either replace the existing SVT or to store the new SVT in addition to the existing SVT.</p>
-<p>If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a new <code>&lt;ds:SignatureProperty&gt;</code> element inside the existing <code>&lt;ds:SignatureProperties&gt;</code> element where the old SVT is located.</p>
-<p>For interoperability robustness, signature validation applications MUST be able to handle signatures where the new SVT is located in a new <code>&lt;ds:Object&gt;</code> element.</p>
-<p><a name="svt-claims"></a></p>
-<h2 id="3.-svt-claims">3. SVT Claims</h2>
-<p><a name="signature-reference-data"></a></p>
-<h3 id="3.1.-signature-reference-data">3.1. Signature Reference Data</h3>
-<p>The SVT SHALL contain a <strong>SigReference</strong> claims object that SHALL contain the following data:</p>
-<table>
-<thead>
-<tr>
-<th>Claim</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>id</code></td>
-<td>The Id-attribute of the XML signature, if present.</td>
-</tr>
-<tr>
-<td><code>sig_hash</code></td>
-<td>The hash over the signature value bytes.</td>
-</tr>
-<tr>
-<td><code>sb_hash</code></td>
-<td>The hash over the canonicalized <code>&lt;ds:SignedInfo&gt;</code> element (the bytes the XML signature algorithm has signed to generated the signature value).</td>
-</tr>
-</tbody>
-</table>
-<p><a name="signed-data-reference-data"></a></p>
-<h3 id="3.2.-signed-data-reference-data">3.2. Signed Data Reference Data</h3>
-<p>An SVT according to this profile SHALL contain one instance of the <strong>SignedData</strong> claims object for each <code>&lt;ds:Reference&gt;</code> element in the <code>&lt;ds:SignedInfo&gt;</code> element. The <strong>SignedData</strong> claims object shall contain the following data:</p>
-<table>
-<thead>
-<tr>
-<th>Claim</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>ref</code></td>
-<td>The value of the URI attribute of the corresponding <code>&lt;ds:Reference&gt;</code> element.</td>
-</tr>
-<tr>
-<td><code>hash</code></td>
-<td>The hash of all bytes identified corresponding <code>&lt;ds:Reference&gt;</code> element after applying all identified canonicalization and transformation algorithms. These are the same bytes that is hashed by the hash value in the <code>&lt;ds:DigestValue&gt;</code> element inside the <code>&lt;ds:Reference&gt;</code> element.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="signer-certificate-references"></a></p>
-<h3 id="3.3.-signer-certificate-references">3.3. Signer Certificate References</h3>
-<p>The SVT SHALL contain a <strong>CertReference</strong> claims object. The <code>type</code> claim of the <strong>CertReference</strong> claims object SHALL be either <code>chain</code> or <code>chain_hash</code>.</p>
-<ul class="list">
-<li>The <code>chain</code> type SHALL be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.</li>
-<li>The <code>chain_hash</code> type SHALL be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.</li>
-</ul>
-<p><a name="jose-header"></a></p>
-<h2 id="4.-jose-header">4. JOSE Header</h2>
-<p><a name="svt-signing-key-reference"></a></p>
-<h3 id="4.1.-svt-signing-key-reference">4.1. SVT Signing Key Reference</h3>
-<p>The SVT JOSE header MUST contain one of the following header parameters in accordance with [<a href="#rfc7515">RFC7515</a>], for storing a reference to the public key used to verify the signature on the SVT:</p>
-<table>
-<thead>
-<tr>
-<th>Header Parameter</th>
-<th>Value</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>x5c</code></td>
-<td>Holds an X.509 certificate [<a href="#rfc5280">RFC5280</a>] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain.</td>
-</tr>
-<tr>
-<td><code>kid</code></td>
-<td>A key identifier holding the Base64 encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT as specified by the <code>alg</code> header parameter.</td>
-</tr>
-</tbody>
-</table>
-<p><a name="normative-references"></a></p>
-<h2 id="5.-normative-references">5. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="rfc5280"></a>
-<strong>[RFC5280]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc5280.txt">D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, Internet
-X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
-Profile, May 2008</a>.</p>
-</blockquote>
-<p><a name="rfc8174"></a>
-<strong>[RFC8174]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc8174.txt">Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,
-May 2017</a>.</p>
-</blockquote>
-<p><a name="xmldsig"></a>
-<strong>[XMLDsig]</strong></p>
-<blockquote>
-<p><a href="https://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/">XML Signature Syntax and Processing Version 1.1 - W3C Recommendation 11
-April 2013</a>.</p>
-</blockquote>
-<p><a name="eidregistry"></a>
-<strong>[EidRegistry]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html">Swedish eID Framework - Registry for identifiers</a>.</p>
-</blockquote>
-<p><a name="svt"></a>
-<strong>[SVT]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/updates/15_-_Signature_Validation%_Token.html">Signature Validation Token</a>.</p>
-</blockquote>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html b/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
deleted file mode 100644
index 78bbaf5..0000000
--- a/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
+++ /dev/null
@@ -1,220 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <meta charset="utf-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1">
-    <title>User Message Extension in SAML Authentication Requests</title>
-    <link type="text/css" rel="stylesheet" href="assets/css/github-markdown.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/pilcrow.css">
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-portrait.css" media="print" >
-    <link type="text/css" rel="stylesheet" href="assets/css/eln-custom.css" media="print" >
-  </head>
-  <body>
-    <article class="markdown-body"><p>
-<img align="left" src="img/sweden-connect.png"></img>
-<img align="right" src="img/digg_centered.png"></img>
-</p>
-<p>
-<img align="center" src="img/transparent.png"></img>
-</p>
-
-<h1 id="user-message-extension-in-saml-authentication-requests">User Message Extension in SAML Authentication Requests</h1>
-<h3 id="version-10---2024-04-15---draft-version">Version 1.0 - 2024-04-15 - <em>Draft version</em></h3>
-<p>Registration number: TBD</p>
-<hr>
-<p class="copyright-statement">
-Copyright &copy; <a href="https://www.digg.se">The Swedish Agency for Digital Government (DIGG)</a>, 2024. All Rights Reserved.
-</p>
-
-<h2 id="table-of-contents">Table of Contents</h2>
-<ol class="list">
-<li><p><a href="#introduction"><strong>Introduction</strong></a></p>
-<p> 1.1. <a href="#requirements-notation">Requirements Notation</a></p>
-<p> 1.2. <a href="#xml-namespace-references">XML Namespace References</a></p>
-<p> 1.3. <a href="#structure">Structure</a></p>
-</li>
-<li><p><a href="#data-elements"><strong>Data elements</strong></a></p>
-</li>
-<li><p><a href="#usage-requirements"><strong>Usage Requirements</strong></a></p>
-<p> 3.1. <a href="#identity-provider-requirements">Identity Provider Requirements</a></p>
-<p> 3.2. <a href="#service-provider-requirements">Service Provider Requirements</a></p>
-</li>
-<li><p><a href="#examples"><strong>Examples</strong></a></p>
-</li>
-<li><p><a href="#schemas"><strong>Schemas</strong></a></p>
-</li>
-<li><p><a href="#normative-references"><strong>Normative References</strong></a></p>
-</li>
-<li><p><a href="#changes-between-versions"><strong>Changes between versions</strong></a></p>
-</li>
-</ol>
-<p><a name="introduction"></a></p>
-<h2 id="1-introduction">1. Introduction</h2>
-<p>When a Service Provider requests authentication of a user, the Service Provider may want to pass a message along for the user to see during the authentication phase at the Identity Provider. Normally, an Identity Provider displays information about the requesting Service Provider for the user based on the registered presentation data from the SP&#39;s SAML metadata entry. This information is static and its purpose is to show for the user that he or she is still in the context of the Service Provider.</p>
-<p>By using dynamic user messages to be displayed at the Identity Provider side (possibly in an authentication device such as a mobile phone), the Service Provider may further strengthen the coupling to its current context. Examples of messages can be information about the purpose of the authentication or warnings and prompts for the user to not authenticate based on another person&#39;s request. </p>
-<p>This specification defines the <code>&lt;umsg:UserMessage&gt;</code> element that may be included in the <code>&lt;saml2p:Extensions&gt;</code> element of a SAML <code>&lt;saml2p:AuthnRequest&gt;</code> where the requesting Service Provider can specify a message text that is to be displayed by the Identity Provider during the user authentication process.</p>
-<p><a name="requirements-notation"></a></p>
-<h3 id="11-requirements-notation">1.1. Requirements Notation</h3>
-<p>The key words <strong>MUST</strong>, <strong>MUST</strong> <strong>NOT</strong>, <strong>REQUIRED</strong>, <strong>SHALL</strong>,
-<strong>SHALL</strong> <strong>NOT</strong>, <strong>SHOULD</strong>, <strong>SHOULD</strong> <strong>NOT</strong>, <strong>RECOMMENDED</strong>,
-<strong>MAY</strong>, and <strong>OPTIONAL</strong> are to be interpreted as described in
-[<a href="#rfc2119">RFC2119</a>].</p>
-<p>These keywords are capitalized when used to unambiguously specify requirements over protocol features and behaviour that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.</p>
-<p><a name="xml-namespace-references"></a></p>
-<h3 id="12-xml-namespace-references">1.2. XML Namespace References</h3>
-<p>The prefix <strong>umsg:</strong> stands for the User Message Extension XML schema namespace <code>http://id.swedenconnect.se/authn/1.0/user-message/ns</code>. </p>
-<p>The prefix <strong>saml2:</strong> stands for the OASIS SAML 2 Assertion schema namespace <code>urn:oasis:names:tc:SAML:2.0:assertion</code>.</p>
-<p>The prefix <strong>saml2p:</strong> stands for the OASIS SAML 2 Protocol schema namespace <code>urn:oasis:names:tc:SAML:2.0:protocol</code>.</p>
-<p>The prefix <strong>md:</strong> stands for the OASIS SAML 2 Metadata schema namespace <code>urn:oasis:names:tc:SAML:2.0:metadata</code>.</p>
-<p><a name="structure"></a></p>
-<h3 id="13-structure">1.3. Structure</h3>
-<p>This specification uses the following typographical conventions in text:
-<code>&lt;LocalElement&gt;</code>, <code>&lt;ns:ForeignElement&gt;</code>, <code>Attribute</code>, <strong>Datatype</strong>,
-<code>OtherCode</code>.</p>
-<p><a name="data-elements"></a></p>
-<h2 id="2-data-elements">2. Data elements</h2>
-<p>This specification defines the element <code>&lt;UserMessage&gt;</code> to be included in the <code>&lt;Extensions&gt;</code> element of an <code>AuthnRequest</code>. </p>
-<p>This element MAY included by a Service Provider asking the Identity Provider to display a given message for the user during the authentication phase. The element has the following elements and attributes:</p>
-<p><code>&lt;Message&gt;</code> [One or more]</p>
-<blockquote>
-<p>Element that holds the user message for a specific language. See below.</p>
-</blockquote>
-<p><code>mimeType</code></p>
-<blockquote>
-<p>The MIME type for the text contained in all <code>Message</code> elements. This specification defines two possible values that are <code>text/plain</code> (where ;charset=UTF-8 is an implicit condition) and <code>text/markdown</code><sup>1</sup>. If no value is given for this field, <code>text/plain</code> MUST be assumed. Other profiles MAY add support for additional MIME types.</p>
-</blockquote>
-<p>The following schema fragment defines the <code>&lt;UserMessage&gt;</code> element:</p>
-<pre class="hljs"><code>&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;UserMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:UserMessageType&quot;</span>/&gt;
-
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;UserMessageType&quot;</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:MessageType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span>/&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;mimeType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> default=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;The format of the user message(s)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;</code></pre><p>The <code>&lt;Message&gt;</code> element is defined by the following schema definition:</p>
-<pre class="hljs"><code><span class="hljs-tag">&lt;<span class="hljs-name">xs:complexType</span> <span class="hljs-attr">name</span>=<span class="hljs-string">&quot;MessageType&quot;</span>&gt;</span>
-  <span class="hljs-tag">&lt;<span class="hljs-name">xs:simpleContent</span>&gt;</span>
-    <span class="hljs-tag">&lt;<span class="hljs-name">xs:extension</span> <span class="hljs-attr">base</span>=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">xs:attribute</span> <span class="hljs-attr">ref</span>=<span class="hljs-string">&quot;xml:lang&quot;</span> <span class="hljs-attr">use</span>=<span class="hljs-string">&quot;required&quot;</span>/&gt;</span>
-      <span class="hljs-tag">&lt;<span class="hljs-name">xs:anyAttribute</span> <span class="hljs-attr">namespace</span>=<span class="hljs-string">&quot;##any&quot;</span> <span class="hljs-attr">processContents</span>=<span class="hljs-string">&quot;lax&quot;</span>/&gt;</span>
-    <span class="hljs-tag">&lt;/<span class="hljs-name">xs:extension</span>&gt;</span>
-  <span class="hljs-tag">&lt;/<span class="hljs-name">xs:simpleContent</span>&gt;</span>
-<span class="hljs-tag">&lt;/<span class="hljs-name">xs:complexType</span>&gt;</span></code></pre><p>The <code>&lt;Message&gt;</code> element contains the Base64-encoding of the UTF-8 string holding the message to display to the user for a specific language.</p>
-<p>The required <code>xml:lang</code> attribute contains the language tag for the message&#39;s language according to [<a href="#bcp47">BCP47</a>].</p>
-<blockquote>
-<p><strong>[1]</strong>: The Markdown dialect, and potential restrictions for tags, is not regulated in this specification. However, the Markdown SHOULD NOT contain HTML-tags for security reasons.</p>
-</blockquote>
-<p><a name="usage-requirements"></a></p>
-<h2 id="3-usage-requirements">3. Usage Requirements</h2>
-<p><a name="identity-provider-requirements"></a></p>
-<h3 id="31-identity-provider-requirements">3.1. Identity Provider Requirements</h3>
-<p>An Identity Provider that supports the <code>&lt;umsg:UserMessage&gt;</code> extension MUST declare this support in its metadata entry by declaring the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category (see section 6.3 of [<a href="#eidentcat">EidEntCat</a>]).</p>
-<p>Identity Providers compliant with this specification MUST support the <code>text/plain</code> and <code>text/markdown</code> MIME types.</p>
-<p>An OpenID Provider MUST NOT display a user message unless the user is being authenticated. Thus, if the <code>IsPassive</code>-flag of the authentication request is set to <code>true</code>, the Identity Provider MUST NOT display the user message.</p>
-<p>An Identity Provider that receives a <code>&lt;umsg:UserMessage&gt;</code> extension containing user messages in several languages SHOULD display the message that best matches the user&#39;s current locale at the Identity Provider. If no message matches the user&#39;s current locale, the Identity Provider SHOULD select the first message from the list.</p>
-<p>An Identity Provider MUST refuse to display a message if it does not support a given MIME type. It MAY respond with an error if a non-supported MIME type is received.</p>
-<p>Should a message contain illegal characters, or any other constructs not accepted by the Identity Provider, the Identity Provider MAY choose not to display the message, or filter the message before displaying it.</p>
-<p>The Identity Provider MUST be able to handle messages containing line breaks.</p>
-<p><a name="service-provider-requirements"></a></p>
-<h3 id="32-service-provider-requirements">3.2. Service Provider Requirements</h3>
-<p>A Service Provider SHOULD check whether an Identity Provider supports the <code>&lt;umsg:UserMessage&gt;</code> extension before including it in a <code>&lt;saml2p:AuthnRequest&gt;</code> element. This is done by checking the Identity Provider metadata entry for the presence of the <code>http://id.swedenconnect.se/general-ec/1.0/supports-user-message</code> entity category (see <a href="#identity-provider-requirements">3.1</a> above).</p>
-<p>A Service Provider MUST NOT supply user messages that contains integrity sensitive information. The message will be displayed for the user <strong>before</strong> he or she is authenticated.</p>
-<p><a name="examples"></a></p>
-<h2 id="4-examples">4. Examples</h2>
-<p>Example of supplying a user message in Swedish (&quot;Jag vill logga in till example.com&quot;) and in
-English (&quot;I wish to login to example.com&quot;):</p>
-<pre class="hljs"><code>...
-&lt;saml2p:Extensions&gt;
-  &lt;ums<span class="hljs-variable">g:UserMessage</span> xmln<span class="hljs-variable">s:umsg</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>
-                    mimeType=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
-    &lt;ums<span class="hljs-variable">g:Message</span> <span class="hljs-keyword">xm</span><span class="hljs-variable">l:lang</span>=<span class="hljs-string">&quot;sv&quot;</span>&gt;
-      SmFnIHZpbGwgbG9nZ2EgaW4gdGlsbCBleGFtcGxlLmNvbQ==
-    &lt;/ums<span class="hljs-variable">g:Message</span>&gt;
-    &lt;ums<span class="hljs-variable">g:Message</span> <span class="hljs-keyword">xm</span><span class="hljs-variable">l:lang</span>=<span class="hljs-string">&quot;en&quot;</span>&gt;
-      SSB3aXNoIHRvIGxvZ2luIHRvIGV4YW1wbGUuY29t
-    &lt;/ums<span class="hljs-variable">g:Message</span>&gt;
-  &lt;/ums<span class="hljs-variable">g:UserMessage</span>&gt;
-&lt;/saml2p:Extensions&gt;
-...</code></pre><p><a name="schemas"></a></p>
-<h2 id="5-schemas">5. Schemas</h2>
-<p>The following XML schema defines the <code>http://id.swedenconnect.se/authn/1.0/user-message/ns</code> namespace:</p>
-<pre class="hljs"><code>&lt;?xml <span class="hljs-keyword">version</span>=<span class="hljs-string">&quot;1.0&quot;</span> encoding=<span class="hljs-string">&quot;UTF-8&quot;</span>?&gt;
-&lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span> xmln<span class="hljs-variable">s:xs</span>=<span class="hljs-string">&quot;http://www.w3.org/2001/XMLSchema&quot;</span> elementFormDefault=<span class="hljs-string">&quot;qualified&quot;</span>
-           targetNamespace=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>
-           xmln<span class="hljs-variable">s:umsg</span>=<span class="hljs-string">&quot;http://id.swedenconnect.se/authn/1.0/user-message/ns&quot;</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:import</span> namespace=<span class="hljs-string">&quot;http://www.w3.org/XML/1998/namespace&quot;</span> schemaLocation=<span class="hljs-string">&quot;http://www.w3.org/2001/xml.xsd&quot;</span>/&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-      Schema location URL: http<span class="hljs-variable">s:</span>//docs.swedenconnect.<span class="hljs-keyword">se</span>/schemas/authn/<span class="hljs-number">1.0</span>/UserMessage-<span class="hljs-number">1.0</span>.xsd
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;UserMessage&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:UserMessageType&quot;</span>/&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;UserMessageType&quot;</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;List of user <span class="hljs-keyword">messages</span> (in different languages)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:element</span> name=<span class="hljs-string">&quot;Message&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;umsg:MessageType&quot;</span> minOccurs=<span class="hljs-string">&quot;1&quot;</span> maxOccurs=<span class="hljs-string">&quot;unbounded&quot;</span>/&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:sequence</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> name=<span class="hljs-string">&quot;mimeType&quot;</span> <span class="hljs-built_in">type</span>=<span class="hljs-string">&quot;xs:string&quot;</span> default=<span class="hljs-string">&quot;text/plain&quot;</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;The MIME <span class="hljs-built_in">type</span> of the user message(s)&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-  &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span> name=<span class="hljs-string">&quot;MessageType&quot;</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-        The Base64-encoding of UTF-<span class="hljs-number">8</span> <span class="hljs-built_in">string</span> holding the user message.
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:documentation</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:annotation</span>&gt;
-    &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-      &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span> base=<span class="hljs-string">&quot;xs:base64Binary&quot;</span>&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:attribute</span> ref=<span class="hljs-string">&quot;xml:lang&quot;</span> use=<span class="hljs-string">&quot;required&quot;</span>/&gt;
-        &lt;<span class="hljs-keyword">x</span><span class="hljs-variable">s:anyAttribute</span> namespace=<span class="hljs-string">&quot;##any&quot;</span> processContents=<span class="hljs-string">&quot;lax&quot;</span>/&gt;
-      &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:extension</span>&gt;
-    &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:simpleContent</span>&gt;
-  &lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:complexType</span>&gt;
-
-&lt;/<span class="hljs-keyword">x</span><span class="hljs-variable">s:schema</span>&gt;</code></pre><p><a name="normative-references"></a></p>
-<h2 id="6-normative-references">6. Normative References</h2>
-<p><a name="rfc2119"></a>
-<strong>[RFC2119]</strong></p>
-<blockquote>
-<p><a href="http://www.ietf.org/rfc/rfc2119.txt">Bradner, S., Key words for use in RFCs to Indicate Requirement
-Levels, March 1997</a>.</p>
-</blockquote>
-<p><a name="bcp47"></a>
-<strong>[BCP47]</strong></p>
-<blockquote>
-<p><a href="https://www.rfc-editor.org/rfc/rfc5646.txt">Tags for Identifying Languages, September 2009</a>.</p>
-</blockquote>
-<p><a name="saml2core"></a>
-<strong>[SAML2Core]</strong></p>
-<blockquote>
-<p><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">OASIS Standard, Assertions and Protocols for the OASIS Security
-Assertion Markup Language (SAML) V2.0, March
-2005</a>.</p>
-</blockquote>
-<p><a name="eidentcat"></a>
-<strong>[EidEntCat]</strong></p>
-<blockquote>
-<p><a href="https://docs.swedenconnect.se/technical-framework/updates/06_-_Entity_Categories_for_the_Swedish_eID_Framework.html">Entity Categories for the Swedish eID Framework</a>.</p>
-</blockquote>
-<p><a name="changes-between-versions"></a></p>
-<h2 id="7-changes-between-versions">7. Changes between versions</h2>
-<p>This is the first version of this specification.</p>
-    </article>
-  </body>
-</html>
diff --git a/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html b/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
new file mode 120000
index 0000000..38d335a
--- /dev/null
+++ b/docs/updates/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
@@ -0,0 +1 @@
+../december-2024/18_-_User_Message_Extension_in_SAML_Authentication_Requests.html
\ No newline at end of file
diff --git a/docs/updates/OpenID_Connect_Claims_and_Scopes_Specification.html b/docs/updates/OpenID_Connect_Claims_and_Scopes_Specification.html
new file mode 120000
index 0000000..1c38ad2
--- /dev/null
+++ b/docs/updates/OpenID_Connect_Claims_and_Scopes_Specification.html
@@ -0,0 +1 @@
+../december-2024/OpenID_Connect_Claims_and_Scopes_Specification.html
\ No newline at end of file
diff --git a/docs/updates/OpenID_Connect_Profile_for_Sweden_Connect.html b/docs/updates/OpenID_Connect_Profile_for_Sweden_Connect.html
new file mode 120000
index 0000000..2954279
--- /dev/null
+++ b/docs/updates/OpenID_Connect_Profile_for_Sweden_Connect.html
@@ -0,0 +1 @@
+../december-2024/OpenID_Connect_Profile_for_Sweden_Connect.html
\ No newline at end of file
diff --git a/scripts/release.sh b/scripts/release.sh
index ed49bd6..a6a94e5 100755
--- a/scripts/release.sh
+++ b/scripts/release.sh
@@ -2,7 +2,7 @@
 #
 # release.sh
 #
-# Author: Martin Lindstr�m, Litsec AB
+# Author: Martin Lindström
 #
 
 INSTALL_DIR=$(dirname $0)
@@ -38,7 +38,10 @@ declare -a SPECIFICATIONS=("00 - Tekniskt ramverk - Introduktion"
     "11 - eIDAS Constructed Attributes Specification for the Swedish eID Framework"
     "12 - BankID Profile for the Swedish eID Framework"
     "13 - Signature Activation Protocol"
-    "14 - Principal Selection in SAML Authentication Requests")
+    "14 - Principal Selection in SAML Authentication Requests"
+    "18 - User Message Extension in SAML Authentication Requests"
+    "OpenID Connect Claims and Scopes Specification"
+    "OpenID Connect Profile for Sweden Connect")
 
 #
 # Produce HTML
@@ -60,8 +63,3 @@ done
 ${INSTALL_DIR}/tohtml.sh ${INSTALL_DIR}/templates/index.md ${OUTPUT_DIR} -o p
 
 exit 0
-
-
-
-
-