owned this note
owned this note
Published
Linked with GitHub
# 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"
}
```