Hey Richard, My reply was very verbose, thank you for the time spent in reading it.
The problem I see in the communities around the openid/ietf/any-other technical specification is the way we use the term trust and how we aim to achieve trust from a technical perspective. I can show that my name is Giuseppe (subject id) and that you are talking exclusively with me (secure cryptographic material exchange and confidentiality in transaction) but this doesn't solve the problem we want to solve through a trust establishment, because identity and key attestations doesn't give us any trust. As mentioned by Mike, OpenID Connect Core implementations already uses TLS and subject id comparisons to achieve this. The example of the surgery made with the chainsaw is something already heard by architects that have implemented SAML2 and that reluctant to move to OAuth 2.0. They said <<useless complexity>> or <<all those endpoints only increases the attack surface>>. Several years was spent to demonstrate why OAuth 2.0 was designed in a way to satisfy several design principles about scalability and specialization of the endpoints to specific functionalities. I can only help, where needed or requested, to demystifying the complexity of the relationships willing to find trust (in this context, at least, from a technical pespective only) and be sure that who is going to create new specifications is aware of the previous ones, of the problem that he's trying to solve and recognize what is intentionally excluded from the scope. I would like to continue this conversation with the will to merge the openid federation approach and the PIKA that I see an important specification to create a bridge to the X.509 world. this also requires trust and reducing conflict between authors and consequently between specifications I believe is an intrinsic goal of our community. If I had a little more time... Il giorno mar 11 giu 2024 alle ore 05:09 Richard Barnes <r...@ipv.sx> ha scritto: > Hi Giuseppe, > > To be blunt, solving the use cases we're talking about with OpenID > Federation is like doing surgery with a chainsaw. You might achieve the > intended goal, but the results will be messy. > > The trust model we are addressing is one that already exists: A JWT is > issued by an issuer identified by a URL, and the relying party needs to get > keys that are verifiable associated with that issuer's URL. The only thing > we are doing is trading HTTPS for JWT signing for how that verifiable > association is made. It is explicitly *not* a federated model; X.509 is > already baked into it and does the job well. > > Your first point is a good one, though. It could be a good idea to have > an indicator here of how the issuer intends the keys to be used (for > issuing ID tokens vs. Verifiable Credentials, say). Happy to have that > filed as a first issue on an adopted document. > > Cheers, > --Richard > > > On Mon, Jun 10, 2024 at 6:50 PM Giuseppe De Marco <demarco...@gmail.com> > wrote: > >> 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 >> >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
