Thank you for the discussion and addressing my concerns. And thanks again for the work on this document.

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.

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.

Thank you for addressing my previous DISCUSS and COMMENTs.

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

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.