Skip to main content

Minutes interim-2021-gnap-02: Wed 18:00

Meeting Minutes Grant Negotiation and Authorization Protocol (gnap) WG
Title Minutes interim-2021-gnap-02: Wed 18:00
State Active
Other versions plain text
Last updated 2021-02-11

Minute taker: Adrian Gropper

Aaron presenting: Second interim meeting
… changes since last IETF issues are on GitHub and link to PDF
… 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 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