Token Status List (TSL)
draft-ietf-oauth-status-list-20

[Ballot discuss]
[revised ballot for -20]

** For the OAUTH WG Chairs and responsible AD: this document appears to be describing new mechanisms for CWT; and a new sub-registry for CWT.  I could use help understanding how this fits into the defined scope in OAUTH WG charter given that the status-list work isn’t explicitly named and CWT work is not in scope.  In particular, SD-CWT is done in SPICE.

[Ballot comment]
Authors have merged several PRs which address my DISCUSS and Comments here:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pulls

I'm sure these will make their way into the drafts soon, so am clearing the discuss.

## Comments

### Public?

```
216   Status Provider, who serves the Status List Token on a public,
217   resolvable endpoint.  The Relying Party or the Holder may fetch the
```

Perhaps you mean simply accessible to the verifier?
I'm not sure if public precludes .internal, or other non public internet resources.

### SD-JWT

```
827   SD-JWT-based Verifiable Credentials (Section 3.2.2.2 of [SD-JWT.VC])
```

Is there a reason that SD-JWT VC is mentioned throughout this document instead of SD-JWT by itself?

### Why not MUST?

```
1113   most common Status Type values.  Applications SHOULD use registered
1114   values for statuses if they have the correct semantics.  Additional
```

Under which circumstances, can this SHOULD be ignored?
Which use cases would encourage a different value from one in the registry to be used with the exact same semantics?


### Which .well-known

```
1387   The Issuer MAY link to the Status List Aggregation URI in metadata
1388   that can be provided by different means like .well-known metadata as
1389   is used commonly in OAuth and OpenID Connect, or within Issuer
1390   certificates or trust lists (such as VICAL as defined in Annex C of
```

It would be better to explicitly name the .well-known URIs than to refer to them like this.
The current normative requirement is ambiguous.


### One time use reference tokens

```
1704   To avoid privacy risks of colluding Relying Parties, it is
1705   RECOMMENDED that Issuers provide the ability to issue batches of one-
1706   time-use Referenced Tokens, enabling Holders to use in a single
1707   interaction with a Relying Party before discarding.  See Section 13.2
```

Is the index of and URL of the status information allowed to be the same for these single use tokens?

```
1723   interacted with the same Holder.  It is therefore recommended to use
1724   Status Lists for Referenced Token formats that have similar
1725   unlinkability properties.
```

I don't undertand what "similar unlinkability properties" means.

### APPLICATION_SPECIFIC

Are there really 0 references to provide for these application specific registrations?
Are they in use today? or anticipated to be be used ever?
Are the reserved for experimentation, or reservered because of existing deployments?

## Nits

### Media type point of contact

```
2349   *  Person & email address to contact for further information: Paul
2350       Bastian, paul.bastian@posteo.de
```

While this has been common, I think it is better to direct the point of contact for media types reserved by a working group to the working group list itself.

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-oauth-status-list-15
CC @OR13



* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-15.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


Thanks to John Levine for the ART ART review.

## Discuss

### Not really out of scope....

```
1233   As this is out of scope for this document, this validation is not
1234   described here, but is expected to be done according to the format of
1235   the Referenced Token.
```

This is not as clear as it could be.

Is it acceptable to perform any HTTP dereferencing in the case the referenced token is invalid?

Perhaps something to the effect of "regardless of the validation procedures for the referenced token, if validation fails, no http operations must be performed".

The current framing feels like its inviting implementers to make network requests which leak metadata, for tokens that are already considered invalid.

```
1285       index is out of bounds of the Status List, no statement about the
1286       status of the Referenced Token can be made and the Referenced
1287       Token SHOULD be rejected.
```

This makes validation of the referenced token in scope... also... this SHOULD seems like a bad idea.
Why not MUST?... What does it mean to accept a token about which not statement of status can be made?

[Ballot comment]

## Comments

### Public?

