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

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

Hi,

I appreciate the introduction of PIKA, which demonstrates a commitment to
addressing current challenges. However, I have identified some key areas of
concern that need attention:

1. The current documentation lacks clarity regarding the number and scope
of cryptographic keys, particularly in terms of their intended use across
different protocols. Given that an issuer can serve multiple roles, such as
an authorization server, a credential issuer, or a relying party issuing
signed request objects, it is important to consider the benefits of using
distinct, specialized keys for different protocols and roles and how PIKA
would propose a model to achieve this.

2. We already have a mechanism to bring multiple public keys, for multiple
scopes/protocols, in a chain of signed JWT. This is OpenID Federation which
doesn't depend to X.509 but at the same time is able to distribute also
X.509 certificates using the `x5c` claim within the jwk claims and for
legacy applications. I believe that this last point is important, since I
see X.509 as a requirement only for legacy applications. I would not design
a new infrastructure using X.509 as a foundamental requirement for a trust
framework.

3. I kindly suggest to clarify which is the meaning/intention of the term
trust, from which kind of perspective PIKA aims to approach the mechanisms
of the trust evaluations and for which trust topology (federative, end to
end, hybrid ...), the roles of the trust authorities or trusted third
parties and so on.

4. I read that PIKA reuses the same requirements of openid federation.
Probably this needs more clarifications. OpenID Federation provides a
mechanism to establish the trust to a subject and obtain its public keys
and not only this, since it allow a secure interoperability through a
secure metadata exchange and also the distribution of compliance assertions
called trust marks.

5. The trust model proposed in PIKA relies fundamentally on a WWW CA
(Certificate Authority) for purposes beyond its original design.
Specifically, assessing compliance with shared rules, such as a trust
framework or national regulations, falls outside the scope of WWW X.509
CAs. Consequently, using this type of binding to establish a higher level
of trust may not be appropriate. The use of the term "trust" in this
context could potentially be misleading. It would be beneficial to
reconsider the terminology and mechanisms used to better align with the
intended functions and limitations of the technologies employed.

therefore,

I would therefore suggest defining the terms trust and trust model, and the
purposes of the specification in relation to these.
Then list the problems that this specification intends to solve and the
requirements identified by it.

If it is trust and the mechanisms for validating trust in relation to
common elements or properties between different entities (and mutual
recognition) we could start working on common elements already well
established in openid federation and that they could be further explored
with your contribution and requirements.

>From my side, I find the use of openid federation as a broad-based solution
evident. Today I am having a positive conversation with other authors about
the birth of two new drafts dedicated to openid federation and I believe
that this is a good time to join forces to build something together with
strong harmonizations, not just some endpoint picking.

>From my perspective Iam probably more interested in understand what
obstacles you have found in using federation and what additional features
or endpoints you intend to use to satisfy your requirements that, in fact,
I would mark with greater determination within the draft.

Even If I read it with pleasure and curiosity, appreciating the work and
the effort spent of it, I look forward to receiving more information here
in this thread from the pika's authors.
Currently, I am hesitant to support this specification as it requires
additional time and comparative analysis before I can evaluate it
positively.

Thank you for sharing and for the work made todate
Giuseppe

Il giorno lun 10 giu 2024 alle ore 13:48 Rifaat Shekh-Yusef <
[e-mail]> ha scritto:

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