Original text:
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A <del> Status List may either be provided by an endpoint or be signed and </del>  embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic

Reviewer comments:
"endpoint" is still mentioned in there, unsure we we completely want to get rid of it
Section '8.1. Status List Request' currently states: This seems redundant when the endpoint is used to retrieve a Status List Token, as the Token's integrity is already guaranteed by requiring it to be signed using an asymmetric cryptographic algorithm. If requiring TLS was intended for providing confidentiality of the Token, this seems unnecessary. The endpoint is publicly accessible - there does not seem to be any client authentication mechanisms described for it - thus the Tokens could be retrieved by anybody.
Hi NAME , thanks for the feedback! I think you are correct that we could relax using TLS when a Status List Token is queried. However, if an unsigned Status List is returned, we need TLS as an integrity mechanism.
Yes I vehemently agree :) Btw, perhaps the issue is a bit broader that just permitting plain HTTP when obtaining Status List Tokens. I don't think it's currently explicitly stated in the specification whether a Status List Provider should/must simultaneously provide both plain Status Lists and Status List Tokens. Ie the standard states that an RP should use the Accept-Header to indicate the requested response type, but it does not specify what the Status List Provider should do if it is unable to provide the requested response type. I think this is somewhat relevant under this issue as: if you were to simply add a sentence to the spec permitting plain HTTP for Status List Tokens then an Issuer would have to decide whether to put an HTTP or HTTPS URI in the claim of the Referenced Token but this somewhat contradicts with the Accept-Header mechanism which would seem to indicate (to the reader of the spec) that it's up to the RP to choose the response type. Perhaps the Issuer should explicitly specify supported response type(s) in the claim of the Referenced Token? Ie there could be an additional attribute in the object under the claim specifying the supported formats. Such an attribute could prove beneficial in other regards as well. For example, I don't immediately see an use case where an Issuer/Status List Provider would be providing cbor/cwt Status Lists for JOSE Referenced Tokens.
Section mentions Status List Endpoint. The term is not mentioned elsewhere in the specification nor is it defined.
Thanks for the feedback. Discussion Editors Call: connected to the discussion whether Status List Provider is an entity that shall be described in the spec intend to clarify the term for next iteration

Revised text:
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A  <ins> Status List may either be provided via HTTPS or be signed and </ins> embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic