Thank you very much for being willing to share your thoughts more fully, Brian. That is very generous of you. I will respectfully disagree, but I will not try to persuade you (unless you would like to discuss it more privately). We’re all entitled to our opinions. Thank you again.
Pierce CONFIDENTIAL From: Brian Campbell <[email protected]> Sent: Monday, February 16, 2026 1:41 AM To: Pierce Gorman <[email protected]> Cc: Paul Bastian <[email protected]>; [email protected]; oauth <[email protected]> Subject: Re: [SPICE] Re: CBOR/CWT parts in OAuth Token Status List You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> That's a fair question, Pierce, and it's certainly possible that my reasoning is perfectly clear in my own mind but I've not articulated it well or at all outwardly. If my wife was asked, she'd probably say that it is, in fact, highly likely that I've not been clear about something that's in my head. I'll try and explain my thinking a bit more. Yes, it's highly annoying when standards are unavailable without paying for them. But it's more than that. There's an entire process of non-transparent and access-restricted development of those standards that precedes the pay-to-view publication model. Do we really want to provide tacit endorsement of that model through what is effectively a link to a publisher's product page? Obviously, I do not. I'd further suggest that it is not the job of Token Status List (TSL) to help a reader gain a broader understanding of the technology and standards landscape. Readers that find their way to TSL without knowledge of ISO/IEC 18013-5:2021 will be just fine without learning of the opportunity to pay to see ISO/IEC 18013-5:2021 from TSL. And readers that already know about ISO/IEC 18013-5:2021 have no need for TSL to inform them of it. On Wed, Feb 11, 2026 at 11:22 AM Pierce Gorman <[email protected]<mailto:[email protected]>> wrote: Dear Brian, I am genuinely interested in your thinking. I’ve read numerous posts from you and always appreciate your thoughtful candor. I must apologize for commenting in the middle of a thread I haven’t followed completely. I agree that standards which are unavailable without paying for them is annoying. Sometimes highly annoying. Nevertheless, such standards exist and some are very important. I think the ISO mDL/mDoc standards qualify for that designation. i.e., behind a paywall, and yet still very important. I think it is the latter qualification which merits their mention in other relevant standards, including standards developed in the IETF. I understand that you object to having them being referenced in an IETF standard, but I don’t understand why. The exclusion inhibits a reader from gaining a broader understanding of the technology and standards landscape that would be easily enhanced by what I consider to be a harmless inclusion. Apologies again in advance for perhaps asking you to explain something you’ve perhaps explained ad nauseum already (too many times?). Respectfully, Pierce Gorman CONFIDENTIAL From: Brian Campbell <[email protected]<mailto:[email protected]>> Sent: Wednesday, February 11, 2026 11:42 AM To: Paul Bastian <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [SPICE] Re: CBOR/CWT parts in OAuth Token Status List I apologize for any lack of clarity in my previous messages. To be direct, I am requesting the removal of the ISO/IEC 18013-5:2021 references. I have made specific suggestions on the pull request<https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/350> to reflect this. On Mon, Feb 9, 2026 at 6:30 PM Brian Campbell <[email protected]<mailto:[email protected]>> wrote: My perspective on non-transparent, access-restricted standards development and fee-gated publication models has not changed since last week https://mailarchive.ietf.org/arch/msg/spice/nYhBMowGdrKeW6BgWqf1t9svRjI/, and I again suggest that there be no references to such specifications at all. I am well aware, by the way, that some work with which I'm closely involved has reference to ISO/IEC 18013-5:2021. RFC9901/SD-JWT mentions it here https://datatracker.ietf.org/doc/html/rfc9901#section-10.1-10 <https://datatracker.ietf.org/doc/html/rfc9901#section-10.1-10> but basically just says "this also exists and has the same limitations" while SD-JWT VC mentions it here https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-14#section-11 but as just one of a list of many credential formats. The context of both feels less like any endorsement of the paywalled ISO document. Although this conversation has me reconsidering some and thinking the mention in SD-JWT VC could be further contextualized as such or even removed. On Sun, Feb 8, 2026 at 2:40 PM Paul Bastian <[email protected]<mailto:[email protected]>> wrote: Hi all, I don't mind mentioning all of them: https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/350 If anybody want's to add a non-normative example for SD-CWT, feel free to do so. Otherwise I would merge this in the next days and we can move this forward hopefully. Best regards, Paul On 2/6/26 07:46, Rohan Mahy wrote: Hi, I have seen an implementation of SD-CWT with status lists, intended for production use at scale. Yes, as long as SD-CWT is not a normative reference, you can mention it in the draft. It will be described in the Informative References as draft-ietf-spice-sd-cwt-xx (work in progress), and if anyone clicks on a link in status lists or goes to the datatracker looking for SD-CWT using the draft name, they will find the document even after it becomes an RFC. And yes, as an author of SD-CWT, please include a reference in status list. thanks, -rohan On Thu, 5 Feb 2026, 12:31 Paul Bastian, <[email protected]<mailto:[email protected]>> wrote: Hi Brian, in the most recent version, we: - removed the examples for ISO mdoc, it is merely named as a possible type of Referenced Token - we removed the occurence of SD-JWT VC and replaced it with SD-JWT, as this makes it more widely applicable and SD-JWT is a final RFC compared to SD-JWT VC - we already have CWT in the draft as an explicit example - following this line of though, I'm not in favor of referencing SD-CWT, because it is not final, is it even possible to mention SD-CWT unless it is final? Best regards, Paul On 2/3/26 22:20, Brian Campbell wrote: In full disclosure, I have expressed concerns about scope (eg https://mailarchive.ietf.org/arch/msg/oauth/suJmeCHxLPhV9htUQEuzVcmUbrA/ and https://mailarchive.ietf.org/arch/msg/oauth/ZB-yrl3XDzo58hVyn16_gwPCQWM/) but setting that aside here and assuming the scope won't change. From the SPICE WG perspective, wouldn't it be preferable to use SD-CWT (IETF SPICE's representation of digital credentials with selective disclosure secured using COSE) as the example rather than mDoc (ISO/IEC JTC 1/SC 17/WG 10's representation of digital credentials with selective disclosure secured using COSE)? On Thu, Jan 22, 2026 at 3:11 AM Christian Bormann <[email protected]<mailto:[email protected]>> wrote: Hi Orie, Thanks for the feedback! Yeah the SD-JWT VC part is a fair point. My understanding would be that SD-JWT is more on the level of the container format whereas SD-JWT VC is a concrete credential format with additional/pre-defined semantics. I was under the impression that SD-JWT (or JWT for that matter) would not be the best level to introduce a status mechanism since status is usually bound to the semantics of a concrete use-cases / instantiation (like a credential or for example an access token). Our intention is definitely that everyone that wants to use this mechanism can use it and our definition is not bound to SD-JWT VC but rather on the JWT (or CWT for that matter) payload level. We used SD-JWT VC and mDoc (ISO 18013-5) as examples since those are two drafts that are describing in their respective documents how to use status list as a status mechanism in their context. We tried to always make clear that mDoc and SD-JWT VC are examples and not normative in the draft. On the presentation of a Status List Token in combination with the respective credential/token: We also thought about this but that felt like something that needs to be defined on the exchange protocol level instead of this document. Best Regards, Christian On 16. Jan 2026, at 15:06, Orie <[email protected]<mailto:[email protected]>> wrote: Hi, (as an individual). I considered this when I read the OAuth Token Status List draft. I do not see any issues: SD-JWT -> SD-JWT (as referenced token) + JWT (as Status List Token) -> presentation with key binding and status list revocation. SD-CWT -> SD-CWT (as referenced token) + CWT (as Status List Token) -> presentation with key binding and status list revocation. I don't understand why the OAuth draft focuses on "VC" instead of just SD-JWT, ... as you can see above, without that focus the translation is perhaps a bit more intuitive. Let me highlight some similarities and differences to SD-JWT, and perhaps others might see issues: After verification, the SD-CWT claimset IS a CWT Claimset (all the SD stuff gets removed as part of the verification process)... This means we should not have any challenges regarding claims. SD-CWT presentation format is a KBT that wraps the SD-CWT... this is different from the ~ or json encoding for SD-JWT VC. I don't think that creates any issues, but it did make me wonder why the holder could not just present the status list token to the verifier, and let the verifier decide if it was fresh enough. Another difference between CBOR and JSON flavored tokens to watch out for is aud, in CBOR its singular.... I don't see any mention of aud in your draft, so this probably does not matter. In SD-CWT we used kcwt (Confirmation Key CWT), when I read the oauth draft I wondered if there might be CBOR use cases where this was used with status lists where the collision could be an issue, but none came to mind immediately... and JOSE does not have an equivalent iirc. Hopefully this is helpful, TLDR, I don't see any issues. Regards, OS On Fri, Jan 16, 2026 at 7:43 AM Christian Bormann <[email protected]<mailto:[email protected]>> wrote: Hello SPICE WG, We are currently finalising the OAuth Token Status List draft (https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/). While the draft started with only JSON-based representations, upon request we added a CBOR/CWT based variant. We are aware that CBOR/CWT-related work is typically the domain of the SPICE or ACE WGs and outside of OAuth. However, given that the draft consists of an encoding-agnostic core data model and only adds JSON and CBOR encoding on top, we felt that this adds more benefits for using a consistent method across these two common data representation formats, which have a history of shared standards. The CBOR-specific parts are currently a rather small part of the overall draft and mirror the JSON-based definitions. Are there any concerns with the current situation of including the CBOR/CWT parts in the draft? Could you please provide feedback on the situation and our proposal to keep the CBOR/CWT parts in the current draft, preferably within ~2 weeks. Best Regards, Christian + Paul + Tobias -- SPICE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- SPICE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- SPICE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. -- SPICE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- SPICE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
