Detailed status assertions (#61)

* Assertions of invalidity * Add example * Updated examples for clarity * Add privacy considerations for reasons * Update draft-demarco-oauth-status-attestations.md * Update draft-demarco-oauth-status-attestations.md * Update draft-demarco-oauth-status-assertions.md * Update draft-demarco-oauth-status-assertions.md * Apply suggestions from code review * Apply suggestions from code review * Update draft-demarco-oauth-status-assertions.md Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * Apply suggestions from code review Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * Update draft-demarco-oauth-status-assertions.md * Update draft-demarco-oauth-status-assertions.md * Apply suggestions from code review * Apply suggestions from code review Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * Update draft-demarco-oauth-status-assertions.md Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * Update draft-demarco-oauth-status-assertions.md Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * Update draft-demarco-oauth-status-assertions.md Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> * address missing details * Update draft-demarco-oauth-status-assertions.md Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it> --------- Co-authored-by: Giuseppe De Marco <giuseppe.demarco@teamdigitale.governo.it>
peppelinux · Sep 26, 2024 · 67534bd · 67534bd
1 parent b497657
commit 67534bd
Showing 1 changed file with 141 additions and 4 deletions.
diff --git a/draft-demarco-oauth-status-assertions.md b/draft-demarco-oauth-status-assertions.md
@@ -111,14 +111,15 @@ These assertions are periodically provided
 to holders, who can present these to verifier along
 with the corresponding digital credentials.
 The approach outlined in this document
-makes the verifier able to check the non-revocation of a digital credential
+makes the verifier able to check the status,
+such as the non-revocation, of a digital credential
 without requiring to query any third-party entities.
 
 --- middle
 
 # Introduction
 
-Status Assertions ensure the non-revocation of digital
+Status Assertions show the status of digital
 credentials, whether in JSON Web Tokens (JWT) or CBOR Web Tokens (CWT)
 format. Status Assertions function
 similarly to OCSP Stapling ([RFC6066]), allowing clients to present to the
@@ -248,7 +249,7 @@ the expiration datetime of the Digital Credential;
 - MUST enable the offline use cases by employing validation using
 a cryptographic signature and the cryptographic public key of the
 Credential Issuer.
-- MUST NOT contain personal information about the User who owns
+- SHOULD NOT contain personal information about the User, that isn't already made available to the Credential Verifier, who owns
 the Digital Credential to which the Status Assertion refers.
 
 # Proof of Possession of a Credential
@@ -269,7 +270,8 @@ guidance for concrete implementations utilizing common proof of
 possession mechanisms. This includes, but is not limited to:
 
 1. Having the digital representation of the Digital Credential (the bytes).
-2. Controlling the confirmation method of the Credential, using the Credential's `cnf` parameter.
+2. Controlling the confirmation method of the Credential,
+using the Credential's `cnf` parameter.
 
 The essence of requiring proof of possession over the Credential
 through the confirmation method, such has proving the control of the
@@ -549,6 +551,7 @@ where the format is JWT.
     "exp": 1504785536,
     "credential_hash": $hash-about-Issuer-Signed-JWT,
     "credential_hash_alg": "sha-256",
+    "credential_status_validity": true,
     "cnf": {
         "jwk": {...}
     }
@@ -571,6 +574,7 @@ The Status Assertion MUST contain the parameters defined below.
 | **exp** | UNIX Timestamp with the expiration time of the JWT. It MUST be greater than the value set for `iat`. | {{RFC9126}}, {{RFC7519}}, {{RFC7515}} |
 | **credential_hash** | Hash value of the Digital Credential the Status Assertion is bound to. | this specification |
 | **credential_hash_alg** | The Algorithm used of hashing the Digital Credential to which the Status Assertion is bound. The value SHOULD be set to `sha-256`. | this specification |
+| **credential_status_validity**| Boolean value indicating the absolute validity of the Credential linked to the Status Assertion. This parameter is REQUIRED, and the Verifier MUST verify its presence and value to assess the Credential's validity. | this specification |
 | **cnf** | JSON object containing confirmation methods. The sub-member contained within `cnf` member, such as `jwk` for JWT and `Cose_Key` for CWT, MUST match with the one provided within the related Digital Credential. Other confirmation methods can be utilized when the referenced Digital Credential supports them, in accordance with the relevant standards. | {{RFC7800}} Section 3.1, {{RFC8747}} Section 3.1 |
 
 
@@ -677,6 +681,123 @@ may not always coincide with the actual usability of a Digital Credential,
 allowing Verifiers to examine and make educated conclusions based on a
 variety of scenarios.
 
+# Detailed Status Assertions
+
+Status Assertions can introduce a more accurate level of detail, and therefore not necessarly limited to simple boolean information.
+This enables Verifier policies to be conditioned on the presence of secured information, instead of the absence of information.
+This section proposes syntax to support detailed assertions.
+The `credential_status_validity` claim MUST be present and be either `true` or `false`.
+The `credential_status_detail` claim MAY be present and if present MUST be an object.
+The semantics of the claims within the `credential_status_detail` object are determined by the Credential Issuer.
+
+An example of a boolean status is:
+
+~~~
+{
+    "alg": "ES256",
+    "typ": "status-assertion+jwt",
+    "kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
+}
+.
+{
+    "iss": "https://issuer.example.org",
+    "iat": 1504699136,
+    "exp": 1504785536,
+    "credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
+    "credential_hash_alg": "sha-256",
+    "credential_status_validity": false,
+    "credential_status_detail": {
+      "revoked": false,
+      "suspended": true,
+    },
+    "cnf": {
+      "jwk": {
+        "alg": "ES256",
+        "kty": "EC",
+        "crv": "P-256",
+        "x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",
+        "y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk"
+      }
+    }
+}
+~~~
+
+An example of an enumeration status is:
+
+~~~
+{
+    "alg": "ES256",
+    "typ": "status-assertion+jwt",
+    "kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
+}
+.
+{
+    "iss": "https://issuer.example.org",
+    "iat": 1504699136,
+    "exp": 1504785536,
+    "credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
+    "credential_hash_alg": "sha-256",
+    "credential_status_validity": false,
+    "credential_status_detail": {
+      "state": "suspended", // or "revoked"
+    },
+    "cnf": {
+      "jwk": {
+        "alg": "ES256",
+        "kty": "EC",
+        "crv": "P-256",
+        "x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",
+        "y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk"
+      }
+    }
+}
+~~~
+
+An example of dynamic status using a small matrix:
+
+~~~
+{
+    "alg": "ES256",
+    "typ": "status-assertion+jwt",
+    "kid": "w8ZOZRcx21Zpry7H-0VLBsH7Wf7WXb6TeK3qVMCpY44"
+}
+.
+{
+    "iss": "https://issuer.example.org",
+    "iat": 1504699136,
+    "exp": 1504785536,
+    "credential_hash": "xnlAq6Ma8fgu1z4hdGphJnKLulaVHpLCFeZFUGpQ2dA",
+    "credential_hash_alg": "sha-256",
+    "credential_status_validity": true,
+    "credential_status_detail": {
+      "preferences": [[1, 0.25, 0.76 ...] ...]
+    },
+    "cnf": {
+      "jwk": {
+        "alg": "ES256",
+        "kty": "EC",
+        "crv": "P-256",
+        "x": "_2ySUmWFjwmraNlo15r6dIBXerVdy_NpJuwAKJMFdoc",
+        "y": "MV3C88MhhEMba6oyMBWuGeB3dKHP4YADJmGyJwwILsk"
+      }
+    }
+}
+~~~
+
+An example of multiple assertions:
+
+~~~
+HTTP/1.1 200 Created
+Content-Type: application/json
+
+{
+    "status_assertion_responses": [
+      $JWT_1, // Not revoked, boolean assertion
+      $JWT_2, // alg = none, suspended indicator
+      $JWT_3, // Preferences matrix assertion
+    ]
+}
+~~~
 
 # Security Considerations
 
@@ -783,6 +904,13 @@ Status Assertions are based on a privacy-by-design approach, reflecting
 a deliberate effort to balance security and privacy needs in the
 Digital Credential ecosystem.
 
+## Validity Reasons
+
+Depending by the scopes of how the detailed Status Assertions are implemented, these may disclose details about the Holder or subject that were not initially committed to during the original Credential issuance. This can potentially expose additional information that was not part of the original credentialing process.
+Providing a reason that a Digital Credential is no longer valid can be essential to certain use cases, and unacceptable for others
+For example, in a healthcare setting, a patient should not have medical reasons for a suspended credential disclosed in assertions of suspension.
+However, in a supply chain context, a product suspension might benefit from additional information, such as batch or lot information.
+
 # IANA Considerations
 
 ## JSON Web Token Claims Registration
@@ -803,6 +931,15 @@ IANA "JSON Web Token Claims" registry [IANA.JWT] established by {{RFC7519}}.
 *  Change Controller: IETF
 *  Specification Document(s): [this specification](#status-assertion)
 
+<br/>
+
+*  Claim Name: `credential_status_detail`
+*  Claim Description: New status information provided by the Issuer.
+*  Change Controller: IETF
+*  Specification Document(s): [this specification](#status-assertion)
+
+
+
 ## Media Type Registration
 
 This section requests registration of the following media types [RFC2046] in