Minute taker: Adrian Gropper Aaron presenting: Second interim meeting … changes since last IETF issues are on GitHub and link to PDF https://datatracker.ietf.org/meeting/interim-2021-gnap-02/materials/slides-interim-2021-gnap-02-sessa-interim-slides-00 … dropping short URL … OIDC claims parameter ... new thighs are last 3 … edits have now been made in the draft Justin: We don’t have slides with details … first two presented at last interim meeting on how we present requests … 162 and 150 restructured how access tokens work … the important thing is that as an object - no more flags … request for access token looks a lot like the response - which is really nice … did a major editorial change - movers around where you describe using keys - #152 … #162 will be merged today or tomorrow Aaron: editorial changes do not change behavior, new ones not interesting, fiddling with GitHub so any of the PRs get a built-out link to see rendered view - also labels going on - including pending merge - to signal a chance to review before the merge - if you’re interested, click that label Yaron: Changes? Justin: Link from main GitHub that lets you see rendered version of what’s on the main branch - see reformat of section 7 - you can look at the history of commits - editors are also tagging the repo every time we make a release - so you can easily diff what’s there now - Fabien: Denis asking for more info on how to use the GitHub. See Wiki https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Github-tutorial with link for how to use markdown - we’re using the kramdown-rfc2629 MD dialect. Denis: is it possible to incorporate screen shots Fabien: Yes but hard to integrate Aaron: Please pay attention to the issues - editors will do the grunt work and work the document itself Denis: Wanted to create issues - “remember to discuss on mailing list first” correct? Fabien: Make sure it’s not already an issue and also notify mailing list if important issues Justin: We have a 2 hr meeting IETF Week 11 ET on March 9. See IETF calendar when updated. Topic: #122 PR: #164 Aaron: General approval last meeting on the request the client makes to the authorization server - went back and forth and landed on syntax - see slides - 3 top-level properties defined - how to start, how to finish, and any hints .... this is now very close to original but clearly labeled and grouped … see #122 … a lot of the Section 2.5 of the preview draft Justin: Important when you refer to a section please identify the release … what’s the motivation for change? The win is much clearer for where extensions fit in - this is how a client can kick off interaction with somebody and then I have one way that I get updated when the AS decides - so extensions now have real places to put stuff - let’s say Ping comes up with a interaction method - they can register as an extension that fits in the protocol - before, that would have been less clear - now if you have another way to do things - Denis has brought up gathering consent on the user device directly - if we have a way to message, we can now handle that. … The other important thing: we now have a way to potentially make this a multiple object, an array, so clients can define how to define and allow AS to choose which to respond to - semantics are tricky but this syntax makes this an clearer conversation when the time comes. Yaron: Does Start allow objects as well as strings? Aaron: Yes, there’s a place for that although it’s not done yet. Yaron: Comment: “Hint” is a little subjective. Maybe use additional properties or something more blad. Aaron: It’s a suggestion from the client not a directive. If we had a more explicit directive it would not be a good place for it. Justin: Fair points. Editors discussed the appropriateness - we did not want to bike-shed so let’s do that in the group - easy to swap the labels Denis: Do we have a well-defined state machine? What needs to be before the start and the finish Justin: That bois down to AS’s authorize process. In the text it’s listed as one of two ways - either you interact with RO - or if the result is negative or the RO has wandered off and will never approve this - GNAP should tell the client it should stop waiting Justin: The Neg and Pos behavior is the same. In OAuth2 we had to invent a bunch of front-channel codes - there were a lot of security issues with doing that - so the client sits there forever. With GNAP we can do that better - as a generic process - depends on the Finish method - you send the message telling the client to take the next step. Denis: New methods will need to inven both Justin: The method itself is an extension token. It’s always secure regardless the Finish method … a lot of the problems in OAuth2 arise from being able to specify a redirect. GNAP is always safe because you can tie the redirect to a specific request. Adrian: Is there a comparison with OAuth2 Justin: There’s not a specific doc. Yaron: It needs to be in the draft. Justin: As an editor we should not make it philosophical. Adrian: Does SIOP intersect with GNAP or not? Justin: Good question. SIOP use-cases need to be addressed - threads already as device-based authorization Francis: Essential to draw a line as to whether considered or not. It looks difficult do bring device based authn into GNAP. Justin: This is something we can prepare for IETF. SIOP first step is an HTTP call. With GNAP there is not separate step. If we had a way to tie in to a device but we don’t have that yet. Implicit flow is Francis: SSI activity around carrying keys on the device. Need protocol for communicating with the user device. Makes sense so we need to better work on user-device generation of access token. Justin: Somebody should build something. Aaron: Help frame discussion about Implicit Flow in SIOP could be done differently in GNAP. Adrian: Vaccine credential discussion is this use-case - I can contribute as an issue. Justin: HTTP AS not going away - needs to be translated into other spaces but we can’t let HTTP get away. Francis: GNAP might have two phases: First HTTP then second phase has device-based included - produce the HTTP first then abstract later - Justin: Agree with Francis. HTTP first. Also need to be aware of SSI world so we don’t accidentally design it out or put barriers in. In the future, if we have another GNAP for device flows. Francis: HTTP is in the charter. As long as you want to connect to the server using HTTP. If we can abstract the way to connect to the AS, then we can consider ways to not exclude those cases. Justin: We can learn from OAuth and ACE as a port of OAuth to IoT space as a deliberate translation so it can take advantage. I think we can clearly do stuff here with the Start and Finish bits around interacting with RO that already don’t have to go over HTTP. … this interaction method thing. OAuth starts in a browser. We can start with HTTP w/o assuming a browser. Yaron: Tome. Thanking the editors. We will meet again on Mar 9 or wherever it’s on the calendar.