```
216   Status Provider, who serves the Status List Token on a public,
217   resolvable endpoint.  The Relying Party or the Holder may fetch the
```

Perhaps you mean simply accessible to the verifier?
I'm not sure if public precludes .internal, or other non public internet resources.

### SD-JWT

```
827   SD-JWT-based Verifiable Credentials (Section 3.2.2.2 of [SD-JWT.VC])
```

Is there a reason that SD-JWT VC is mentioned throughout this document instead of SD-JWT by itself?

### Why not MUST?

```
1113   most common Status Type values.  Applications SHOULD use registered
1114   values for statuses if they have the correct semantics.  Additional
```

Under which circumstances, can this SHOULD be ignored?
Which use cases would encourage a different value from one in the registry to be used with the exact same semantics?


### Which .well-known

```
1387   The Issuer MAY link to the Status List Aggregation URI in metadata
1388   that can be provided by different means like .well-known metadata as
1389   is used commonly in OAuth and OpenID Connect, or within Issuer
1390   certificates or trust lists (such as VICAL as defined in Annex C of
```

It would be better to explicitly name the .well-known URIs than to refer to them like this.
The current normative requirement is ambiguous.


### One time use reference tokens

```
1704   To avoid privacy risks of colluding Relying Parties, it is
1705   RECOMMENDED that Issuers provide the ability to issue batches of one-
1706   time-use Referenced Tokens, enabling Holders to use in a single
1707   interaction with a Relying Party before discarding.  See Section 13.2
```

Is the index of and URL of the status information allowed to be the same for these single use tokens?

```
1723   interacted with the same Holder.  It is therefore recommended to use
1724   Status Lists for Referenced Token formats that have similar
1725   unlinkability properties.
```

I don't undertand what "similar unlinkability properties" means.

### APPLICATION_SPECIFIC

Are there really 0 references to provide for these application specific registrations?
Are they in use today? or anticipated to be be used ever?
Are the reserved for experimentation, or reservered because of existing deployments?

## Nits

### Media type point of contact

```
2349   *  Person & email address to contact for further information: Paul
2350       Bastian, paul.bastian@posteo.de
```

While this has been common, I think it is better to direct the point of contact for media types reserved by a working group to the working group list itself.

[Ballot discuss]
** For the OAUTH WG Chairs and responsible AD: this document appears to be describing new mechanisms for CWT and ISO mdoc; and a new sub-registry for CWT.  I could use help understanding how this fits into the defined scope in OAUTH WG charter given that the status-list work isn’t explicitly named and CWT and mdoc aren’t directly tied to “increasing interoperability of OAuth deployments and to improve security [in OAuth deployments].”

** Section 6.3.2
  ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by
  introducing the status parameter in the Mobile Security Object (MSO)
  as specified in Section 9.1.2 of [ISO.mdoc].  The status parameter
  contains the Status CBOR structure as described in Section 6.3.
  It is RECOMMENDED to use status for the label of the field that
  contains the Status CBOR structure.

Interpretting and implementing this text seems to require understanding the [ISO.mdoc] specification.  Please make this a normative reference.

** Section 11.5
  Reasonable values for both claims highly depend on the use-case
  requirements and clients SHOULD be configured with lower/upper bounds
  for these values that fit their respective use-cases.

What is the interoperable way to access the “lower/upper bound … that fit their respective use-cases”.  Perhaps s/SHOULD/should/

** Section 11.6
  Implementers SHOULD only use MACs to
  secure the integrity of Status List Tokens if they fully understand
  the risks of MACs when compared to digital signatures and especially
  the requirements of their use-case scenarios.

What is the interoperable way to assess if an implementor “fully understand[s] the risks of MACs”?  Perhaps s/SHOULD/should/

** Sections 14.2, 14.4, and 14.5 establish new registries with a Specification-Required allocation policy.  This policy includes a review/approval by a Designated Expert (DE).  The current text is clear on where and when to send such requests, but it doesn’t provide any guidance to the DE on deciding how to process it.  Could this please be added.

