WG Chairs, I support moving this draft forward.
Thanks, -dhs -- Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/> (he/him) Principal Engineer Office of the CTO Beyond Identity dean.s...@beyondidentity.com On Apr 7, 2025 at 11:10:03 PM, Steffen Schwalm <Steffen.Schwalm@msg.group> wrote: > 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 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 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> > <yasudakrist...@gmail.com> > *Gesendet:* Mittwoch, 2. April 2025 00:22 > *An:* ANTHONY NADALIN <nada...@prodigy.net> <nada...@prodigy.net> > *Cc:* torsten=40lodderstedt....@dmarc.ietf.org; oauth <oauth@ietf.org> > <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 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 to oauth-le...@ietf.org
