Hi Steffen,
In the sentences below, the use of the word "attestation" looks
ambiguous, as it is commonly used in eIDAS 2.0 for EAAs.
However, when considering eIDAS 2.0, PKCs used for electronic signatures
purposes would be able to take advantage
of Status List Tokens.
I have a preference for a single RFC covering all aspects related to
Status List Tokens and hence covering end-entity X.509 PKCs,
(in addition to SD-JWTs and SD-CWTs).
Denis
As the Status List focus on revocation of attestations it directly
affects the revocation of attestation signature. Means if OauthWG
defines status list related to revocation of attestation but ignores
the one on the signature of the attestions – this sounds a bit weird.
Especially in case the signature is legally mandatory as given in
Annex V g) eIDAS regulation. (and as there´s no signature acc. eIDAS
using status list, this increase the effort for QTSP in eiDAS
significantly)
Means statulist would look a bit like a unfinished. But if somebody
else would finish – also fine
*Von:* Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>
*Gesendet:* Freitag, 7. Februar 2025 16:19
*An:* Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org>
*Cc:* oauth <oauth@ietf.org>
*Betreff:* [OAUTH-WG] Re: Status List Feature Request
*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.
That seems well beyond the scope of both the Status List draft and the
OAuth WG in general.
On Fri, Feb 7, 2025 at 2:57 PM Christian Bormann
<chris.bormann=40gmx...@dmarc.ietf.org> wrote:
Hi all,
While going through the feedback and issues on github, there was
one bigger discussion point that we would like to bring to the
mailing list. Steffen Schwalm asked for support for X.509
Certificate revocation with the Status List - in that case the
Status List describing the status of an X.509 Certificate
(relevant issue
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243).
That would mean defining an extension to X.509 to embed the
relevant information for a Status List (URI and index) and
creating validation rules etc.
While we understand the general motivation as is discussed in more
detail in the issue, it would be somewhat of a change of scope for
the Status List draft. We felt it might be out of scope of the
OAuth Working Group and rather in scope of other working groups
like lamps? Any comments/opinions would be appreciated!
Best Regards,
Christian Bormann
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
*/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly
prohibited. If you have received this communication in error, please
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./*
_______________________________________________
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
