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 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.
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
