Code change:
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 5.4. </del> <ins> 6.4. </ins> <del> TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy </del> <ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy </ins> <del> 5.5. </del> <ins> 6.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a <del> third party instead of the issuer reducing tracking possiblities </del> <ins> third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> <del> 6. </del> <ins> 7. </ins> This document has no IANA actions.

Related discussion:
text: NAME Whats' failing on the build here?
breaks the build All RFC references are resolved interally and linked
There are possible applications of this draft that go beyond just verifiable credentials, hence we do not want to use that term in this draft IMO. "Token" is already a term broadly used in this space e.g CWT and JWT both use it, "subject" was used in this context because it is also a term used heavily w.r.t tokens, feel free to suggest alternative terminology but at this point I think subject token is the best I've heard suggested.
can we simply use JWT/CWT instead of creating any kind of abstraction term like ? One person i asked for feedback associated with a token used to communicate a subject of an email.
or, bottomline, please stick to . is very confusing.
I'm with Tobias on this and prefer introducing a new term here. Otherwise things get really weird because the status list is also a JWT/CWT and a token. We need something that clearly separated the status list token and the other token. I think subject token is the best we have. Also subject is leaving towards what we have as credentialSubject in the VC world, so the term subject is kind of established in this context
I am really strongly against "Subject Token". Not only because it is not intuitive (I have been asking various people in this space and no one would associate what it trying to be conveyed), but we should not be introducing a new term in this already confusing ecosystem. Moreover, this status list mechanism can be used with a JWT/CWT that does not necessarily contain a subject (like SD-JWT-VC), so using a term subject because it is widely used is not a sufficient reason. Keep referring to it as a token, because this draft should not be opinionated about what is in the JWT/CWT whose status is being expressed should be fine, if a "status list JWT/CWT" is always referred as such. there are multiple occurrences where "status list JWT" is referred to simply as a JWT which should be fixed IMO.
We need clear terminology for: the status list token (i think this one fits pretty well) the credential / token that is bound to the status list I do believe only calling it token will cause confusion with the status list token.