[Ballot comment]
I support Andy Newton and Mike Bishop’s DISCUSS positions.

** Section 1.2
  Modern
  approaches use accumulator-based revocation registries and Zero-
  Knowledge-Proofs to accommodate for this privacy gap, but face
  scalability issues again.

-- Consider how this text might age in a long-lived document.

-- Consider if “modern approaches” is the right characterization (if so, what does this mean?).  Are these schemes (e.g., accumulator-based schemes) widely deployed?

** Section 1.3
  *  the specification shall favor a simple and easy-to-understand
      concept
…
  *  the specification shall be optimized to support the most common
      use cases and avoid unnecessary complexity of corner cases

-- How is “easy-to-understand” being judged?
-- What are these use cases?
-- Consider if this text is needed

** Section 11.2
  A Status List Token in the JWT format SHOULD follow the security
  considerations of [RFC7519] and the best current practices of
  [RFC8725].
  A Status List Token in the CWT format SHOULD follow the security
  considerations of [RFC8392].

Is there any further guidance that can be given on when it is appropriate to ignore these security considerations or best practices?

[Ballot discuss]
# IESG review of draft-ietf-oauth-status-list-15

CC @MikeBishop

## Discuss

### Section 8.4, paragraph 3
```
    To obtain the Status List Token, the Relying Party MUST send an HTTP
    GET request to the URI provided in the Referenced Token with the
    additional query parameter time and its value being a unix timestamp.
    The response for a valid request SHOULD contain a Status List Token
    that was valid for that specified time or an error.

    If the Server does not support the additional query parameter, it
    SHOULD return a status code of 501 (Not Implemented) or if the
    requested time is not supported it SHOULD return a status code of 406
    (Not Acceptable).  A Status List Token might be served via static
```
406 (Not Acceptable) indicates that a server was unable to satisfy a client's
preferences as expressed through Proactive Negotiation (RFC 9110, Section 12.1),
but a query parameter isn't that. In fact, HTTP itself has no notion of "query
parameters" -- the optional query component is merely a part of identifying the
target resource, and the `key=value` structure is a convention applications can
use or not (albeit a very common one).

I would suggest normatively spelling out how you want the query portion of the
URI constructed and choosing a different status code for the requested resource
not existing. 404 or 410 might be the most appropriate for a server that can
provide historical data, but not for the requested timestamp. 501 (Not
Implemented) seems reasonable for a server that understands the request for a
historical status list, but does not support such a request, though 404 might be
equally appropriate as the requested resource does not exist on the server.

[Ballot comment]
## Comments

### Section 3

Thanks for a good Terminology section. For a crucial word that occurs
over 1k times in this document, I'm surprised not to see a definition of
"Status" either in the introduction or here.

It does finally show up in Section 7!

### Section 4, paragraph 1

Please update the last sentence to also use section numbers.

### Section 4.1, paragraph 13

Step 4 above says these byte arrays will be compressed, but there's no
mention of that here at the end. While it may not be terribly illustrative,
it might be worth a sentence confirming that these are run through DEFLATE/ZLIB
before being used as input to 4.2 or 4.3.

### Section 8.1, paragraph 1
```
    The Status Provider SHOULD provide Status List Token on an endpoint
    serving an HTTP GET request to the URI provided in the Referenced
```
Consider instead:
  The Status Provider SHOULD return the Status List Token
  in response to an HTTP GET request to the URI provided in the Referenced

### Section 8.1, paragraph 0

Consider a reference to RFC 9110 for HTTP semantics, Accept, etc.

### Section 8.2, paragraph 8
```
    The HTTP response SHOULD use gzip Content-Encoding as defined in
    [RFC9110] for Status List Tokens in JWT format.
```
Given the variety of content codings which are in use with HTTP, it seems
strange to call out gzip in particular in this spec. That's not an
interoperability issue. Consider simply indicating that a content coding *such
as* gzip could reduce the size of the payload, and reference 9110 for negotiation
of such codings.

### Section 14.2, paragraph 2
```
    Experts.  However, to allow for the allocation of names prior to
    publication, the Designated Expert(s) may approve registration once
    they are satisfied that such a specification will be published.
```
Given that Specification Required only requires that the doc exist, not be
published as an RFC, is this really needed? Does the allocation need
to happen even before publication as an -00 draft?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4.1, paragraph 2
```
-        every operation and thus keeping implementations simpler and less
-                      ^^^^
+        every operation, thus keeping implementations simpler and less
+                      ^
```

#### Section 6.3, paragraph 4
```
-          o  idx: REQUIRED.  Unsigned integer (major type 0) The idx
+          o  idx: REQUIRED.  Unsigned integer (major type 0). The idx
+                                                            +
```

#### Section 11.4, paragraph 1
```
-    HTTP clients that follow 3xx (Redirection) class of status codes
-                                              ---------
```

#### Section 13.2, paragraph 3
```
-    Beware, that this mechanism solves linkability issues between Relying
-          -
-    Parties, but does not prevent traceability by Issuers.
-          -
```

### Section 1.4, paragraph 1
```
    Representing statuses with bits in an array is a rather old and well-
    known concept in computer science and there has been prior work to
    use this for revocation and status management such as a paper by
    Smith et al. [smith2020let] that proposed a mechanism called
    Certificate Revocation Vectors based on xz compressed bit vectors for
    each expiration day and the W3C bit Status List [W3C.SL] that
    similarly uses a compressed bit representation.
```
This section-as-sentence could be chunked for easier parsing:

>  Representing statuses with bits in an array is a rather old and well-
>  known concept in computer science. There has been prior work to
>  use this for revocation and status management. For example, a paper by
>  Smith et al. [smith2020let] proposed a mechanism called
>  Certificate Revocation Vectors based on xz compressed bit vectors for
>  each expiration day. The W3C bit Status List [W3C.SL]
>  similarly uses a compressed bit representation.

### Grammar/style

#### "URI", paragraph 6
```
ementers should be particularly careful for the correct parsing and decoding
                                ^^^^^^^^^^^
```
The usual collocation for "careful" is "with", not "for". Did you mean "careful
with"?

#### Section 9.2, paragraph 1
```
s, since they can be used for denial of service attacks on clients. A client
                              ^^^^^^^^^^^^^^^^^
```
It appears that hyphens are missing.

#### Section 12.1, paragraph 1
```
or a query parameter that allows these kind of historic lookups as described
                                ^^^^^^^^^^
```
The plural determiner "these" does not agree with the singular noun "kind".

#### Section 12.4, paragraph 1
```
n rates close to 0% or 100% create lowest sizes while revocation rates close
                                  ^^^^^^
```
A determiner may be missing.

#### Section 12.4, paragraph 2
```
50% and random distribution create highest sizes) * the lifetime of Referenc
                                  ^^^^^^^
```
A determiner may be missing.

#### Section 13.5, paragraph 5
```
., "status_list"). The name is case sensitive. Names may not match other reg
                              ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 13.7, paragraph 13
```
., "status_list"). The name is case sensitive. Names may not match other reg
                              ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 14.1.1, paragraph 1
```
meters. The registry records a human readable label, the bit representation a
                              ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 14.2, paragraph 2
```
The name is a human-readable case insensitive label for the Status Type that
                              ^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 14.4.1, paragraph 2
