Hi Unfortunately I didnt see and I still do not see any of my comments and or requests for change acquired after the first call for adoption and not even in this second one
Waiting for a new draft I am therefore sad and forced to not support the current state of PIKA draft Il mar 3 set 2024, 15:04 Giuseppe De Marco <demarco...@gmail.com> ha scritto: > 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
