Hi Christian, Thank you for your feedback.
A) About the title of this document: The current title of this document is: Token Status ListToday, for X.509 certificates, we use CRLs or OCSP. Tomorrow, for digital credentials (but not exclusively), we will use SLTs.
SLTs = Status List TokensA client does not fetch a "Token Status List" : it fetches a "Status List Token" that contains _*a*_ Token Status List. In the same way, for an X.509 certificate, a client fetches a CRL that contains the status of revoked or suspended certificates.
Unfortunately, "Status List Tokens" is not the title of this document. The title of this document should be changed into:
Status List Tokens B) For comments 1, 8, 12 , 15 and 16: I still believe that there is a problem with the vocabulary. The model you have in mind seems different from the model you have in mind.I consider that an Issuer handles multiple Token Status Lists, each one intended to be incorporated into a specific Status List Token. The issuer can decide the number of Referenced Tokens that will be carried into each Status List Token. It can increase this number at any time. It can group Referenced Tokens that have similar expiration times into different Token Status Lists that will be placed into different Status List Tokens.
For the comment 1, the current text is: Status List: An object in JSON or CBOR representation containing a compressed byte array that represents the statuses of many Referenced Tokens. It is not wrong by itself, but it can be misunderstood. I propose to clarify it : Status List: An object in JSON or CBOR representation containing a compressed byte array *_itself contained into a Status List Token _*that represents the statuses of many Referenced Tokens. C) For comment 8 (section 9): 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 client has no way "to fetch _*all *relevant Status Lists_ for a specific type of Referenced Token".
There is still a vocabulary problem between *Status Lists *and *Status List Tokens*.
The client has a way "to fetch relevant *Status List _Tokens_* for an Issuer without knowing (when only looking at the Status List Token) whether the Referenced Tokens contained in them are relative (or not) to a specific type of Referenced Token.
I would propose to change this sentence into:
Status List Aggregation is an optional mechanism that allows a
Relying Party to retrieve a list of URIs to Status List *_Tokens_*
relevant to an Issuer. It is up to the Issuer to decide whether
this list is the whole list of Status List Tokens or some subset of it.
D) A typo in section 8:
In the following section is described from the role of the Relying
Party, however the same rules would also apply for the Holder.
Change into:
In the following section_, *it *_is described from the role of the
Relying Party, however the same rules would also apply for the Holder.
E) For comment 8.
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.
The second sentence is still not understandable to me:
It is therefore recommended to use Status Lists for Referenced
Token formats that have similar unlinkability properties.
There is no recommendation to be done about the "formats of Status
Lists for Referenced Token(s?)". No change to Status Lists
contained in Status List Tokens (nor to Status List Tokens) is needed.
There is however a recommendation that can be done
for the presentation of Referenced Tokens by a Holder to a Relying Party. I would thus propose to replace this sentence by the following sentence: In order to prevent such a link, it is therefore recommended for a Holder to handle Referenced Tokens that will only be presented once to any Relying Party. F) Comment 12. There is still a vocabulary problem: In this case, every Referenced Token MUST have a dedicated Status List entry and MAY be spread across multiple *Status Lists*. This should be changed into: In this case, every Referenced Token MUST have a dedicated Status List entry and MAY be spread across multiple *Status List Tokens*.When a new version will be posted, I will take a look at them for the other comments.
Thank you again for your feedback. Best regards, Denis
Hi Denis,We went through your feedback and each point individually in https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/281. We didn’t agree with all points you made, but did a small editorial PR fixing some of them.Best Regards, Christian *From: *Denis <denis.i...@free.fr> *Date: *Monday, 7. April 2025 at 12:21*To: *Steffen Schwalm <Steffen.Schwalm@msg.group>, Kristina Yasuda <yasudakrist...@gmail.com>, ANTHONY NADALIN <nada...@prodigy.net> *Cc: *torsten=40lodderstedt....@dmarc.ietf.org <torsten=40lodderstedt....@dmarc.ietf.org>, oauth <oauth@ietf.org>*Subject: *[OAUTH-WG] Re: Second WGLC for Token Status List 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 TokenA 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 AggregationStatus 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 relevantStatus 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 section7. Section 12.5.2 states Colluding Status Issuer and Relying PartyA 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 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 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 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 thisfrom 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 itsReferenced 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 InformationIf 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 itselfThe 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; 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> 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
