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> 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 HTTPThe 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 statesColluding 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
|
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
