Your premise relies on a feature of JSON that does not exist. JSON does not provide well-defined behavior for repeated names within an object:
When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. From: https://www.rfc-editor.org/rfc/rfc8259.html#section-4 — Justin On Oct 2, 2023, at 1:12 PM, Denis <denis.i...@free.fr> wrote: The latest draft (i.e. draft-looker-oauth-jwt-cwt-status-list-latest) which is available at : https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.html includes the following illustrative drawing: +------------------+ +-------------------+ | | 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 or use 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. As another example, currently the claim "nationalities" has been registered by the IANA. See: https://www.iana.org/assignments/jwt/jwt.xhtml 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 | | | |<-------------------| | +----------------------+ +----------------------+ The first draft of the OAuth WG should rather be called: draft-oauth-status-list-token-00 Denis PS. A remainder: - the protocol leaks information that allows verifiers to link the tokens they receive. - depending upon the architecture deployed by the token Issuer, the Issuer may be in a position to act as Big Brother, i.e. allowing it to know where and when a token it has issued has been used. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
