Hi Mike, The intent here is to follow exactly the same security model as current HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery. With those mechanisms:
1. The only way the issuer is authenticated is via a certificate presented in HTTPS. 2. The only aspect of the URL that is authenticated is the domain name. In multi-tenant environments, whoever owns the domain name can speak for any tenants. Changing the first property would make this document non-interoperable, since it is no longer clear how the relying party is supposed to verify the PIKA signature. Changing the second property would require inventing some new PKI-ish thing that can authenticate more of a URL. Do you have some specific additional mechanism that you think needs to be accommodated here? If not, I would propose we follow the YAGNI principle, be specific, and if we need to extend later, we can do a follow-on spec. Otherwise it's just abstraction for abstraction's sake. Cheers, --Richard On Mon, Jun 10, 2024 at 12:14 PM Michael Jones <michael_b_jo...@hotmail.com> wrote: > While I’m generally supportive of the goals of this draft, I have issues > with the mechanisms proposed. Therefore, I believe that more working group > discussion is needed before adoption. > > > > If I were to do something along these lines, I would not use “x5c”. Other > than for TLS certificates, the OAuth and JOSE specs generally steer clear > of dependence upon X.509 certificates. Especially for a spec focused on > JWK Sets, it’s odd to require an X.509 certificate to secure them. > Instead, I’d do so by validating the signature made by the issuer. > > > > Also, the spec says: > > * The JOSE Header of the PIKA MUST contain an x5c field. The > > contents of this field MUST represent a certificate chain that > > authenticates the domain name in the iss field. The domain name > > MUST appear as a dNSName entry in the subjectAltName extension of > > the end-entity certificate. > > > > This talks about the domain name of the issuer, but not the path within > the issuer. In multi-tenant systems, issuers typically include path > components. When the issuer is https://example.com/tenant/123, what > would the DNSName entry be? The spec doesn’t say. > > > > Conclusion: Not ready for adoption > > > > -- Mike > > > > *From:* Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > *Sent:* Monday, June 10, 2024 4:47 AM > *To:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] Call for adoption - PIKA > > > > All, > > This is an official call for adoption for the *Proof of Issuer Key > Authority (PIKA)* draft: > > https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ > > > Please, reply *on the mailing list* and let us know if you are in favor > or against adopting this draft as WG document, by *June 24th*. > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
