Authors,
As the document shepherd, I have reviewed the Token Status List v10 and I
have the following comments:
Comments/Questions
==================
1.1. Example Use Cases
Token Introspection [RFC7662] defines another way to determine the status
of an issued access token, but it requires the party trying to
validate the state of access tokens to directly contact the token
issuer, whereas the mechanism defined in this specification does not
have this limitation.
This mechanism still requires the relying party to interact with the Issuer
or an entity that hosts the status of these tokens on behalf of the Issuer.
How is this interaction different from Introspection interaction?
4.1. Compressed Byte Array
1. The Status Issuer MUST define a number of bits (bits) of either
What is the purpose of the “(bits)” that follows the “number of bits”?
status[0] = 1
status[1] = 0
:
You might want to explicitly state what the values of 0 and 1 mean, or at
least reference section 7.1 that defines these values.
8.1. Status List Request
The HTTP endpoint SHOULD support the use of Cross-Origin Resource
Sharing (CORS) [CORS] and/or other methods as appropriate to enable
Browser-based clients to access it.
Maybe explicitly state that it is the Status Provider endpoint:
“The Status Provider HTTP endpoint SHOULD…”
I am assuming the above use of SHOULD is to address a use case where a
browser-based clients are not supported? If this is the case, then I think
it would be clearer if you explicitly state that.
The Relying Party SHOULD send the following Accept-Header to indicate
the requested response type:
• "application/statuslist+jwt" for Status List Token in JWT format
• "application/statuslist+cwt" for Status List Token in CWT format
What is the implicit type?
Why not a MUST to guarantee interop between the RP and the Status Provider?
8.2. Status List Response
If caching-related HTTP headers are present in the HTTP response,
Relying Parties SHOULD prioritize the exp and ttl claims within the Status
List Token over the HTTP headers for determining caching behavior.
The above implies that there are cases where the RP can prioritize the TTL
values in the HTTP headers. When can the RP do that?
9. Status List Aggregation
If a Relying Party encounters an invalid Status List referenced in the
response from the Status List Aggregation endpoint, it SHOULD continue
processing the other valid Status Lists referenced in the response.
Are there cases where the RP will not continue the processing of the rest
of the lists when it encounters an invalid list?
VICAL extension for ISO mDoc / mDL.
Add a reference to this extension.
This aggregation in JSON and the media type return SHOULD be
application/json.
Why is this a “SHOULD”?
10. X.509 Certificate Extensions
Since you have only one subsection, 10.1 Extended Key Usage Extension, you
might want to drop the subsection?
11. Security Considerations
11.1 Correct decoding and parsing of the encoded Status List
This section discusses implementation issues.
Should this be moved to section 13. Implementation Considerations?
13.2. Default Values and Double Allocation
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.
I am not sure that I understand what the above text is trying to say.
Why is initialization needed? Why is it RECOMMENDED? What does “most common
value” mean?
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.
Why does the first part use RECOMMENDED, while the second part uses MUST?
13.6. Status List Update Interval and Caching
“Both ttl and exp are RECOMMENDED to be used by the Status Issuer.”
This implies that a Status Issuer might not include any of these claims. If
this is the case, then what is the expected behaviour of the RP?
Nits
====
6.1. Status Claim
The claim contains members used to reference to a
Status List Token as defined in this specification.
Drop the “to” after “reference”
8. Verification and Processing
“In the following section is described from…”
Drop the “In” at the beginning of the sentence.
11.3 Key Resolution and Trust Management
or ecosystems that are planning ot make use of the Status List…
“ot” -> “to”
Regards,
Rifaat
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
