Hi Rohan, thanks for your feedback. Answers are inline:
On 06.02.25 02:21, Rohan Mahy wrote:
Hi,
I support the overall goals of this document. I do *not* think the
document was ready for WGLC; at minimum there are still plenty of TBDs
and TODOs in the text. Below are some comments:
We do not have any TODOs in the text. We have TBD in the text for values
that will be defined by IANA registry which is standard procedure in
other drafts as well.
1. I would prefer we make the document standards track instead of
informational.
This is correct, this draft has always been planned for the standards
track, we will fix the metadata to accompany for that.
2. You have to read through to section 6.2 to see how a verifier
determines the index of a token it receives in the status value array.
Please add one sentence in the Introduction saying that the index is
in the referenced token. You could even update the diagram to reflect
this.
This in incorrect, the introduction currently contains the following
text: "Each Referenced Token is allocated an index during issuance that
represents its position within this bit array. The value of the bit(s)
at this index corresponds to the Referenced Token's status." We like the
other idea, we will investigate the idea to add this to the diagram.
3. The document uses status_list (JSON object) and StatusList (CBOR
map) to refer to the map, but Status List seems to be used to refer to
both the compressed byte string (in Section 5) and the uncompressed
byte array of status values (in Section 4 step 2, and Section 4.1 2nd
sentence).
This is correct, we will separate, the parts of section 4 that talk
about the the uncompressed byte array into its own subsection and not
use the wording Status List for this. Otherwise, through out the rest of
the document, Status List refers to the compressed byte array as defined
in the terminology.
4. CRLs (Certificate Revocation Lists) are a list of the serial
numbers of every invalidated certificate (with a reason code). While a
compressed 1 or 2 bit status per token tends to be very compact per
issued token, it would be useful for the draft to show an analysis of
what percentage of issued tokens would need to be invalid before a
status list would be smaller than a CRL-like structure that only
references invalid indexes in a (possibly compressed) ordered list
(assuming randomly distributed invalidations).
I have not seen performance or comparative measures like this in many
other drafts, we have made analysis and performance measures for our
presentations at IEFT, for example here:
https://docs.google.com/presentation/d/1m59OC8uKM4nZ14aH2TM9r2mxEhOiP-G5uqzAZ7oOAUk/edit#slide=id.g2318b641e56_0_23
The comparison with the CRL depends on a bunch of parameters and
assumptions, so it's not that easy.
What does the working group think about including performance metrics
itself in the draft?
5. There is no discussion of maximum or recommended limits to the size
of a Status List. Starting ambitiously, idx is a JSON Number, so we
should probably follow the recommendation in
https://datatracker.ietf.org/doc/html/rfc8259#section-6 and say it
MUST NOT be larger than (2^53) - 1, but a 1-bit status list with that
many indexes would be 10TB with > 10:1 compression. I think the
document needs to define a reasonable maximum size, and could allow
profiles to make that smaller.
I haven't seen an guidance like this in CRL draft either and I believe
that our assumptions about reasonable sizes in 2025 will not hold in
2035, so I'm hesitant to add this kind of guidance.
6. I think it is a mistake to compress the entire status_list (JSON
object) or StatusList (CBOR map). Instead it would be better to
compress just the status value array (the "lst" field).
* Naive implementations might try to decompress the entire
object/map to get the bit field before trying to read the array.
* If you make the "lst" field an uncompressed byte string in JSON,
it will need to be base64url encoded *before* you compress it.
Then the status_list object would need to be base64url encoded
again. That's wasteful and accomplishes nothing as far as I can tell.
* Because JSON maps and CBOR maps are encoded differently,
compressing the object/map will make it hard to use a status list
across token encoding environments. If only the contents of the
"lst" field was compressed, it would allow an issuer to generate
JWT/CWT pairs with the same index and use one status list between
them. (both would be invalidated together).
I think this is a misunderstanding. The Status List from Section 4 is
already compressed in the Step 3. Section 4.1 about Status List in JSON
Format has an "lst" field that then contains the compressed byte array,
which must however be base64-encoded as JSON does not support. byte
array. Section 4.2 about Status List in CBOR Format has an "lst" field
that then contains the compressed byte array directly. I don't see how
we can be any more space-efficient than this. Therefore, JSON and CBOR
structures would contain the same Status List byte array.
Furthermore, we have test vectors in the Appendix, so that
implementations can verify correctness.
7. I am surprised by some details of the CBOR encoding:
* Traditionally, CWT maps have integer keys for comment values. Why
not replace "bits" with 1, and "lst" with 2?
* The document registers CWT claim keys 65534 and 65535. Why not ask
for unused numbers in the 24-256 range?
* It wasn't immediately clear from the text that the status list is
a bstr encoding of the compressed serialized map. If we implement
my recommendation in #6, this problem goes away.
- We have talked to people from the CBOR world and apparently this is
what people do today, e.g. in the ISO mdoc world, but we are open for
discussions here.
- We have talked to Mike Jones about this, who is one of the designated
experts for CWT and this was his recommendation
- We have the text: "|lst|: REQUIRED. Byte string (Major Type 2) that
contains the Status List as specified in Section 4
<https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#status-list>."
which clearly references bstr.
8. There should be a CDDL snippet for the CBOR. I would be happy to
provide one once points 6 and 7 are addressed.
If CDDL is requested and helps the understanding, then we can add this
to the draft.
9. I think it will be important for implementers to have some advice
on constructing a logical scope for Referenced Tokens to be
interoperable, so that issuers have good practices for recycling
indexes. For example if all the tokens with the same status list URL
have roughly the same duration of validity, cycling through URL paths
would eventually allow reuse after all previously referenced tokens
had expired.
Is it ok to generate a Status List for 100 tokens, then generate a new
Status List with the same "referenced token scope" that covers 200
tokens (including the first 100 tokens)? If so, that would be good to say.
We have some guidance here:
https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#name-referenced-token-lifecycle
saying "The lifetime of a Status List Token depends on the lifetime of
its Referenced Tokens. Once all Referenced Tokens are expired, the
Issuer may stop serving the Status List Token." We did not want to
encourage re-usage of indices, as this may introduce security issues.
10. NIT: Section 6.3 refers to status_list but I think you mean StatusList
The CWT status structure says: "Each data item in the |Status| CBOR
structure comprises a key-value pair, where the key must be a CBOR text
string (Major Type 3) specifying the identifier of the status mechanism
and the corresponding value defines its contents. This specification
defines the following data items:", so indeed "status_list" refers to a
CBOR text string.
Thanks,
-rohan
Thanks for your feedback. Best regards,
Paul+Christian
On Thu, Jan 2, 2025 at 5:53 AM Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com> wrote:
All,
This is a 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 *Jan 17th*.
Note that this document will be discussed during the OAuth WG
*interim* on *Jan 13th*.
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 tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
