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

[Giuseppe De Marco <[e-mail]>]

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 <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>