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.