GNAP at IETF-109 --- Date: Nov. 17, 2020 Chairs: Leif Johansson and Yaron Sheffer Note takers: Dave Tonge, Bron Gondwana CodiMD for notes: https://codimd.ietf.org/notes-ietf-109-gnap Meetecho link: https://meetings.conf.meetecho.com/ietf109/?group=gnap Let's meet at Room 7 of [Gather](https://ietf.gather.town/app/L4fNNdm1NJa1sE2v/ietf) during and after the session! Agenda bashing: * no agenda bashing Agenda: * Proposed process and discussion: chairs * Core protocol: progress update, discussion of selected issues: editors * Next steps: chairs ### Proposed Process - Leif Johansson and Yaron Sheffer WG is final decision maker about content and process. Proposal to use Github and make use of RFC8874 and RFC8875. Use of Github is well understood, but issue management needs discussion. Clear from mailing list that participants want to use Github to manage issues. #### Proposal - Documents * Small editorial edits can be made via Pull Requests * Pull requests for all significant changes to be linked to issues, and can be publicised on the mailing list * Documents to be published at least once per IETF period * Github wiki/discussions are not a permanent record - if something should be preserved for posterity it needs to be published as an I-D. However discussions that are useful for the development of the specs are suitable for Github. #### Proposal - Issues * RFC8874 - Issue Discussion Mode * Long document reviews should be via the mailing list * After mailing list discussion, reviewer opens issues on Github * Further discussion takes place on Github * Editors to assign labels * Only editorial team to close/resolve issues - that are clearly resolved. * Issues that are more controversial should be taken to the list or a meeting before being resolved * There should be a PR specific to the issue so that WG members can review the final text * Issues should not be re-opened unless there has been a WG discussion and consensus to do so #### Discussion Fabien Imbault: Asking for feedback about the work on Terminology - should wikis or issues be used Justin Richer: Propose to address this question in the next session Dave Tonge: clarification -> are issues ONLY to be opened after discussion on the list? Yaron: would encourage new substantial issues to be first sent to the list and then linked to a discussion on github (minor editorial issues are fine on github only) Lucy Lynch: {meetecho audio issue} - am concerned about substantial work being stored on git alone. Github isn't under IETF control longterm. Supporting work that informs the work needs to be mirrored on the list. Leif: agree, but hope that the benefits outweigh the problems. There are 113 issues open right now. Yaron: it's important to have a record and sometimes people refer back to the discussion on the mailing list, but we can be a lot more efficient on github (and more inclusive) because people can work on issues they are interested in without being spammed by the whole thing. Dick Hardt: how are we going to link all the things? Might be good to link to the github issues when making points on the mailing list. Yaron: that's what I did for my own review - responded with links to the issues for each of the points that I raised. Dick: would be nice for when issues are reaching consensus, that this is brought back to the mailing list Leif: agree that this is a good way of working Roman Danyliw: Consensus must be on the mailing list ### Core Protocol, Editors Update - Justin Richer ##### Background: * This is not an extension to OAuth 2 * This is not OAuth 3 * OAuth 2 is not going anywhere, but it has its limits, this is an opportunity to move beyond OAuth 2 ##### Design Considerations: * Protocols for negotiating access * Methods for interacting with humans * Validating and verifying client software * Methods for binding keys to message requests * Data model of what's being requested ##### Current State: * Design team formed * Draft adopted by WG * 3 editors - job is to express and codify WG consensus * Lots of notes and decision points in current draft - these have now been opened as issues in Github * Some test implementations for the current draft are in the works ##### Design Team Output: * Single document which combined functional aspects of XYZ and XAuth drafts * Not a final output, lots of decisions to be made * Current draft is not compatible with XYZ or XAuth drafts * Editor's notes issues are currently referenced as links in the draft, this is temporary ##### Editor's Process: * Every change to the document will go through a Pull Request * All changes need a review from at least one other editor * Substantive changes need to be verified on the list * Releases will all be tagged * Source is in markdown, xml and html will not be checked into github * Repo includes a build script to build html artifacts * Goal with changes is not to come up with the perfect text, but to improve the current text. Changes may be accepted and merged and even published, that are not yet final. #### Issue Discussion ##### Issue 29: Terminology Justin: * How do we decide on names without endless bikeshedding * Should we use issues or wikis or separate files for each term Dick: suggested the wiki to summarise all the terms, so that we have one place to see all the terms in one place. Leif: do we see this is a permanent thing Justin: we should have a terminology section in the draft, there is the start of this in the current introduction. Whether the terminology section is the same content of the wiki, not sure. Yaron: Not as chair. I don't like terminology discussions that much, we should get it done asap and aim to get it done at least by the next IETF. Fabien: I would support Yaron's comments, that we should aim to get this finalised soon Leif: Suggest we use the wiki to gather all the terms and then have a discussion of them at the next interim meeting Justin: Agree, a wiki is terrible for discussion, but good for collecting the current state. So discussion either on issue 29 or a new issue for a specific term (but should be linked back), then it should be pulled back into the wiki. Aaron: Not a good long term plan, but faster to make changes in wiki than in draft. So a good place to capture current discussion. Lucy: Need to be able to defend terms in context ___ Justin: Nearly everywhere in the current spec, any reference to a client / RC is actually a client instance Issues 44,45,56 - Client Information Moving beyond OAuth 2 - want to separate a client instance from the software running that instance. OAuth 2.1 is continuing to struggle with this. In current protocol, a client instance can send instance identifier (client id) or client information block (like dynamic registration). This allows us to address many use-cases. Since we are talking about individual instances, we need to tie them together. OAuth 2 Dynamic Registration as the concept of software statements. In GNAP we want to separate the identification of an instance vs a class. Reason for joining these together, means policies can be applied on groups of client instances. Use cases for client information: - verifiable display information - third party pre-registration We need to understand the difference between information that will be sent every single request vs first request. How can we do this in the protocol. Leif: "Software statements" are important. Not sure if its software or posture. Justin: Sometimes it's about the organisation not the software - largely been in proprietary systems. We've seen people say this is the device signature of this application to prove I'm running unmodified software.GNAP even if it doesn't define all of this, should provide a place for this information to be conveyed. As soon as you "grant", you need to be able to "revoke" Issue 67: Continuation Currently there is a mandatory url in the continuation response. Access token (not bearer) is optional. What is the value of having those different options. Benefits of access token approach: authorization as an API, allows many different deployment options Benefits of token free approach: fewer moving parts, different behaviour for talking to AS vs RS Dick: My understanding, the client is going to authenticate on every call to the AS. Justin: its a bound access tokens, in the same way as calling the RS (whether the RS uses that) Dick: Not all mechanisms for binding the token include GNAP in the authorization header, e.g. DPoP has a different token style. So it's not the same as you'd call the RS. Justin: Bearer tokens would not be allowed here. Dick: Calling the AS / RS is not the same as you can call the RS with a bearer token Justin: I mean that tokens used to call the AS would have to be bound Leif: Are you for either of the options Dick: I'm questioning some of the statements made, will the client need to understand a different approach for contacting the AS /RS. Justin: Key presentation mechanisms are the same Aaron: Recommend keeping the state out of the url. Yaron: Process comment, request that the editors make it clear what the ask of the WG is Justin: Client information, 3 issues. Some of them just have contextual info. Would like feedback on the issues. Justin: Continuation (Issue 67), editors want to know what direction to take Dave: OAuth 2 extensions - some follow access token, some client authentication. Would prefer access tokens as allow for distributed AS, but main ask - reduce optionality. Justin: Bearer tokens will be forbidden. Justin: Issue 59 Interaction bundles - 2 alternatives. Aaron: There is a start and finish operation to an interaction. At the start its things like, whether it can redirect or show code. How it can finish the operation, at the moment its a callback either as a redirect or as a post back. There is also the ui_locales that would be convey somewhere. Suggest adding top level properties for `start` and `finish` Justin: You could allow a client to send an array of these interaction options. The editors would like feedback on issues 59 and 122. Yaron: We did some work on collecting use-cases, will this be useful for the editors in resolving this issue? Justin: It is some of those use-cases that are driving this issue. Need to get the balance between security and expressivity. Want to make it so the simple cases are simple, but more complex interactions can still be conveyed. Leaning towards allowing an array, but with the start/finish syntax. Justin: Issue 40 - Token Request Syntax. Yaron: The name "access_token" is not the best in the syntax, perhaps "access" would be better. Justin: Request input from the WG on this issue Dick: I think it's a good idea to have more metadata than just the resources, e.g. proof of possession. You could still have the label on the left side of the object. Agree with terminology of access rather than access_token. Justin: L value. If this a JSON object for single and multiple use-cases then this could bring issues with polymorphism. Moving the label into the object in an array has benefits. Justin: Issue 6 - Polymorphism. JSON has no inherent type restrictions. Security protocols benefits from predictable structures. How can we support polymorphism? Schema language for validation? Test suites? Optimise complexity away from client software. If we drop polymorphism what would we do instead? Justin: Please comment on the issues. ### Next Steps Chairs would like 2 interim meetings between now and next IETF. But this is a question to the group. Aaron: I'm a big fan of interim meetings, helps progress move faster and more checkpoints. Also more affordable. I would be in support of more interim meetings. Justin: I'm also in favour of interim meetings. Can be really good for moving discussion forward rapidly, with the caveat that they need to be clearly scoped by the chairs - maybe topic based meetings. Yaron: Suggest the next interim for 1 month's time. Justin: Editors have made a handful of changes to the document. Would it be beneficial to publish a draft with that changeset? Yaron: Yes, a new draft would make it easier for those reviewing. Meeting closed at 06:57 UTC