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 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

Proposal - Issues

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:
Design Considerations:
Current State:
Design Team Output:
Editor's Process:

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