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]. 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]> 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]>
*Sent:* Wednesday, February 11, 2026 11:42 AM
*To:* Paul Bastian <[email protected]>
*Cc:* [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]> 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]> 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]> 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]> 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]> 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]>
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]
To unsubscribe send an email to
[email protected]
--
SPICE mailing list -- [email protected]
To unsubscribe send an email to
[email protected]
--
SPICE mailing list -- [email protected]
To unsubscribe send an email to
[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]
To unsubscribe send an email to [email protected]
--
SPICE mailing list -- [email protected]
To unsubscribe send an email to [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./*
