Extensibility point - Allowing for different types of statuses

[tplooker]

The draft currently sets at least directionally that there can be different types of status lists that convey different kinds of statuses (e.g revocation vs a more complex suspended/active/inactive status setup), w.r.t I think we need to agree:

1. We think this extensibility point is useful
2. What the extensibility point should control e.g does it affect things like the number of bits allocated per index (so more than a binary state can be expressed)
3. Does it control the type of URI the status list can be resolved from e.g MUST be an HTTPS url or is that controlled else where.

[paulbastian]

@c2bo and me were thinking on that. Our ideas were:

• having the possibility that a status contains more than one bit is very useful and should be included. Otherwise multiple statuses for one token (e.g. revocation and suspension) requires two status lists, this means additional calls, potential syncing issues etc. this is a shortcoming of the StatusList2021
• the spec should serve a predefined template for the most common usecases, e.g. simple revocation with 1 bit and maybe one more template with revocation and suspension
• in other cases the statusList should either include the definition in its metadata and/or point to a issuer-controlled URL that explains the status bits

Our proposal was:

{
    "iss": "https://example.org/" //MUST
    "iat": 1683560915, //MUST
    "exp": 1686232115, //MAY -> this allows issuer to defined a TTL
    // this part probably needs to change
    "def": { // optional: could be left out if pre-defined type
        "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"
}

In this example state_definitions_uri could point to a tempalte from this spec

[c2bo]

I do believe we have to give some pre-defined interpretations - parsing the different states doesn't really work well for fully automated flows imho. Biggest question then would be if just mentioning that template via name would be enough or if we still want to have that information served in the status list as well.

If we take revocation as an example, then we likely need to define at least 2 default templates similar to these:

• 1bit-revocation: where 0 equals VALID and 1 equals REVOKED
• 2bit-revocation: 0 = VALID 1 = REVOKED 2 = SUSPENDED 3 = ..

We could then either have that definition as part of the JWT or just reference via name/uri (which I would prefer - makes implementation a lot easier).

[tplooker]

Our proposal was:

Thanks this is great to be able to review! IMO the simplest possible conveyance about what statues a list can represent I believe can be done through the sts.typ alone. Because I think majority of implementations will require explicit handling of different status types rather than supporting generic statuses. For example as an implementation if I were to come across a JWT with a sts.typ value set to "revocation-list" it would mean each status entry in the list is represented by 1bit where when the bit is set to 0 it represents NOT REVOKED status and when the bit is set to 1 it represents REVOKED.

[paulbastian]

This is addressed by #17, @tplooker please close this issue