V3 updates

5.0/en/0x12-V3-Session-management.md

@@ -44,7 +44,6 @@ Some of the requirements in this section relate to section [7.1](https://pages.n
 | **3.2.2** | [MOVED TO 3.1.4] | | | | |
 | **3.2.3** | [DELETED, MERGED TO 8.2.2] | | | | |
 | **3.2.4** | [DELETED, MERGED TO 3.1.4] | | | | |
-| **3.2.5** | [ADDED] Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF-style attack where a new application session for the user is created via SSO without user interaction. | | ✓ | ✓ | |
 
 TLS or another secure transport channel is mandatory for session management. This is covered in the Communications Security chapter.
 
@@ -80,8 +79,8 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **3.5.1** | [GRAMMAR] Verify that the application allows users to revoke OAuth tokens that form trust relationships with linked applications. | | ✓ | ✓ | 290 |
 | **3.5.2** | [MOVED TO 3.1.3] | | | | |
-| **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that stateless tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
-| **3.5.4** | [ADDED] Verify that stateless tokens are checked for expiration before processing them further. | ✓ | ✓ | ✓ | 613 |
+| **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
+| **3.5.4** | [ADDED] Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | ✓ | ✓ | ✓ | 613 |
 | **3.5.5** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 |
 | **3.5.6** | [ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience. | ✓ | ✓ | ✓ | 287 |
 
@@ -95,6 +94,7 @@ Some of the requirements in this section relate to section [7.2.1](https://pages
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **3.6.1** | [MODIFIED, MERGED FROM 3.6.2] Verify that session lifetime and termination between Relying Parties (RPs) and Credential Service Providers (CSPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between CSP authentication events is reached. | | | ✓ | 613 |
 | **3.6.2** | [DELETED, MERGED TO 3.6.1] | | | | |
+| **3.6.3** | [ADDED] Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | | ✓ | ✓ | |
 
 ## V3.7 Defenses Against Session Abuse