# GNAP Interim Date: 2022-01-20 ## Draft Updates Presented by: Justin Richer Note taker: Aaron Parecki Slides * A lot of recent document changes but no protocol changes * Haven't yet published a new draft ahead of the interim, but editor's copy is available on GitHub * https://github.com/ietf-wg-gnap/gnap-core-protocol * New security considerations, as discussed during last meeting * Cuckoo token attack, 302 redirects * These are mainly talking about attacks against deployment choices, didn't require protocol changes to address * Clarifying token rotation and grant updates * token rotation: requesting a new token with the same abilities as the current token * grant update: asking for something new, doesn't necessarily change previous tokens Questions * Yaron: Making sure an old token can't be used is sometimes difficult as we know. If a client refreshes 5 minutes ahead, nobody cares the old token is valid for an extra 5 minutes. But if someone changes a password etc, should there be something different to make sure the tokens are revoked? * Justin: Token revocation is already part of the draft. Should we make a stronger statement about this in rotation? * Yaron: For the normal use case this is overshooting it, because if I want revocation then there is already a mechanism for that * Justin: We are planning to add something in security considerations talking about when it might be difficult to strictly expire tokens. But the goal is to set the expectations of the action. * Yaron: There is also the expectation of the person running the system as a whole. By adding the expectation of revocation on rotation, we're making life harder for everyone. * Denis: I believe revocation and rotation should be separate. Slides * Process * Editors are working through the issue backlog * Contributions on the issue tracker are very welcome, but please do not open duplicate issues * Focusing on core draft now, RS draft later * Preparing for IETF 113 hackathon * The editors believe the core protocol is stable enough to start testing interop * GNAP is on the hackathon schedule for IETF 113 * We want to go into the hackathon with several implementations already * Interoperability parameters for hackathon, defining a minimum set of interaction methods and keys * Interaction: redirect start finish * Signing: HTTP Signatures * We do want to encourage other parameters and methods, since some of the existing implementations will also already cover other parts of the spec too * The hackathon will hopefully help with the "mandatory to implement" discussion Yaron: What's the right venue to talk about implementations ahead of the hackathon? Justin: I will start a thread on the GNAP mailing list * Developing community * Not targeting these goals right now but will help in the future * Test suite, could reuse the OpenID Connect framework * Would love to see support for API description frameworks like OpenAPI/AsyncAPI * Next steps * Formal security analysis - in progress, has already brought to light some security considerations * Outreach to other communities * Implementations * Resource servers draft - it just expired * RS draft addresses things that aren't a concern of the client, lots of discussion to be had still ## Interactive requests in support of W3C VC API Presented by: Dmitry Zagidulin Note taker: Justin Richer Interactive workflow in VC API (w3c work) - Verifiable Credentials - Digital wallets for EDU Inspired by GNAP's interaction methods, want to see what the overlap is Use cases: 1. We had expiring credentials in the wallet, needed to refresh them. Needed to send an existing credential plus some prereqs to get a new one. 2. Needed to carry prerequs (like an access token (from OIDC)) to get a new VC looked at OIDC, GNAP, WACKI (?) Looked for support to fulfill prereqs: - "I received this request but need something else from you" - looked at GNAP's interact/continue model VC re-issue workflow: - client needs a new VC - issuer says "get a new token, send the old one" - client posts it to endpoint Reminds me of GNAP! - access token management endpoint in GNAP - credential has "refresh service" endpoint Instead of just submitting the old token for refresh, could we allow submission of additional prerequisites? 2: issue a VC with prereqs - client: i want a VC - server: give me these things - client: sends things - server: I need these two more - cycle continues question to GNAP WG: can we use interact start/finish to model the server endpoint? - maybe server responds with its set of prerequisites - multi-step interactive workflow Justin: great writeup. This aligns well with the token rotation discussion. This sounds more like a grant update, "I want a new thing, you're going to require something else from me". It's not the same as rotating an access token, also because you're not issued an access token, you're issued a credential. The main divergence is how this all starts. In GNAP you start with an HTTP Post. Is there a way and does it make sense to allow an API like the VC API to start a GNAP flow in the middle? Is that GNAP or is that the VC API? Dmitri: GNAP and VCAPI can be very complimentary - VCAPI requires authn (access tokens), getting tokens is out of band so GNAP is a way to do that - would love to hear from the group whether there's intention to also use it for issuing VC's Adrian: frame question in terms of delegation, this is the issue in terms of delegation. b/c we have an authentication component to the flow, question becomes "are we going to allow delegation as part of this process?" Justin: GNAP could be extended to have VC's issued by the AS and presented to the AS. Already does "subject information" as identifiers and assertions. VCs could maybe be an assertion or possibly something else.