I took a closer look to the document. Below are 17 comments. 1.The
current definition of a Status List is: Status List:An object in JSON or
CBOR representation containing a compressed byte array that represents
the statuses of many Referenced Tokens. This definition is ambiguous. It
is proposed to change this definition as follows: Status List:An object
in JSON or CBOR representation containing a compressed byte array itself
contained in a Status List Token that represents the statuses of many
Referenced Tokens. 2.In section 4.1: 3.The Status Issuer sets the status
values for all Referenced tokens within the byte array.This sentence is
ambiguous;. Change into: 3.The Status Issuer sets the status values for
all Referenced Tokens that are referenced in the Status List
Token.3.Section 5 states: Status List Token
A Status List Token embeds *_the_* Status List into a token that
iscryptographically signed and protects the integrity of the StatusList.
It would be more appropriate to use "a" instead of "the" and to say: A
Status List Token embeds *_a_* Status List into a token that is
cryptographically signed and protects the integrity of the Status List.
4.Section 7.1 is stating: Status Types Values *0x02 - "SUSPENDED" - The
status of the Referenced Token istemporarily invalid, hanging, debarred
from privilege.This stateis reversible. I would be worth to explain what
is meant by " This state is reversible". Change into: This state is
usually temporary. In a further issued Status List Token, this state may
remain the same, change to VALID, INVALID or to any other state.
5.Section 8.4, second paragraph states: To obtain the Status List Token,
the *_Relying Party_* MUST send an HTTP The Holder can also obtain a
Status List Token. Using the term" client" would cover both cases.
Change into: To obtain the Status List Token, the _*client*_ UST send an
HTTP 6.Section 9 states: 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 Lists
for a specific type of Referenced Token orIssuer. The concept of a
*specific type of Referenced Token* looks odd, as the "type" of the
Referenced Token is not present in the Status List. I have not yet
understood how a *client *can fetch "all relevant Status List Tokens for
a specific type of Referenced Token". I can understand how a how a
*client *can fetch "all relevant Status List Tokens for a specific Issuer".
"The Status List Aggregation URI provides a list of Status List URIs." I
would expect that it contains a list of Status List Token URIs, i.e. NOT
a list of Status List URIs. If all the URIs of the Status List Tokens of
a given Issuer are made publicly available, then there is a leakage of
information. The client would be able to know roughly how many
Referenced Tokens are currently issued. Issuers should be warned of the
consequences. This should be mentioned here as well as in the privacy
considerations section
7.Section 12.5.2 states Colluding Status Issuer and Relying Party A
Status Issuer and a Relying Party Issuer may link two
transaction*_s_*involving the same Referenced Tokens by comparing the
status claims of the Referenced Token and therefore determine that they
haveinteracted with the same Holder.It is therefore recommended to use
Status Lists for Referenced Token formats that have similar
unlinkability properties. This section is not understandable to me.
Would it be possible first to explain how the link may happen only by
using the SLT ? What means "similar unlinkability properties" ? I have
no idea. 8.One typo in section 12.8 (Status Types) This document*_s_*
defines ... 9.In section 12.8 again: Depending on the use-case,
suspended could for example provide information that an authorization in
the Token is suspended, but the token itself is still valid. No. If the
Token is suspended, it is not valid. Change proposal : Depending on the
use-case, suspended could for example provide information that an
authorization in the Token is suspended, which means that it should be
considered currently invalid. 10.The concrete example is biased.
"suspended could signal that it should not be considered valid in the
scope of being allowed to drive a car". No. Suspended does not mean that
the driver is no more allowed to drive a car. Suspended can be used
because the driver license has been lost or stolen and rather that
invalidating it immediately, the person can ask to the Issuer to suspend
it in order to prevent someone else to temporary use it. A status
different from VALID, INVALID or SUSPENDED should be used to signal that
the driver is no more allowed to drive a car. This example should either
be removed or modified. 11.In section 13.1 the text states: Referenced
Tokens may be regularly re-issued to mitigate thelinkability 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. This is not a good
recommendation. The next paragraph is a better solution.Correlation
would still be possible during some time-window. Please remove this
paragraph. 12.The text states: 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
Lists.Revoking batch-issued Referenced Tokens might reveal this
correlation later on. The first sentence is correct. The second sentence
would need to be reworded: In this case, every Referenced Token MUST
have a dedicated Status List entry and one-time use Referenced Tokens
SHOULD be spread across multiple Status List Tokens. In this way,
revoking batch-issued Referenced Tokens is unlikely to reveal a
correlation later on. 13.In section 13.3, the text states:
Implementations producing Status Lists are RECOMMENDED to initialize the
Status List byte array with a default value and provide this as an
initialization parameter to the Issuer.The Issuer is RECOMMENDEDto use a
default value that represents the most common value for its Referenced
Tokens to avoid an update during issuance. There is a confusion between
"Status Lists" and "Status List Tokens". The recommendation does not
take into account that some Referenced Tokens can be issued with the
status VALID while some others with the status SUSPENDED. Change into:
Implementations producing Status List Tokens are RECOMMENDED to
initialize the Status List byte array with a default value. Some
Referenced Tokens may be issued under the status VALID while some others
under the status SUSPENDED. Status List Tokens should be prepared in
advance with the relevant status. 14.The next paragraph states:
Implementations producing Status Lists are RECOMMENDED to prevent double
allocation, i.e. re-using the same uri and index for multiple Referenced
Tokens.The Issuer MUST prevent any unintended doubleallocation by using
the Status List. There is a confusion between "Status Lists" and "Status
List Tokens". Change into: Implementations producing Status List Tokens
are RECOMMENDED to prevent double allocation, i.e. re-using the same uri
and index for multiple Referenced Tokens.The Issuer MUST prevent any
unintended doubleallocation. 15.In section 13.3, the text states: The
Status List Issuer may increase the size of a Status List if it requires
indices for additional Referenced Tokens. In order to avoid a confusion
between "Status Lists" and "Status List Tokens", change into: The Status
List Issuer may increase the size of a Status List contained in a Status
List Token if it requires indices for additional Referenced Tokens.
16.Then after the text states: The Status List Issuer may divide its
Referenced Tokens up into multiple Status Lists to reduce the
transmission size of an individual Status List Token.Make a similar
change: The Status List Issuer may divide its Referenced Tokens up into
multiple Status List Tokens to reduce the transmission size of an
individual Status List Token. 17.In section 13.7, the text states:
Relying Parties avoiding correlatable Information If the Relying Party
does not require the Referenced Token and theStatus List Token after the
presentation, e.g. for subsequent status checks or audit trail, it is
RECOMMENDED to delete correlatable information, in particular: *the
status claim in the Referenced Token *the Status List Token itself The
Relying Party should instead only keep the relevant payload from the
Referenced Token. Deleting the Status List Token is not a good idea, as
the same Status List Token could be useful for another Referenced Token
checked later on. Change proposal: The Relying Party should only keep
the relevant payload from the Referenced Token. In particular, it should
not keep the status claim in the Referenced Token. Denis
I strongly oppose against moving forward the specification as Issues
still open.
1. There´s no documented decision on the well-known x509 issue –
beside the wishes of the authors
2. Still wait for information from chairs where and how to solve
issue when not in TokenStatusList
3. Means TokenStatusList contains privacy issue in case used for
Attestatiosn of attributes in eIDAS
*Von:*Kristina Yasuda <yasudakrist...@gmail.com>
*Gesendet:* Mittwoch, 2. April 2025 00:22
*An:* ANTHONY NADALIN <nada...@prodigy.net>
*Cc:* torsten=40lodderstedt....@dmarc.ietf.org; oauth <oauth@ietf.org>
*Betreff:* [OAUTH-WG] Re: Second WGLC for Token Status List
*Caution:* This email originated from outside of the organization.
Despite an upstream security check of attachments and links by
Microsoft Defender for Office, a residual risk always remains. Only
open attachments and links from known and trusted senders.
I support moving this specification forward. It is a crucial building
block for lifecycle management of different tokens/credentials.
On Tue, Apr 1, 2025 at 9:42 PM ANTHONY NADALIN <nada...@prodigy.net>
wrote:
support this moving forward as we need this in ISO
Get Outlook for Android <https://aka.ms/AAb9ysg>
------------------------------------------------------------------------
*From:*torsten=40lodderstedt....@dmarc.ietf.org
<torsten=40lodderstedt....@dmarc.ietf.org>
*Sent:* Tuesday, April 1, 2025 11:38:22 AM
*To:* oauth <oauth@ietf.org>; Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com>
*Subject:* [OAUTH-WG] Re: Second WGLC for Token Status List
Hi,
I support moving this spec forward.
best regards,
Torsten.
Am 24. März 2025, 13:41 +0100 schrieb Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com>:
All,
This is a *second WG Last Call* for the *Token Status List*
document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
Please, review this document and reply on the mailing list if
you have any comments or concerns, by *April 7th*.
Regards,
Rifaat & Hannes
_______________________________________________
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 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
