December 2024 (#231)

* December 2024 release

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**
 

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**
 

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,17 +321,17 @@ 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>
 ###### 2.1.3.8.2. Requesting Identity Provider to Display SignMessage
 
 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:**
 

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\]**