StatusList

inital thoughts from Christian and Paul

Requirements

• configurable state definitions
  • configurable bits per entry
• offline capability
  • holder caches status list
  • presentes during openid4vp (e.g., as additional proof in the array)
• compression
  • bitstring compression in the VC
    • advantage for offline/BLE
  • compression on transport layer
• binding to vc

Ideas

• Formats: JWT + CWT
  • What about JADES? Would this mean JWS and CWT (CWT supports unprotected header, whereas JWT does not)
• status list hoster as 4th entity for privacy -> IDunion SCE?
• predefined state definitions in the spec matching 90% of use cases
  • further stati with URL?
  • predefined state_defintions by type?

Example StatusList-JWS

{
    "alg" : ES256,
    "kid" : 1 //pointing to https://example.org/.well-known/jwks#1 
    "typ": "statuslist+jwt", //MUST
}
.
{
    "iss": "https://example.org/" //MUST
    "iat": 1683560915, //MUST
    "exp": 1686232115, //MAY -> this allows issuer to defined a TTL
    // this part probably needs to change
    "definition": { // optional: could be left out if pre-defined type
        "state_bits": 2, //MUST
        "state_definitions_uri":, //CONDITIONAL: uri to explanations
        "state_definitions" { //CONDITIONAL: explanations inline
            "0" : "VALID",
            "1" : "SUSPENDED",
            "2" : "REVOKED",
            "3" : "UNDEFINED" //or absent
        }
    }
    "encoded_status" : "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
}
.
{
<signature>
}

JWT Status List Credential (K added)

The typ header parameter of the Status List JWT MUST be present. The typ value MUST use statuslist+jws.

The following JWT claims [@!RFC7519] MUST be present in a Status List Credential expressed as a JWT:

• iss: REQUIRED. The issuer of the Status List JWT. The value of iss MUST be a URI.
• iat: REQUIRED. The time of issuance of the Status List JWT.
• exp: OPTIONAL. The expiry time of the Status List JWT.
• encoded_status: REQUIRED. Bitstring values that express the status of the digital credential. It is GZIP-compressed [@!RFC1952] and base64 encoded [@!RFC4648].

Note: If the issuer makes use of exp, it is RECOMMENDED to reissue a new status list before the exp date is reached. (P added)

Example Entry in SD-JWT credential

{
...
    
    //[k: not needed]
    "status_type": "status_list-jws" // do we need this or is resolving the status list and parsing the type from there fine? 
    // 42 = identifier for status list
    // 1234 = identifier in status list (1234th entry)
    "status_uri": "https://example.com/status_list/42#1234", 
}

Claims to be added to a Credential (K added)

• status: REQUIRED. The information on how to read the status of the Credential. See TBD for more information.

How to prove Status in offline Scenarios (K added)

When both Holder and the Verifier is offline.

• holder caches status list and presentes during openid4vp as an additional credential

Validation

Creation

Do we want this..?

Predefined Statuses

Privacy Considerations

• verifier profiling
• issuer/verifier collusion
• avoid sequential indices

Security Considerations

• regular reissuance with using "exp"
  • more assurance for verifier that status is not cached

Questions

• access control
  • public
  • restriced
    • holder: bearer token reuse?
    • verifier: relying party proof?
  • who fetches status list?
    • holder
    • verifier
• are there better representations than a bit string?
• Compression? Is zlib/DEFLATE the best option?
• JSON Serialization?

Other options for status list jwt

{
    "typ": "statuslist+jwt-revoc2", // statuslist for revocation with 2 bits with predefined meaning
    
    "iss": "https://example.org/"
    "iat": 1683560915,
    "exp": 1686232115,
    "status" : "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
}

I dislike the ex

{
    "typ": "statuslist+jwt", // statuslist with included definition
    
    "iss": "https://example.org/"
    "iat": 1683560915,
    "exp": 1686232115,

    "def": {
       "bits": 2,
       "values": {
          "0" : "VALID",
          "1" : "SUSPENDED",
          "2" : "REVOKED",
          "3" : "UNDEFINED" //or absent
       }
    },
    "status" : "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
}

typ is for JOSE header (Paul)

Status List Types

Define common statuses:

• VALID : This status means xyz
• SUSPENDED:

Define common status lists:

Type definition for "revocation-list":

{
   "bit_size": 1,
   "values": {
      "0" : "NOT REVOKED",
      "1" : "REVOKED",
   }
}`

Type definition for "revocation-suspension-list":

{
   "bit_size": 1,
   "values": {
      "0" : "VALID",
      "1" : "SUSPENDED",
      "2" : "REVOKED",
      "3" : "UNDEFINED", //or absent
   }
}`

How to use well-defined status list types:

"sts_lst": {
    "typ": "revocation-list",
    "list": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAA......IC3AYbSVKsAQAAA"
  }

How to define new types:

"sts_lst": {
    "typ_def" : {
       "bit_size": 2,
       "values": {
          "0" : "MY_FANCY_STATUS_1",
          "1" : "REVOKED",
          "2" : "REVOKED",
          "3" : "UNDEFINED" //or absent
       }
    },
    "list": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAA......IC3AYbSVKsAQAAA"
  }