Fully agree to Denis. Recommend to do the changes before publication
Von: Denis <denis.i...@free.fr>
Gesendet: Montag, 7. April 2025 21:20
An: Steffen Schwalm <Steffen.Schwalm@msg.group>; Kristina Yasuda
<yasudakrist...@gmail.com>; ANTHONY NADALIN <nada...@prodigy.net>
Cc: torsten=40lodderstedt....@dmarc.ietf.org; oauth <oauth@ietf.org>
Betreff: Re: [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 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 is
cryptographically signed and protects the integrity of the Status List.
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 is temporarily
invalid, hanging, debarred from privilege. This state is 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 or Issuer.
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 transactions
involving the same Referenced Tokens by comparing the status claims
of the Referenced Token and therefore determine that they have interacted
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 documents 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 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.
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 RECOMMENDED to 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 double allocation
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 double allocation.
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 the Status
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><mailto:yasudakrist...@gmail.com>
Gesendet: Mittwoch, 2. April 2025 00:22
An: ANTHONY NADALIN <nada...@prodigy.net><mailto:nada...@prodigy.net>
Cc:
torsten=40lodderstedt....@dmarc.ietf.org<mailto:torsten=40lodderstedt....@dmarc.ietf.org>;
oauth <oauth@ietf.org><mailto: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<mailto: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<mailto:40lodderstedt....@dmarc.ietf.org>
<torsten=40lodderstedt....@dmarc.ietf.org<mailto:40lodderstedt....@dmarc.ietf.org>>
Sent: Tuesday, April 1, 2025 11:38:22 AM
To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>; Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com<mailto: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<mailto: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<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
