Code change:
8.1. To obtain the Status List or Status List Token, the Relying Party <del> MUST send a HTTP GET request to the Status List Endpoint. Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </del> <ins> MUST send an HTTP GET request to the URI provided in the Referenced Token. If the Status List is provided by an HTTP endpoint (and not as a Status List Token), the provider of the Status List MUST utilize TLS. Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type:

Related discussion:
text: "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