```
5.7.3). This OID is defined in section Section 10. IANA is requested to regis
                              ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 16.2, paragraph 15
```
atus List The following example uses a 8-bit Status List (256 possible value
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### "C.4.", paragraph 4
```
the new ttl claim * clarify the sub claim of Status List Token * relax stat
                                ^^^^^^^^^
```
This word is normally spelled as one.

#### "C.4.", paragraph 4
```
Change typo in Status List Token sub claim description * Add access token as
                                  ^^^^^^^^^
```
This word is normally spelled as one.

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-oauth-status-list-15
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-15.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to John Levine for the ARTART review.

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

Thanks for the work on this document. I have a few DISCUSS issues which I think are easily addressed.
All of my issues are around the use of SHOULD and RECOMMENDED.

### Status Label

956        It is RECOMMENDED to use status for the label of the field that
957        contains the Status CBOR structure.

Keeping in mind that I am not familiar with ISO mdoc, why is this RECOMMENDED? Will there be an interoperability failure
if an implementer does not follow this advice? Or is this just a common practice? If it is just a practice, can this be
a non-normative "recommended"?

### Status Type Values

1112      This document creates a registry in Section 14.5 that includes the
1113      most common Status Type values.  Applications SHOULD use registered
1114      values for statuses if they have the correct semantics.  Additional
1115      values may be defined for particular use cases.  Status Types
1116      described by this document comprise:

Why is this a SHOULD and not a MUST? Is there some circumstance when type VALID is to be used when INVALID is more appropriate?

### Status List Request

1145      The Status Provider SHOULD provide Status List Token on an endpoint
1146      serving an HTTP GET request to the URI provided in the Referenced
1147      Token, unless the Relying Party and the Status Provider have
1148      alternative methods of distribution.

Can this be a MUST as well? If there is no other pre-arranged distribution method, would it be acceptable for the
status list to be available in any other method than HTTP GET?

1155      The Relying Party SHOULD send the following Accept HTTP Header to
1156      indicate the requested response type unless the Content-Type of
1157      Status List Tokens in the respective ecosystem is known or the
1158      Relying Party supports both formats:

1160      *  "application/statuslist+jwt" for Status List Token in JWT format

1162      *  "application/statuslist+cwt" for Status List Token in CWT format

1164      If the Relying Party does not send an Accept Header, the response
1165      type is assumed to be known implicitly or out-of-band.

Is this using something other than normal HTTP content negotiation? If not, I think it is better to
identify the media types for the status list formats and defer to how HTTP does content
negotiation.

### Security Guidance

1482      A Status List Token in the JWT format SHOULD follow the security
1483      considerations of [RFC7519] and the best current practices of
1484      [RFC8725].

1486      A Status List Token in the CWT format SHOULD follow the security
1487      considerations of [RFC8392].

Why aren't these a MUST? Is there something in those considerations that would cause interoperability problems?

### Redirection

1557      HTTP clients that follow 3xx (Redirection) class of status codes
1558      SHOULD be aware of the possible dangers of redirects, such as
1559      infinite redirection loops, since they can be used for denial of
1560      service attacks on clients.  A client SHOULD detect and intervene in
1561      infinite redirections.  Clients SHOULD apply the guidance for
1562      redirects given in Section 15.4 of [RFC9110].

Why aren't these MUST? Is there a reasonable scenario in which a client is advised to be unaware of infinite redirection loops, etc...?

[Ballot comment]
Thanks for the work done in this document even if I wonder why it is a OAUTH WG document as its potential scope is broader than OAuth... and while OAUTH charter inclues `guidance on encoding state
information`, it rather seems to indicate a BCP or an operational informational document.

Is there a reason why the media type registration is linked to an author rather than to the I-D ?

Med Boucadair has valid points about the use of RECOMMENDED/SHOULD in the I-D.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I have a couple of comments/queries to share:

1) [IANA.JOSE] is cited as a normative reference without any reference to it.

2) I am not sure if the multiple IANA registries listed as references are normative. Please check if they are more suited as informative.

[Ballot comment]
Hi Tobias, Paul, and Christian,

Thank you for the effort put into this document.

# Overall, the document is well-organized and various pieces are adequately grafted together. Some cross referencing would be even better to link some of goals to how these are actually addressed in the current design, especially for the following ones:

