GNAP interim meeting, 2021-10-05 Chairs: Leif Johansson and Yaron Sheffer Note taker: Peter Yee Justin Richer (Bespoke Engineering) gave an overview of topics and the what the editors are thinking along with a summary of some of the discussions on the mailing list and GitHub issue trackers. * Core draft update – last update has now been out for 1.5 weeks. Changes cover four areas: + The user handle syntax has been collapsed. The “extra”, special field is no longer needed. Now the client instance can send the opaque “subject information” identifier in place of the user handle. This was always possible, but now it is the only way. + Trust relationships – these are defined using promise theory. This doesn’t change the requirements, but it does change how we do it. The interactions between the actors in the protocols are specified. Denis Pinkas (DP Security Consulting) doesn’t agree that the text defines a trust relationship. ISO defines a trust relationship as between entities for specific interactions. He has his own Internet-Draft that has a different take on the trust model and would like to see it considered here. Fabien Imbault (acert.io) says this is initial text, so there may be missing relationships. Client to authorization server is a complex relationship, so it hasn’t yet been included. Richer doesn’t feel that the ISO trust relationship model is the only valid model and he feels that the one in the core Internet-Draft has its own advantages. He admits that more work is needed to complete its description. Adrian Gropper (HIE of One) asks whether it would make sense to consider a zero-trust architecture (ala NIST) and discuss that explicitly in the document. Richer says that zero-trust architectures are brilliant, but that’s not what’s being talked about here. Zero-trust in his mind is pre-establishing trust based on an authority. What’s in this document is a different concept: what those relationships mean after they have been formed. Gropper feels that zero-trust introduces many concepts that are relevant to the core protocol, although the document doesn’t have to use the zero-trust terms to describe them. Pinkas wants Richer to discuss attribute vs. capability models; Richer said this has been discussed before. + Security considerations have been added in the form of 21 subsections. This is the initial cut; more are expected. This is a very wide look at potential security considerations given this is a security protocol. Trade-offs in using various features such as bearer tokens are considered as well, so that informed choices can be made. Input is requested to fill in unknown holes. Pinkas feels the document is incomplete because it doesn’t define the structure of an access token, therefore it is only a framework. Yaron Sheffer requested that Pinkas bring up his own Internet-Draft on the mailing list instead of relitigating issues outside of the topics being discussed. + Privacy considerations have also been fleshed out, noted Aaron Parecki (Okta). They have been modeled like RFC 6973 to the extent it applies to this specification. The main topics covered are surveillance (client, authorization server), stored data, intrusion, correlation (by clients, resource servers, authorization servers), and disclosure in shared references. This section shows how GNAP relates to each of these topics. Sheffer asks whether we know that the formalism in the trust relationships is actually being used by the teams and tools that are doing verification of such protocols. Imbault replied that this is an open discussion point. Trust is not just something you rely on; you can put some evaluations in your framework as well. Sheffer further asks if the editors thought there’s value in separate security and privacy considerations for the resource servers draft. Richer believes so - there are some different considerations for each. Richer does not want, however, to see a separate security document as was done in OAUTH. Pinkas doesn’t believe that the document actually follows RFC 6973 all that well. He was asked to bring up his concerns on the mailing list. * Open Issues + Symmetric Crypto – should symmetric crypto be completely disallowed? PQC is largely symmetric, so disallowing it might be problematic down the line. Input on issue #299 is requested. + SOLID use cases - this use case from the SOLID community can be divided into a couple of different cases, depending on whether the AS or the client instance gets the artifacts from the end user extension server. If the client does the work, it can preload the information, otherwise it is gated by its interaction with the AS. + End-user vs. resource owner (RO) – these can have different relationships even if they are the same person. Subject information is confusing when the RO isn’t the equal to the end user. + Generic HTTP access type – the access object’s type field is specific to the API being protected. It might make sense to use a generic HTTP type which would be applicable to far more APIs without additional definition. If the WG chooses to go down this path, where should it be done: gnap-core, gnap-resource-server, some other document, or even in some other forum? Is the WG interested in this idea? * What topics to focus on for IETF 112? The editors will have another revision of the core (and maybe the resource) draft before the meeting. Additional topics should be submitted to the mailing list for consideration. Pinkas asked for reconsideration of his end user information proposal in contrast to the current subject information. Sheffer assumes that the group will iterate on the security and privacy considerations sections before IETF 112, since there is a lot of work to do there. Gropper notes that IIW (Internet Identity Workshop) meets next week and asks that GNAP be well represented there.