Hi Christian,
IMO, the sentence proposed by Paul is confusing.
I still do not think that such a sentence is needed, but if you *really*
want to add some guidance, I would propose the following:
If a Relying Party chooses to validate a bunch of cached Status List
Tokens returned from the Status List Aggregation endpoint and
encounters an invalid SLT,
then it SHOULD skip that one and continue with the remaining
cached Status List Tokens. For every skipped SLT, if the Relying
Party is online, it SHOULD
attempt to fetch the relevant SLT online.
Denis
Hi Denis,
The current text does not imply that you should validate after
fetching, it simply states that whenever you are validating a bunch of
cached SLTs and encounter an invalid SLT, then you should skip that
one and continue with the rest.
I don’t think we should say anything other than that and the current
sentence does not hinder implementations to validate SLTs on demand /
when needed.
Best regards,
Christian
On 7. Jul 2025, at 11:57, Denis <denis.ietf=40free...@dmarc.ietf.org>
wrote:
Hi Paul,
Unfortunately, this change proposal does not address my concern.
I have the following approach in mind:
The Relying Party fetches all the Status List Tokens mentioned at the
Status List Aggregation endpoint. It does not verify any signature at
this time.
When later on, it needs to verify the status of a Referenced Token,
it looks whether one of these Status List Tokens contains the status
of this Referenced Token.
If it is the case, the Relying Party then validate it, including its
signature.
If the Relying Party encounters an error while validating this Status
List Token, it does not continue processing the other Status List
Tokens, but,
if it is online, it attempts to get the relevant Status List Token.
I still prefer to remove this sentence. However, if you really want
to add a sentence, I would propose the following:
If a Relying Party encounters an error while validating a Status
List Token returned from the Status List Aggregation endpoint, if
it is online,
it SHOULD attempt to get the relevant Status List Token online.
Denis
Hi Denis,
we changed Line 842 to: "If a Relying Party encounters an error
while validating one of the Status List Tokens returned from the
Status List Aggregation endpoint, it SHOULD continue processing the
other Status List Tokens."
This removes any indication whether this is happening during
fetching or during runtime and hopefully addresses your concerns.
Best, Paul
On 7/4/25 19:24, Denis wrote:
Hi Paul,
In the Editor's copy, the abbreviation "TSL" does not yet
appear. It should be inserted into the document, as well as in the
title:
*Token Status List (TSL)*
*Line 840:*
- Status List Aggregation is an optional mechanism to retrieve
a list of URIs to all Status List Tokens, allowing a Relying
Party to fetch all relevant Status List Tokens for a specific
type of Referenced Token or Issuer.
This mechanism is intended to support fetching and caching
mechanisms and allow offline validation of the status of a
reference token for a period of time.
+ Status List Aggregation is an optional mechanism offered by
the Issuer to publish a list of one or more Status List Tokens
URIs, allowing a Relying Party to fetch Status List Tokens
provided by this Issuer.
This mechanism is intended to support fetching and caching
mechanisms and allow offline validation of the status of a
reference token for a period of time.
This change is fine for me.
*Line 842:*
- If a Relying Party encounters an invalid Status List Token
referenced in the response from the Status List Aggregation
endpoint,
it SHOULD continue processing the other valid Status Lists
referenced in the response instead of fully aborting processing
and retrying later.
+ If a Relying Party encounters an error while validating
Status List Token referenced in the response from the Status
List Aggregation endpoint,
it SHOULD continue processing the other valid Status Lists
referenced in the response instead of fully aborting processing
and retrying later.
This change is still not fine for me.
As already said, processing options should be left open. Fetching
does not imply or mandate any validation. If validation were done
at caching time, this would slow down the process.
Validation can be done either asynchronously at any time *after*
the caching or at the time of use of a TSL. There are many ways to
take advantage of the caching and hence recommanding a given way
would not be appropriate. For example, the signature of a Status
List Token can only be validated when it contains the reference of
the Referenced Token. As another example, all Status List Tokens
can be validated
asynchronously in the background, in particular when a
multi-processor environment is available. In this way, if the
processing is complete, Status List Tokens from the Status List
Aggregation endpoint are already validated.
The simplest way to solve this issue is to remove this sentence.
Denis
Hi Denis,
responses inline. We intend to merge this PR by Monday before IETF
cutoff.
On 6/30/25 08:34, Denis wrote:
Hi Paul,
Three replies are embedded into the text.
Our proposed changes are in this PR:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295
On 6/20/25 13:06, Paul Bastian wrote:
Hi Denis,
I've responded to your issues in detail in this Github issue:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/294
I also copied my answers inline as well.
A PR will follow later today.
Best regards, Paul
On 6/9/25 09:06, Denis wrote:
Hi Rifaat,
I have 10 comments.
1) There are still a few vocabulary issues that relate to
confusion between "Token Status Lists" and "Status List Tokens".
This is addressed in subsequent comments.
2) The title of the document is "Token Status List". There is
no single "Token Status List".
The goal of this document is to allow the retrieval of
Status List Tokens, where each Status List Token (SLT)
contains a Token Status List that provides up-to-date
status information on several Referenced Tokens.
The acronym "SLT" should be introduced in the document, in
the same way as the acronym "CRL"
has been introduced for "Certificate Revocation List" (RFC
5280).
The title of this document should rather be: Status List
Tokens (SLTs)
The name "Token Status List" of the draft makes sense:
* the naming is similar to Certificate Revocation List -
read: Revocation List for Certificates, here the same:
Status List for Token
* Token is a very common term in the OAuth ecosystem, similar
to "Certificate", so the naming sequence is exactly the
same as CRL
* the Status List Token is still its own thing, it's defined
in the section 5 and covers how a Status List structure
from Section 4 is integrty/authenticity-protected, however
a Status List Token is usually not relevant from the
high-level outside look
Conclusion:
* I agree that it makes sense to establish an official
abbreviation like CRL
o I think that TSL makes more sense
* Status List Token should remain as an internal terminology
apart from TSL
Denis: OK. Let we add the acronym TSL.
3) The current text in section 6.1 (Status Claim) is:
By including a "status" claim in a Referenced Token,
the Issuer is
referencing a mechanism to retrieve status information
about this
Referenced Token. The claim contains members used to
reference a
Status List Token as defined in this specification.
Other members of
the "status" object may be defined by other
specifications.
In this specification, only one member of the "status"
object is defined.
Taking into account the previous comment, I propose to
rephrase these sentences as follows:
By including a "status" claim in a Referenced Token,
the Issuer can
indicate in a "status" object, how status information
about a
Referenced Token can be obtained. This specification
defines one
member of the "status" object, called "status_list".
Other members of
the "status" object may be defined by other
specifications.
Partly accepted
4) The examples in sections 6.2 and 6.1 are confusing "status
lists" with "status list tokens".
The current text in section 6.2 ( Referenced Token in JOSE) is:
The following is a non-normative example of a decoded
header and
payload of a Referenced Token:
{
"alg": "ES256",
"kid": "11"
}
.
{
"status": {
"status_list": {
"idx": 0,
"uri": "https://example.com/statuslists/1";
}
}
}
The uri does not contain "statuslists" (status lists) but
"slts" (Status List Tokens).
The uri should be changed into the following way:
"uri": "https://example.com/slts/1";
The same comment applies to the example on page 22 within
section 6.3 (Referenced Token in COSE).
The URI is a non-normative example, so I don't believe it is
relevant. If other group members think this is important, we
may change this.
5) The current text in section 9 (Status List Aggregation) is:
9. Status List Aggregation
Status List Aggregation is an optional mechanism to
retrieve a list
of URIs to all Status List Tokens, allowing a Relying
Party to fetch
all relevant Status List Tokens for a specific type of
Referenced
Token or Issuer. This mechanism is intended to support
fetching and
caching mechanisms and allow offline validation of the
status of a
reference token for a period of time.
The wording "for a specific type of Referenced Token or
Issuer" should be avoided because the retriever of the SLTs
has no way to know whether the retrieved SLTs will be
about a "specific type of Referenced Token", about "all the
Referenced Tokens
issued by that Issuer" or about anything else. Depending
upon choices made by the Issuer, the retrieved SLTs may help or
*may not help* the Relying Party, depending upon the
context and the choices made by the Issuer.
The following rewording is proposed:
9. Status List Aggregation
Status List Aggregation is an optional mechanism that
allows to take advantage of an access to a given Status
List Token
referenced in a Referenced Token to retrieve other Status
List Tokens published by the same Issuer.
This feature is intended to support pre-fetching and
caching of Status List Tokens and allows offline
validation of the status
of further received Reference Tokens for a period of time.
The Section 9 on Status List Aggregation lists two mechanisms:
There are two options for a Relying Party to retrieve the
Status List Aggregation. An Issuer MAY support any of these
mechanisms:
Issuer metadata: The Issuer of the Referenced Token
publishes an URI which links to Status List Aggregation,
e.g. in publicly available metadata of an issuance protocol
Status List Parameter: The Status Issuer includes an
additional claim in the Status List Token that contains the
Status List Aggregation URI.
So while the Relying Party may not know whether an Issuer uses
a particular Status List Aggregation to link /all/ Status Lists
or only for a specific type of Referenced Token,
an Issuer has still the choice to do so, therefore the text is
correct in my opinion. Your proposed text removes functionality
that does not match the rest of Section 9.
Denis: Instead of:
Status List Aggregation is an optional mechanism to retrieve a
list
of URIs to all Status List Tokens, allowing a Relying Party to
fetch
all relevant Status List Tokens for a specific type of Referenced
Token or Issuer.
I propose:
Status List Aggregation is an optional mechanism that allows
to take
advantage of an access to a given Status List Token referenced in
a Referenced Token to retrieve other Status List Tokens published
by the same Issuer.
Relying Parties may not know whether an Issuer uses this
mechanism
to allow the retrieval of either all Token Status Lists that
it issues or
Token Status Lists specific to some types of Referenced Tokens.
This text does not remove any functionality.
I proposed the following changes:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/4fb1686ce19ea747a388be6d7433c30f5355bee1
6) The text continues with:
"If a Relying Party encounters an invalid Status List
referenced in
the response from the Status List Aggregation endpoint,
it SHOULD
continue processing the other valid Status Lists
referenced in the
response instead of fully aborting processing and
retrying later".
This sentence is misleading: the Status List Aggregation
endpoint does not contain "Status Lists" but contains "Status
List Tokens".
If corrected the quoted sentence, the sentence would become:
If a Relying Party encounters an invalid Status List
Token referenced
in the response from the Status List Aggregation
endpoint, it SHOULD
continue processing the other valid Status List Tokens
referenced in
the response instead of fully aborting processing and
retrying later.
However, when fetching the Status List Tokens, the
pre-fetching and caching mechanism does not *mandate* any
"validation mechanism",
hence the concept of an " invalid Status List" or of an "
invalid Status List Token" is irrelevant. The goal of this
mechanism is to allow
fetching SLTs and to place them into a cache without
*necessarily* verifying their "validity" at the moment of the
retrieval.
I propose to remove that sentence.
You are correct that it is slightly better to say Status List
Token here. Apart from this, I believe that validation at
caching time makes sense.
There are multiple options ins COSE and JOSE that require
fetching additional resources, like |kid| for |x5u|, that
wouldn't work
if you only pre-fetch Status List Tokens without validation?
Denis: Fetching does not imply or mandate any validation. If
validation were done at caching time, this would slow down the
process.
Validation can be done either asynchronously at any time *after*
the caching or at the time of use of a TSL. Options should be
left open.
I proposed the following changes:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/0e99662ec82b2e26001da537ae8ea19505c35198
End of replies.
PS: Since we will both attend the Global Digital Collaboration
Conference in Geneva on July 1 rst and 2 nd,
there will be an opportunity to meet together there.
7) Section 9.3 (Status List Aggregation in JSON Format) states:
9.3. Status List Aggregation in JSON Format
This section defines the structure for a JSON-encoded
Status List
Aggregation:
* status_lists: REQUIRED. JSON array of strings that
contains URIs
linking to Status List Tokens.
The Status List Aggregation URI provides a list of
Status List URIs.
(...)
The following is a non-normative example for media type
application/
json:
{
"status_lists" : [
"https://example.com/statuslists/1";,
"https://example.com/statuslists/2";,
"https://example.com/statuslists/3";
]
}
Given the confusion between "Status Lists" and "Status List
Tokens", the text from this section should be modified.
Below is a proposal:
9.3. Status List Aggregation in JSON Format
This section defines the structure for a JSON-encoded
Status List
Aggregation:
* status_lists: REQUIRED. JSON array of strings that
contains URIs
linking to Status List Tokens.
The Status List Aggregation URI provides a list of
Status List *Token* URIs.
(...)
The following is a non-normative example for media type
application/
json:
{
"status_lists" : [
"https://example.com/slts/1";,
"https://example.com/slts/2";,
"https://example.com/slts/3";
]
}
Accepted
8) Section 13.1 (Token Lifecycle) states:
13.1. Token Lifecycle
The lifetime of a Status List Token depends on the
lifetime of its
Referenced Tokens. Once all Referenced Tokens are
expired, the
Issuer may stop serving the Status List Token.
Referenced Tokens may be regularly re-issued to
mitigate the
linkability of presentations to Relying Parties. In
this case, every
re-issued Referenced Token MUST have a fresh Status
List entry in
order to prevent this from becoming a possible source
of correlation.
Referenced Tokens may also be issued in batches and be
presented by
Holders in a one-time-use policy to avoid linkability.
In this case,
every Referenced Token MUST have a dedicated Status
List entry and
MAY be spread across multiple Status List Tokens.
Revoking batch-
issued Referenced Tokens might reveal this correlation
later on.
The use of the sub-title 13.1 "Token Lifecycle " is
confusing as it can apply either to "Referenced Tokens" or to
"Status List Tokens".
The first sentence applies to "Status List Token Lifecycle"
but the next sentences apply to linkability issues using
indexes contained
in Status List Tokens. I propose to separate these two cases.
The following text is proposed:
13.1. Status List Token Lifecycle
The lifetime of a Status List Token depends on the
lifetime of its
Referenced Tokens. Once all Referenced Tokens from a
Status List Token
are expired, the Issuer may stop issuing the Status
List Token.
13.2. Linkability issues using indexes contained in
Status List Tokens
To mitigate the linkability of presentations of
Referenced Tokens to
Relying Parties using the index contained in a Status
List Token,
batches of one-time-use Referenced Tokens should be
issued by the
Issuer and each Referenced Tokens from the batch should
only be used
once by the Holder.
For each Referenced Token belonging to a batch of
one-time-use
Referenced Tokens, the indexes in the Status List
should not be
placed into the same Status List and hence into the
same Status List
Token, but spread among different Token Status Tokens.
In this way,
if the status of a batch of one-time-use Referenced
Token changes
simultaneously, it will be difficult to know whether
the Referenced
Tokens belongs to a batch of one-time-use Referenced
Tokens and to
which one.
Accepted to split the sections.
9) There is also an issue about the new IANA entries where the
"status" claim is defined
and where it is possible to place underneath the
"status_list" entry.
The definition of the Claim Name "status" in section 14.1.1
includes the following sentence:
* Claim Description: Reference to a status or validity
mechanism
containing up-to-date status information on the JWT.
A status or a validity mechanism does not *contain*
up-to-date status information.
It *describes* how status information is provided for a
given Referenced Token.
I suggest to change this sentence into:
* Claim Description: Reference to a status or validity
mechanism
describing how status information about a Referenced
Token can
be obtained.
Indeed the existing text is not ideal. I propose: "A JSON
object containing a reference to a status mechanism from the
JWT Status Mechanisms Registry."
10) Section 14.1.2 defines the Claim Name "status_list"
Claim Name: status_list
* Claim Description: A status list containing
up-to-date status
information on multiple tokens.
I propose to rephrase it in this way:
Claim Name: status_list
* Claim Description: A status list contained in a
Status List Token
providing up-to-date status information on several
Referenced
Tokens.
Indeed the existing text is not ideal. I propose: "A JSON
object containing up-to-date status information on multiple
tokens using the Token Status List mechanism."
Denis
All,
Please, review this version of the document and make sure
that your comments, if you had any, were addressed.
I will start working on the shepherd write-up in a week or two.
Regards,
Rifaat
On Fri, May 23, 2025 at 5:05 AM <internet-dra...@ietf.org> wrote:
Internet-Draft draft-ietf-oauth-status-list-11.txt is now
available. It is a
work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.
Title: Token Status List
Authors: Tobias Looker
Paul Bastian
Christian Bormann
Name: draft-ietf-oauth-status-list-11.txt
Pages: 72
Dates: 2025-05-23
Abstract:
This specification defines a mechanism, data
structures and
processing rules for representing the status of tokens
secured by
JSON Object Signing and Encryption (JOSE) or CBOR
Object Signing and
Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web
Token and ISO
mdoc. It also defines an extension point and a
registry for future
status mechanisms.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-11.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-status-list-11
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
