Hi Rifaat and Hannes,
When are you going to post the URL to be used for the OAuth WG Virtual
Interim
- Revocation Drafts @ Tue Jun 11, 2024 12 pm - 1pm (EDT) ?
The title of Hannes "Hot presentation" was : "Can we improve
certificate/JWT/CWT revocation?
The last slide mentions :
Your experience is needed!
• Is this a useful concept [i.e., Status Lists ] ?
• If it is useful for JWTs/CWTs, should it be applied to X.509
certificates as well?
• Is there room for improvement?
Come to the OAuth WG and tell us!
I already answered to these kinds of questions to the OAuth WG on
29/03/2024:
I posted both to the OAuth mailing list and to the SPICE mailing list a
message under the topic "SPICE Revocation"
https://mailarchive.ietf.org/arch/msg/oauth/39dFi890Y76ntjjAHkuuWdq8YAo/
Note that the approach I am proposing is *only applicable when digital
identity wallets are being used*.
In other words, it only applies to the three roles model: Issuer,
Holder, Verifier.
This approach originates from a "/privacy and security by design/"
construction, where *all the components of the ecosystem* are being
considered.
At each PDCA rotation, a privacy principle is being considered so that
at the next rotation of the PDCA wheel, one or more security solutions
can be added to address it ... as well as additional components when
needed.
The approach I am proposing is applicable whatever kind of "token" is
being used, as long as a digital credential has been issued by an issuer
and a digital proof derived from that digital credential has been
locally constructed by a holder (application).
Hence, this approach is independent from the encoding of the digital
proof. The token can be JSON or CBOR encoded or, why not, ASN.1/DER
encoded.
To summarize :
Is the Status Lists a useful concept ? My answer is : no.
Should it be applied to X.509 certificates as well? My answer is : no.
Is there room for improvement? My answer is : yes, indeed. It is
possible to get rid of Status Lists and to use a different approach.
Denis
Note: I have not subscribed to the lamps mailing list.
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)
<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 https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
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
