Establish a mechanism that allows for other revocation means in the Referenced Token

[c2bo]

Establish a mechanism that allows for other revocation means in the Referenced Token as discussed in #85. The only thing i changed was to call the reference "status_list" but I am open to change it to "status_bitstring" if we think that is a better fit.

Closes #85

Preview Link

click here for rendered preview of PR

[paulbastian]

Looks good to me. Maybe merge after #89

[paulbastian]

Should we consider registering an IANA registry? As RFC7800 did here: https://www.rfc-editor.org/rfc/rfc7800.html#section-6.2

[tplooker]

If we make this a MUST then won't other future mechanisms only be additional rather than alternatives?

[paulbastian]

this is only a MUST for the mechanism used in the specification. If Giuseppe wants to implement an OCSP-like mechanism than it would look mlike:

"status" : {
  "new-mechanism-name" : {
    "whatever-parameter" : "whatever-value"
  }
}  

[c2bo]

Yeah, that was the intention. For this spec, the existence of status_list is a MUST, but other status mechanisms can reuse the status claim and define other behaviour depending on other claims within status.

[paulbastian]

I think we may need some text to the introduction that explains this in more detail. However its more better to merge #89 first and then start working from there

[c2bo]

This changed quite a bit with the recent bigger PR (and had some merge conflicts) -> please check again :/ @paulbastian @tplooker

[c2bo]

I'll add a small section as an introduction / to explain the status expansion idea (similar to cnf claim) over the weekend

[paulbastian]

Changes look good so far

[paulbastian]

Maybe swap the order of Uri and idx?

[c2bo]

Current ordering is alphabetical which matches the examples and what afaik most json libraries will generate - that was my main intention for this ordering

[paulbastian]

I think the text in the introduction is a little weird. I checked what 7800 wrote:

Other members of the "cnf"
object may be defined because a proof-of-possession key may not be
the only means of confirming the authenticity of the token

This specification establishes the IANA "JWT Confirmation Methods"
registry for these members in Section 6.2 and registers the members
defined by this specification. Other specifications can register
other members used for confirmation, including other members for
conveying proof-of-possession keys using different key representations.

I think the text may be more subtle along this lines. I would omit "we expect more in the future" which doesn't age well in a standard and be more neutral, just saying that we establish a registry for other mechanisms?

[c2bo]

I think the text in the introduction is a little weird. I checked what 7800 wrote:

Other members of the "cnf"
object may be defined because a proof-of-possession key may not be
the only means of confirming the authenticity of the token

This specification establishes the IANA "JWT Confirmation Methods"
registry for these members in Section 6.2 and registers the members
defined by this specification. Other specifications can register
other members used for confirmation, including other members for
conveying proof-of-possession keys using different key representations.

I think the text may be more subtle along this lines. I would omit "we expect more in the future" which doesn't age well in a standard and be more neutral, just saying that we establish a registry for other mechanisms?

Sounds reasonable - i will propose a change

[c2bo]

I changed the text and realized that the IANA text in general needs some work, could you please re-review the current state? I am not super happy with this version but imho let's go with something like this for the time being and revisit a bit later (and fix all of the IANA related things).

[paulbastian]

it seems this is in the wrong chapter?