Missing requirement for sm3 moving session management to C7 about digital identities

docs/en/04-design/02-web-app-checklist/06-digital-identity.md

@@ -81,7 +81,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 17. Set cookies with the `HttpOnly` attribute,
     unless you specifically require client-side scripts within your application to read or set a cookie value
 
-#### 4. Session Generation and Expiration
+#### 4. Session Management
 
 1. Ensure that the session id is long, unique and random, i.e., is of high entropy
 2. Generate a new session during authentication and re-authentication
@@ -91,6 +91,10 @@ and use the list below as suggestions for a checklist that has been tailored for
     which users must re-authenticate
 6. Supplement standard session management for sensitive server-side operations, like account management, by requiring and
    validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action
+7. If long authenticated sessions are allowed, periodically re-validate a user's authorization
+8. The application must support termination of sessions when authorization ceases
+9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users
+   should be able to terminate their active sessions
 
 #### References
 

docs/en/04-design/02-web-app-checklist/07-access-controls.md

@@ -31,21 +31,19 @@ and use the list below as suggestions for a checklist that has been tailored for
 
 1. Limit the number of transactions a single user or device can perform in a given period of time,
     low enough to deter automated attacks but above the actual business requirement
-2. If long authenticated sessions are allowed, periodically re-validate a user's authorization
-3. Implement account auditing and enforce the disabling of unused accounts
-4. A new account should have minimal or no access by default
-5. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use
+2. Implement account auditing and enforce the disabling of unused accounts
+3. A new account should have minimal or no access by default
+4. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use
     of admin accounts with global access
-6. The application must support termination of sessions when authorization ceases
-7. Restrict function-level access to consumers with explicit permissions
-8. Restrict direct object references to only authorized users with explicit permissions to specific data items  
+5. Restrict function-level access to consumers with explicit permissions
+6. Restrict direct object references to only authorized users with explicit permissions to specific data items  
     to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA)
-9. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken
+7. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken
     object property level authorization (BOPLA)
-10. Restrict access security-relevant configuration information to only authorized users who have been allowed access through
+8. Restrict access security-relevant configuration information to only authorized users who have been allowed access through
     multiple layers of security, including continuous consumer identity verification, device security posture assessment, and
     contextual risk analysis
-11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible
+9. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible
 
 #### References