[OAUTH-WG] Re: Call for adoption - PIKA

But the core problem is all of the trust frameworks, like federation, roll their own conditions and freshness/revocation mechanisms. In other words if the same attributes from one trust framework were passed to an alternative framework, it is likely to fail. There is no interop even under

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tue Jun 11, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Thank you Rifaat and Arndt and also Paul, Cristian, Kristina and Oliver for their valuable questions (many of those embedding the answer in the smart way they use to do). In particular for the github issues and the actions that me and other author will be able to achieve, like: - optioanlly

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Rohan, I'ìm very bad in giving answers, I have to live with this, please accept my excuse (it is almost certainly an attention disorder, autism or something). Therefore here I try the Take 2. > Today relying parties verify the issue domain indirectly by opening a TLS connection to the https

[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations

Hey D Il giorno mer 12 giu 2024 alle ore 13:54 Denis ha scritto: > Hi Giuseppe, > > Thank you for your response that was sent rather early today. :-) > > This draft might be paving the way for *a* solution that might be adopted > for the EUIDW > ... or even paving the way for *THE* solution

[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations

Thank you LanLan Pan, Orie is the (co-)author of both the specifications, therefore I would invite him to say something in this field. I heard about the Bloom filters and I can say that they should not be excluded from the analysis and comparisons (here Giada may say somethign more ...). At this

[OAUTH-WG] Re: Call for adoption - PIKA

Hi, This is all interesting in terms of a larger view of big picture goals of authentication, but you didn't answer my question. Today relying parties verify the issue domain indirectly by opening a TLS connection to the https URL of the issuer, which involves an X.509 validation of the issuer

[OAUTH-WG] Re: Call for adoption - PIKA

This depends on the evaluation criteria of the verification you conduct with a subject. We can agree that the initial verifiable evidence that a Trust Anchor/CA has issued a certificate for a subject is the first indication that the subject belongs to a

[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations

Hi Giuseppe, Thank you for your response that was sent rather early today.  :-) This draft might be paving the way for *a* solution that might be adopted for the EUIDW ... or even paving the way for *THE* solution that will be adopted for the EUIDW. The solution proposed in the draft is

[OAUTH-WG] Re: Call for adoption - PIKA

Giuseppe, Given that verifying the issuer is already done using X.509 PKI today, why do you object to trusting the PKI root for the same purpose (validating the domain name of the issuer) with the same validity period (between the notBefore and notAfter of the certificate)? Thanks, -rohan On

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Mike, "There is no code that understands X.509 certificates in most applications that use TLS". As Waston said, many platforms and libraries provide a way to verify a certificate outside of TLS. However, the whole point of PIKA is that it is an additional *choice* for people who *cannot* use

[OAUTH-WG] Re: Call for adoption - PIKA

I strongly support adoption. This solves important use cases, including messaging with federation. The draft is generally well written and is a very small additional option in-line with what is already done elsewhere. Thanks, -rohan On Mon, Jun 10, 2024 at 7:48 AM Rifaat Shekh-Yusef wrote: >

[OAUTH-WG] Re: Call for adoption - PIKA

Hi Mike, Richard already made my comment for me that the current TLS validation doesn't use the path. I want to focus on this comment of yours: "it’s odd to *require* an X.509 certificate to secure them" (emphasis mine). The point of this document is to provide a *choice*. You can continue to do

[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations

Hi Giuseppe, 2.4.5. > Bloom > Filters > > > Appendix B.2.7