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 < rifaat.s.i...@gmail.com> 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 -- 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
