Hi, I used to support work made by other authors willing to find solution to common problems. I appreciate the efforts, the creativity and the passion I read within those specs lines under the current approval phase.
I am happy about the link between PIKA and OpenID Federation, and that one of the openid federation endpoint was used in PIKA. I ask a proper alignment to the federation historical keys endpoint, that, as already mentioned during my previous comments, was slighlty updated for reducing the complexity of the revocation reason definitions. Please keep it aligned if possibile for sake of consistency (even if in different specs). While for the stability of the contents I don't see any other change in the future on this federation endoint within the openid federation specs. I would ask to say within the text that the difference with the endpoint defined in openid federation is that PIKA includes also the active keys, while federation only requires inactive keys to be published in the endpoint response (unused, if expired or revoked or unknow reason). I ask to say this in PIKA to avoid confusion about the endpoint specific purposes. where implementations might require an additional level of assurance, I suggest to include also the parameter signed_jwks_uri, as registered in IANA for openid federation, providing a signed jwks, obviously signed using the same private key used for the historical key endpoint response (therefore verifiable with the public key contained in the x5c mentioned in the text). one of my comment, even if actually only a side comment between authors, is about scalability: while openid federation supports multiple ways to build a trust chain using one or more trust anchors, PIKA only uses a single X.509 certificate chain and also requires re-using the same cryptographic material already used for HTTP TLS if I got it well. In large scale deployments we used to not re-use https certificates for specific application protocols different from http but relying on top of it, such as SAML2, OIDC and or OAuth 2.0. This was because of different purposes and also for different cryptographic material issuance and expiration constraints, allowing http frontends managed by the A team to be autonomous in the lyfecycle of the key for TLS, while B team working on IAM infrastructure on the backend with other cryptographic materials. not at least, by not propagating the same cryptographic material upon multiple layers within the same infrastructure we aim to reduce the surface of attack againt any crypto material breach it seems that this is only my first revision, I hope that author's will continue doing their best to consolidate PIKA and with the contribution of all this community best Il giorno mar 3 set 2024 alle ore 12:49 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > All, > > As per the discussion in Vancouver, this is a 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 *Sep 17th*. > > 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
