) needed, and issue occurs for AES/ASeal too.
Best
Steffen
*Von:*Christian Bormann
*Gesendet:* Donnerstag, 27. Februar 2025 16:41
*An:* Michael Jones ; Brian Campbell
; Filip Skokan
*Cc:* oauth
*Betreff:* [OAUTH-WG] Re: Status List Feature Request
*Caution:* This email originated from
I agree with Hannes that X.509 extensions need to be done in LAMPS, because
that is where the expertise is.
thanks,
-rohan
On Wed, Feb 26, 2025, 08:48 Hannes Tschofenig
wrote:
> (chair hat off)
>
> Hi Filip, Hi all,
>
> this sounds like feature creep to me. I brought this work on status
> lists
Ayabu-aE4ghyk/edit#slide=id.g33a15d709f8_0_331
Best Regards,
Christian
*From: *Michael Jones
*Date: *Wednesday, 26. February 2025 at 18:05
*To: *Brian Campbell , Filip Skokan
*Cc: *Christian Bormann , oauth
*Subject: *RE: [OAUTH-WG] Re: Status List Feature Request
X.509 already has it
needn’t complicate this spec to add another one for X.509. -- Mike From: Brian Campbell Sent: Wednesday, February 26, 2025 4:46 PMTo: Filip Skokan Cc: Christian Bormann ; oauth Subject: [OAUTH-WG] Re: Status List Feature Request I concur
Skokan
Cc: Christian Bormann ; oauth
Subject: [OAUTH-WG] Re: Status List Feature Request
I concur with Filip's perspective.
On Wed, Feb 26, 2025, 4:21 PM Filip Skokan
mailto:panva...@gmail.com>> wrote:
I believe it is inappropriate and wildly out of scope for an oauth document to
d
I concur with Filip's perspective.
On Wed, Feb 26, 2025, 4:21 PM Filip Skokan wrote:
> I believe it is inappropriate and wildly out of scope for an oauth
> document to define X.509 extensions, which IIUC is needed in order to
> define the Status Claim for X.509? The important thing to make sure
(chair hat off)
Hi Filip, Hi all,
this sounds like feature creep to me. I brought this work on status
lists to the attention of the IETF LAMPS group, and there was zero
interest from the PKI community in this type of solution. The PKIX
community already has a wide range of established solutio
I believe it is inappropriate and wildly out of scope for an oauth document
to define X.509 extensions, which IIUC is needed in order to define
the Status Claim for X.509? The important thing to make sure is that the
document does not preclude a future X.509 extension being drafted (wherever
its ap
: Freitag, 7. Februar 2025 18:56
An: Steffen Schwalm
Cc: oauth@ietf.org
Betreff: Re: [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
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
*Gesendet:* Freitag, 7. Februar 2025 16:19
*An:* Christian Bormann
*Cc:* oauth
*Betreff:* [OAUTH-WG] Re: S
Hi Christian,
My opinion has been posted yesterday at:
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243
In a nutshell:
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
: Brian Campbell
Gesendet: Freitag, 7. Februar 2025 16:19
An: Christian Bormann
Cc: oauth
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
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 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
13 matches
Mail list logo