CURRENT:
  *  the specification shall favor a simple and easy-to-understand
      concept

  *  the specification shall be easy, fast and secure to implement in
      all major programming languages

  *  the specification shall be optimized to support the most common
      use cases and avoid unnecessary complexity of corner cases

  *  the Status List shall scale up to millions of tokens to support
      large-scale government or enterprise use cases

  *  the Status List shall enable caching policies and offline support

# The implementation section (which is actually an Operational Consideration section per RFC5706) is really great. Thanks.

# The use of SHOULD through the document is worth checking. There are clearly cases where it is not trivial if this is a nice-to-have or why a stronger level isn't used, e.g., loop detection or the following:

  *  ttl: RECOMMENDED.  The ttl (time to live) claim, if present, MUST
      specify the maximum amount of time, in seconds, that the Status
      List Token can be cached by a consumer before a fresh copy SHOULD
      be retrieved. 

There many such occurrences that I’m not listing here, but I’d request you double check through.

# I tagged some few nits when reviewing the document that I will send you in a PR.

Cheers,
Med

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-oauth-status-list-13. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are nine actions which we must complete.

First, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at:

https://www.iana.org/assignments/jwt/

three new JSON Web Token Claims are to be registered as follows:

Claim Name: status
Claim Description: A JSON object containing a reference to a status mechanism from the JWT Status Mechanisms Registry.
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 6.1 ]

Claim Name: status_list
Claim Description: A JSON object containing up-to-date status information on multiple tokens using the Token Status List mechanism.
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 5.1 ]

Claim Name: ttl
Claim Description: Time to Live
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 5.1 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the JWT Status Mechanisms registry. The new registry will located in the JSON Web Token (JWT) registry group located at:

https://www.iana.org/assignments/jwt/

The registry will be managed via Specification Required as defined by RFC8126. The registry will contain a note indicating that registrations require a three-week review period on the jwt-reg-review@ietf.org mailing list and that a registration template is available in [ RFC-to-be; Section 14.2.1 ]. There is a single initial registration in the new registry as follows:

Status Mechanism Value: status_list
Status Mechanism Description: A Token Status List containing up-to-date status information on multiple tokens.
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 6.2 ]

Third, in the CBOR Web Token (CWT) Claims registry located at:

https://www.iana.org/assignments/cwt/

three new Web Token Claims are to be registered as follows:

Claim Name: status
Claim Description: A CBOR structure containing a reference to a status mechanism from the CWT Status Mechanisms Registry.
JWT Claim Name: status
Claim Key: [ TBD-at-Registration ]
Claim Value Type: map
Change Controller: IETF
Reference: [ RFC-to-be; Section 6.1 ]

Claim Name: status_list
Claim Description: A CBOR structure containing up-to-date status information on multiple tokens using the Token Status List mechanism.
JWT Claim Name: status_list
Claim Key: [ TBD-at-Registration ]
Claim Value Type: map
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 5.2 ]

Claim Name: ttl
Claim Description: Time to Live
JWT Claim Name: ttl
Claim Key: [ TBD-at-Registration ]
Claim Value Type: unsigned integer
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 5.2 ]

IANA notes that the authors have requested Claim Keys of 65535, 65533 and 65534 for these registrations.

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, a new registry is to be created called the CWT Status Mechanisms. The new registry will be located in the CBOR Web Token (CWT) Claims registry group located at:

https://www.iana.org/assignments/cwt/

The registry will be managed via Specification Required as defined by RFC8126. The registry will contain a note indicating that registrations require a three-week review period on the cwt-reg-review@ietf.org mailing list and that a registration template is available in [ RFC-to-be; Section 14.4.1 ]. There is a single, initial registration in the new registry as follows:

Status Mechanism Value: status_list
Status Mechanism Description: A Token Status List containing up-to-date status information on multiple tokens.
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 6.3 ]

Fifth, a new registry is to be created called the OAuth Status Types registry. The new registry will be located in the OAuth Parameters registry group located at:

