OAuth Virtual Interim Meeting 13.01.2025

Minute Taker: Hannes Tschofenig

Token Status List - Paul, Tobias, Christian

Paul starts with his slide deck and shows the background.

Christian reports about the working group last call feedback.

Hannes: Could you explain the separation of entities: issuer, status
issuer, status provider?

Christian explains the motivation.

Hannes: Could you add this motivation to the draft?

Christian: Will check whether the text contains the motivation already.

Hannes: Could you add references to prior work?

Rifaat: Can you post the links to the list?

Hannes: Sure. Here is the link:
https://www.ndss-symposium.org/ndss-paper/lets-revoke-scalable-global-certificate-revocation/

(There was also prior work in the W3C, which also seems to be based on
the "lets revoke" paper)
Denis: It is very important to separate the referenced token issue and
the status list issuer. I filed three issues before the meeting.

Christian continues with the feedback, including

• test vectors

Justin: We put test vectors on a website (for complex examples).
Consider additional resources beyond the RFC.

• partitioning

Hannes: Doesn't the partitioning happen automatically when token issued
for a specific domain are issued with the same lifetime?

Christian: We also have been thinking about this.

Denis: I sent a comment regarding the implementation consideration
section.
I suggest to issue token in advance and at random associate values in
the token. If you issue one-time-use tokens then you can reduce the
number of tokens. The holder should renew referenced token as soon as
they are re-used.

Christian: We are saying already that you should be issuing status list
of a decent size.

Paul: We cannot do much about the referenced tokens.

Hannes asked a question about the current implementation consideration
text and the recommended size of the status lists.

Paul and Christian responded and explained that there is no size
recommendation in the document since it will be dependent on the use
case.

• Short lived credentials

Christian: We should add text about short-lived credentials.

• Pre-defined status type values

Christian: There is value in having default status types defined.

Hannes: Should there a mechanism to discover the status types values?

Christian: This is currently out of scope.

Hannes: I would recommend to indicate that the value of 0 always
indicates "OK" and any value larger than 0 indicates a problem. I am
worried that status lists could be taken from one context to another
context.

• .well-known

Watson brought this issue up and we hope he can explain the issue. We do
not understand it.

Brian: do you need more than 2 status values?

Deb: In the PKIX case there is also suspended. Many enterprise systems
do not use suspended because it is too complex.

Hannes: Is the reason information used somewhere?

Deb: Because they leak information they are often not used.

Pieter: OK and Revoked is enough for a standarization and other values
could be used in deployments.

Paul: Are you saying that we should not use suspended?

Pieter: Yes, it sounds complicated. You should only define the values
you absolutely need. Minimize the values of status codes. I think we
should learn from the lessons Deb mentioned. If you want more than two
status values provide enough information to make an informed decision.

Denis gives an example of a lost phone where suspention could be used
for the case where it is not clear what the

Hannes agrees with Pieter. Did the parties interested in the suspend
value provide further feedback. It depends a bit on the use case for how
difficult it is to go from a suspended token to a valid token vs. to go
from a revoked token to a new token.

Denis: Revocation is made at the request of the issuer. User may request
other status.