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

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

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 <[e-mail]> 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 <
> [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]
>>
>