https://www.iana.org/assignments/oauth-parameters/

The registry will be managed via Specification Required as defined by RFC8126. The registry will contain a note indicating that registrations require a two-week review period on the oauth-ext-review@ietf.org mailing list and that a registration template is available in [ RFC-to-be; Section 14.5.1 ]. There is are five, initial registrations in the new registry as follows:

Status Type Name: VALID
Status Type Description: The status of the Referenced Token is valid, correct or legal.
Status Type value: 0x00
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 7 ]

Status Type Name: INVALID
Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled.
Status Type value: 0x01
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 7 ]

Status Type Name: SUSPENDED
Status Type Description: The status of the Referenced Token is temporarily invalid, hanging or debarred from privilege. This state is usually temporary.
Status Type value: 0x02
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 7 ]

Status Type Name: APPLICATION_SPECIFIC
Status Type Description: The status of the Referenced Token is application specific.
Status Type value: 0x03
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 7 ]

Status Type Name: APPLICATION_SPECIFIC
Status Type Description: The status of the Referenced Token is application specific.
Status Type value: 0x0B-0xOF
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 7 ]

Sixth, in the OAuth Authorization Server Metadata registry located in the OAuth Parameters registry group located at:

https://www.iana.org/assignments/oauth-parameters/

a single new registration will be made as follows:

Metadata Name: status_list_aggregation_endpoint
Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management.
Change Controller: IESG
Reference: [ RFC-to-be; Section 9 ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Seventh, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

two new registrations will be made as follows:

Name: statuslist+jwt
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: statuslist+cwt
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Eighth, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Content Type: application/statuslist+cwt
Content Coding: -
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

IANA Comment -> Terminology nit; could "sub-registry" in section 14.8 be updated to "registry" and "Registry" to "registry group"?

Ninth, in the SMI Security for PKIX Extended Key Purpose registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single, new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-kp-oauthStatusSigning
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-11-11):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-oauth-status-list@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Token Status List (TSL)) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'Token Status List (TSL)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-11-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a mechanism called Token Status List
  (abbreviated TSL), data structures and processing rules for
  representing the status of tokens secured by JSON Object Signing and
  Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such
  as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc.  It also defines an
  extension point and a registry for future status mechanisms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  Yes, there was a strong support for this document from the WG.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Steffen Schwalm raised some concers realted to x509; Hannes and I met with Steffan
  to discuss his concerns, and we made it clear that x509 is out of scope for this WG.
  Steffen rescinded his opjection after that meeting.

  Denis raised a long list of issues, and the authors address some of them. Denis
  could not convince the WG to adopt the rest of his recommendation.

  Benjamin Kaduk raised some concerns about the Extended Key Usage OID, which the
  authors address in the latest version of the document.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


OWF sd-jwt-js
https://github.com/openwallet-foundation/sd-jwt-js

Adorsys status-list-server
https://github.com/adorsys/status-list-server

Bundesdruckerei issuer
https://github.com/Bundesdruckerei-GmbH/pid-issuer/tree/main/status-list-service-0.1.11

eudi-wallet-it-python
https://github.com/italia/eudi-wallet-it-python/tree/main/pyeudiw/status_list

Janssen Auth Server
https://docs.jans.io/head/janssen-server/auth-server/endpoints/session-status-list/

Cedarling PDP
https://github.com/JanssenProject/jans/pull/11520



## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  The document defines JOSE and COSE representation. Many COSE WG participants
  are also OAuth WG participants and reviewed the COSE part of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No applicable.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No applicable.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There was a review of the CBOR CDDL part:
  https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/270



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is clearly needed, as this is on of the document EUDI Wallet
  referencing and waiting for this to be published asap.

  I raised a number of issues during my shepherd review of v10 of this document,
  which were addressed in v11.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Security area review by the SecDir is always welcomed.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The requested RFC type is Standards Track, as this document defines a mechanism,
    data structures and processing rules for representing the status of tokens
    secured by JOSE or COSE, such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Christian
    https://mailarchive.ietf.org/arch/msg/oauth/gNTlymdl7WedpzeVV_OK1NNylvM/
   
    Tobias
    https://mailarchive.ietf.org/arch/msg/oauth/Puls0xr5WZY2bFu-Qnn55FHIRFc/

    Paul
    https://mailarchive.ietf.org/arch/msg/oauth/GYZAZMZiw34d5ubV6ssqkI7XS1g/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I raised few nits during my review of v10 which were addressed in v11.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    RFC6749 and RFC8414 should be a normative references, since section 9.1 has
    a normative text related to an OAuth Authorization Server and the usage of
    status_list_aggregation_endpoint for the metadata defined in RFC8414.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    No such references.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No chage of status of any existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
    The IANA Considerations section looks good to me for regitration with
    existing registries.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The following sections introduce new registries, and they look good to me:
    14.2.  JWT Status Mechanisms Registry
    14.4.  CWT Status Mechanisms Registry
    14.5.  OAuth Status Types Registry


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  Yes, there was a strong support for this document from the WG.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Steffen Schwalm raised some concers realted to x509; Hannes and I met with Steffan
  to discuss his concerns, and we made it clear that x509 is out of scope for this WG.
  Steffen rescinded his opjection after that meeting.

  Denis raised a long list of issues, and the authors address some of them. Denis
  could not convince the WG to adopt the rest of his recommendation.

  Benjamin Kaduk raised some concerns about the Extended Key Usage OID, which the
  authors address in the latest version of the document.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


OWF sd-jwt-js
https://github.com/openwallet-foundation/sd-jwt-js

Adorsys status-list-server
https://github.com/adorsys/status-list-server

Bundesdruckerei issuer
https://github.com/Bundesdruckerei-GmbH/pid-issuer/tree/main/status-list-service-0.1.11

eudi-wallet-it-python
https://github.com/italia/eudi-wallet-it-python/tree/main/pyeudiw/status_list

Janssen Auth Server
https://docs.jans.io/head/janssen-server/auth-server/endpoints/session-status-list/

Cedarling PDP
https://github.com/JanssenProject/jans/pull/11520



## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  The document defines JOSE and COSE representation. Many COSE WG participants
  are also OAuth WG participants and reviewed the COSE part of the document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No applicable.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No applicable.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There was a review of the CBOR CDDL part:
  https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/270



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is clearly needed, as this is on of the document EUDI Wallet
  referencing and waiting for this to be published asap.

  I raised a number of issues during my shepherd review of v10 of this document,
  which were addressed in v11.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Security area review by the SecDir is always welcomed.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The requested RFC type is Standards Track, as this document defines a mechanism,
    data structures and processing rules for representing the status of tokens
    secured by JOSE or COSE, such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Christian
    https://mailarchive.ietf.org/arch/msg/oauth/gNTlymdl7WedpzeVV_OK1NNylvM/
   
    Tobias
    https://mailarchive.ietf.org/arch/msg/oauth/Puls0xr5WZY2bFu-Qnn55FHIRFc/

    Paul
    https://mailarchive.ietf.org/arch/msg/oauth/GYZAZMZiw34d5ubV6ssqkI7XS1g/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I raised few nits during my review of v10 which were addressed in v11.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    RFC6749 and RFC8414 should be a normative references, since section 9.1 has
    a normative text related to an OAuth Authorization Server and the usage of
    status_list_aggregation_endpoint for the metadata defined in RFC8414.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    No such references.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No chage of status of any existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
   
    The IANA Considerations section looks good to me for regitration with
    existing registries.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The following sections introduce new registries, and they look good to me:
    14.2.  JWT Status Mechanisms Registry
    14.4.  CWT Status Mechanisms Registry
    14.5.  OAuth Status Types Registry


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/