Hi Russ and Tim,
In your quality of co-chairs of the LAMPS WG, I forward you a message
posted on the OAuth mailing list.
Your opinion about it would be appreciated.
On 20/02/2025 Paul Bastian wrote:
We've also resolved several issues in Github, one remaining issue is
on the question, whether X509 should be included as Referenced Tokens,
i.e. whether we should described how to do status management and
revocation of X509 Certificates with the Token Status List,
for details of the discussion see:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243 or
on the mailing list
https://mailarchive.ietf.org/arch/msg/oauth/_vc8RgYVMOl3ekRTFd7nbGyDo9c/
We plan to discuss this topic at the OAuth Security Workshop next week
in Reykjavik, additionally we would love some more input from the
working group/chairs
on this topic, if you can't participate next week in person, either
on the mailing list or in the Github issue.
Token Status Lists allow to get the status of a "Referenced Token". Its
contains the statuses of all "Referenced Tokens " issued by an Issuer
that are compacted in a very efficient way, when most of the "Referenced
Tokens " are valid. Originally, this mechanism has been created to obtain
the statuses of digital credentials encoded as a SD-JWT or as a SD-CWT.
However, this mechanism would also work for X.509 Certificates.
On the discussion #243, I wrote:
It should be noticed, that the LAMPS [Limited Additional Mechanisms for
PKIX and SMIME] charter (https://datatracker.ietf.org/wg/lamps/about/)
indicates:
In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WG.
The LAMPS WG may produce clarifications where needed, but the LAMPS
WG shall not adopt anything beyond
clarifications without rechartering.
Defining this extension in the current draft would be easier as the same
document would be able to support "Referenced Tokens"
encoded as JWT, CWT or ASN.1/DER.
Two approaches would be possible:
* to define an extension similar to "CRL Distribution Points" as
defined in RFC 5280, in section 4.2.1.13.
* to define an accessMethod OID similar to "id-ad-ocsp OBJECT
IDENTIFIER ::= { id-ad 1 }" as defined in RFC 5280, in 4.2.2.1.
Authority Information Access.
If developed by the LAMPS WG, this would require a rechartering of LAMPS.
If developed by the OAuth WG, this would be easier
... and this would be my preferred choice.
The last message posted on the discussion #243 by steffenschwalm,
proposes an Additional Section for the Token Status List Draft.
Would you have an opinion on this matter ?
Denis
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
