@Christian: If you want to replace certificates with JWT/CWT (in case using it for QEAA acc. Art. 45b ff.) it might be meaningful regarding validation (and so revocation subjects) to have look into current development of ETSI EN 319 102 (last version 03/24) which defines current signature validation and might be referenced by Art. 32 eIDAS
https://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.04.00_20/en_31910201v010400a.pdf (currently under discussion) regarding “is a revocation mechanism needed that supports similar support for grace periods, verification relative to times in the past, etc.?” – in case of signatures (referring to your idea to replace certificates) depends on validation model you choose (shell vs. chain) – means IMHO the “time value” depends on different values In case you need an actual time: Do you plan that your status list is signed (as done with OCSP)? Could not find it in your draft but maybe I have missed something. In case it`s signed incl. QTS you would have the timestamp you may think about. Only question: self-created timestamps or qualified one? Would recommend in this context to differentiate timestamps and metadata – and as timestamps (ETSI EN 319 421) contain signatures too it might lead to other challenges. The statement “the statuslist is a good approach for “simple” use-cases where the main thing you are interested in is a current status.” I don`t understand because in case of “chain-model” you need a status in the past and with OCSP/CRL Lists it`s easily possible or is you statement related to https://github.com/oauth-wg/draft-ietf-oauth-status-list? Von: Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org> Gesendet: Sonntag, 19. Mai 2024 20:49 An: 'Rifaat Shekh-Yusef' <rifaat.s.i...@gmail.com>; 'Carl Wallace' <c...@redhoundsoftware.com> Cc: 'Tschofenig, Hannes' <hannes.tschofenig=40siemens....@dmarc.ietf.org>; sp...@ietf.org; 'oauth' <oauth@ietf.org> Betreff: [OAUTH-WG] Re: [lamps] Revocation and OAuth Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk always remains. Only open attachments and links from known and trusted senders. Hi and thanks for the feedback! Here are my thoughts on the comments: Should at least one of ttl and exp be required? Why is ttl not listed for CBOR? Are both mechanisms needed? - I would say no - right now we require “iat” which allows a relying party to make an informed decision on whether the status list is fresh enough or not; the issuer can add additional policy / information by providing “exp” which is a freshness requirement from the issuer side and an optional signal with “ttl” that allows more optimal fetching/caching mechanism (a signal how fast/often updates can be expected – even if the information is not yet considered expired) - This was an oversight on our part (2 PRs in parallel – one introducing ttl, the other one the CBOR encoding) and is fixed in the latest editor’s copy (https://github.com/oauth-wg/draft-ietf-oauth-status-list) - Perhaps ttl isn’t the best name, but as mentioned before I do believe every claim serves its purpose It may 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. - That is a very valid point and should be part of implementation considerations. 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. - That sounds like an interesting concept to combine with a more OCSP-like approach (and there has been some demand in that direction - e.g., Giuseppe’s draft https://peppelinux.github.io/draft-demarco-oauth-status-attestations/draft-demarco-oauth-status-attestations.html) but needs more thought on my side for a proper answer. We provide the freshness currently with iat/exp, so I am not sure the nonce would be necessary or add additional value? 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. - We’ve gotten this feedback a few times and are considering to add an optional mechanism to provide time similar to what you are describing. Related issue: https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/138 - That being said, we reached a point where we realized that the different use-cases differ in terms of privacy considerations and overall requirements where it seems hard to create one approach that is a good fit for everything. The draft introduces “status” as an extension point for other status mechanisms that are better suited for other use-cases that e.g., require more metadata (like timestamps / more events) and we are considering adding an additional draft that works similar to a CRL (with an UUID and attached metadata) but in json/cbor form re-using parts of the statuslists draft. I do believe the statuslist is a good approach for “simple” use-cases where the main thing you are interested in is a current status. Especially the last point is something where more feedback/discussion would be quite helpful imho. Regards, Christian From: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>> Sent: Wednesday, May 15, 2024 2:14 PM To: Carl Wallace <c...@redhoundsoftware.com<mailto:c...@redhoundsoftware.com>> Cc: Tschofenig, Hannes <hannes.tschofenig=40siemens....@dmarc.ietf.org<mailto:hannes.tschofenig=40siemens....@dmarc.ietf.org>>; sp...@ietf.org<mailto:sp...@ietf.org>; oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: [OAUTH-WG] Re: [lamps] Revocation and OAuth Adding the OAuth WG to this thread. Regards, Rifaat On Wed, May 15, 2024 at 7:52 AM Carl Wallace <c...@redhoundsoftware.com<mailto: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<mailto:spasm-boun...@ietf.org>> on behalf of "Tschofenig, Hannes" <hannes.tschofenig=40siemens....@dmarc.ietf.org<mailto:40siemens....@dmarc.ietf.org>> Date: Friday, May 3, 2024 at 3:28 AM To: "sp...@ietf.org<mailto:sp...@ietf.org>" <sp...@ietf.org<mailto:sp...@ietf.org>> Cc: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com<mailto: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)<mailto:[OAUTH-WG]%20Invitation:%20OAuth%20WG%20Virtual%20Interim%20-%20Revocation%20Drafts%20@%20Tue%20Jun%2011,%202024%2012pm%20-%201pm%20(EDT)%20(oauth@ietf.org)> It would be great if some of you could join the interim meeting. Ciao Hannes _______________________________________________ Spasm mailing list sp...@ietf.org<mailto: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
