+------------------++-------------------+
||References||
||------------------->||
| Referenced Token || Status List Token |
|(JSON or CBOR)||(JWT or CWT)|
||Describes Status||
||<-------------------||
+------------------+ +-------------------+
This drawing is not identical to the drawing of the referenced draft.
On the left side, "JSON or CBOR" are mentioned instead of "JWT or CWT".
However, such change would indeed be appropriate (and in both rectangles
as explained below).
In section 4. of JWT [RFC7519] The text states:
The JWT Claims Set represents a JSON object whose members are
the claims conveyed by the JWT.
The Claim Names within a JWT Claims Set MUST be unique. JWT parsers MUST
either reject JWTs
with duplicate Claim Names oruse a JSON parser that returns
only the lexically last duplicate member name (...).
In [RFC8392] such sentence is not present which means that a Claim does
not need to be unique.
However, in some applications, it might be useful to use JSON tokens
that contain several occurrences of the same claim within it.
In addition, the processing of such tokens would not necessarily need to
follow the description made in section 7 of [RFC7519], i.e. JWTs.
As a first example, let us consider the case where the URI placed under
the "status_list " claim does not respond.
For resilience considerations, another URI should be defined. This can
be handled in two ways:
using a more complex claim structure for the "status_list" claim, or
allowing the inclusion of several "status_list" claims.
In order to support selective disclosure, the claim "nationality" should
be defined, so that two "nationality" claims can be present,
in order to allow bi-national users to choose which "nationality"
claim(s) to disclose, without disclosing that they have two nationality
claims.
Note: Using a different name for tokens supporting credentials,
e.g., JXT ot CXT (with the letter "X" different from the letter "J")
would address this problem.
The abstract states:
This specification defines status list data structures for representing
the status of JSON Web Tokens (JWTs) [RFC7519] and
CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures
themselves are also represented as JWTs or CWTs.
Both sentences imply restrictions since they limit the use of the
mechanism only to JWTs and CWTs.
Limiting the use of the Status List mechanism to JWTs and CWTs would not
allow other forms of JSON or CBOR tokens
to take advantage of the mechanism described in this draft.
The abstract should be modified to be able to support other forms of
JSON or CBOR tokens,
while JWTs and CWTs should be mentioned as examples.
In order to allow future evolutions, the same kind of change should be
done for Status List Tokens.
In order to allow for such a possibility, the title should include "JSON
and CBOR" rather than "JWT and CWT".
Proposed changes:
1) Change proposal for the title of the document:
JSON and CBOR encoded Status Lists
2) Change proposal for the Abstract:
This specification defines status list data structures for representing
the status of JavaScript Object Notation (JSON) tokens [RFC8259] and
of Concise Binary Object Representation (CBOR) tokens
[RFC7049] (see also [RFC8949]), /such as/ JSON Web Tokens (JWTs)
[RFC7519] and
CBOR Web Tokens (CWTs) [RFC8392].
The status list data structures themselves are represented as JSON
tokens or CBOR tokens.
3) The same kind of change should be done within the document, e.g. :
*
**+----------------------++----------------------+
||References||
||------------------->||
|Referenced Token||Status List Token|
| (JSON or CBOR token) || (JSON or CBOR token) |
||Describes Status||
||<-------------------||
+----------------------++----------------------+
c2bo
commented
10 months ago
https://mailarchive.ietf.org/arch/msg/oauth/hSOvzlKZTUJpI8ucB1CLNo5koqg/