Adding the OAuth WG to this thread. Regards, Rifaat
On Wed, May 15, 2024 at 7:52 AM Carl Wallace <c...@redhoundsoftware.com> wrote: > Here're a few questions/comments from a first read of > draft-ietf-oauth-status-list. Overall, the approach looks good to me. > > > > Should at least one of ttl and exp be required? Why is ttl not listed for > CBOR? Are both mechanisms needed? > > > > It mahy be worth including some words on using the uri field to partition > status lists based on token lifetime so status lists don't linger. The uri > field is similar to partitioning using the IDP/CDP mechanism in CRLs, so > any partitioning scheme could work, but mentioning the concept may be > helpful. > > > > Should there be a POST option for requesting a status list that provides > for freshness via a nonce? If so, does this cause a need for delegation so > a token signing key need not be online (i.e., maybe some identifier in the > status claim in the referenced token)? This would make GET requests > analogous to partitioned CRLs and POST requests analogous to OCSP with a > nonce, with the extra benefit that both use the same format. > > > > The mechanism is simple, which is good, but the lack of a time value > corresponding to revocation time may limit applicability. If JWTs/CWTs > replace certificates where signature validation is well after generation, > is a revocation mechanism needed that supports similar support for grace > periods, verification relative to times in the past, etc? It may be worth > noting cases where this mechanism may not be a good fit for such use cases > even if not addressing. A POST request that accepted a time value may serve > this purpose with no change to the status list definition, i.e., just > return the response relative to the requested time instead of current. > > > > *From: *Spasm <spasm-boun...@ietf.org> on behalf of "Tschofenig, Hannes" > <hannes.tschofenig=40siemens....@dmarc.ietf.org> > *Date: *Friday, May 3, 2024 at 3:28 AM > *To: *"sp...@ietf.org" <sp...@ietf.org> > *Cc: *Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > *Subject: *[lamps] Revocation and OAuth > > > > Hi all, > > > > At the last two IETF meetings I mentioned that the OAuth working group is > looking into various “token” revocation mechanisms and there is a strong > similarity with the work done in the PKIX environment. See also my HotRFC > presentation at IETF118: Can we improve certificate/JWT/CWT revocation? > (ietf.org) > <https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-can-we-improve-certificatejwtcwt-revocation-00> > > > > Rifaat and I want to make sure that we take the experience from LAMPS into > account. Hence, we have scheduled a dedicated interim meeting on the topic > of revocation, see > > [OAUTH-WG] Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tue > Jun 11, 2024 12pm - 1pm (EDT) (oauth@ietf.org) > > > > It would be great if some of you could join the interim meeting. > > > > Ciao > Hannes > > > > _______________________________________________ Spasm mailing list > sp...@ietf.org https://www.ietf.org/mailman/listinfo/spasm >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
