Session Date/Time: 20 Jan 2022 16:00

GNAP

Summary

This interim meeting of the GNAP working group focused on updates from the co-protocol editors regarding the core draft, detailed plans for the upcoming IETF 113 hackathon, and a presentation by Dmitry Zagdulin (W3C VC Community Group) on potential integration points and multi-step interaction workflows with Verifiable Credentials. Key discussions included clarifying the semantics of token rotation versus grant updates, defining interoperability parameters for the hackathon, and exploring how GNAP's interact and continue mechanisms could support VC issuance and prerequisite handling.

Key Discussion Points

Core Draft Updates:
- No new draft has been published since the last IETF, but an editor's copy is available on GitHub. A new draft is planned for IETF 113.
- New security considerations have been added, addressing topics like the cuckoo token attack, redirects, and server-side request forgery. These do not introduce protocol changes but provide guidance on deployment choices.
- The editors are actively working through the issue backlog, aiming to propose plausible solutions or justifications for closing issues to the working group. The focus remains on the core draft.
Clarification of Token Rotation vs. Grant Update:
- The editors clarified the distinct intents of the Token Management API's "token rotation" function and the Grant Management API's "grant update" function, which previously appeared similar.
- Token Rotation: Intended to replace an existing access token with an exact copy, with the expectation that the old token should be invalidated. Discussion arose regarding the practical difficulties of ensuring immediate revocation in distributed or stateless token systems. Danny suggested separating token rotation (creating a new token) from explicit revocation to simplify implementation for the common use case.
- Grant Update: Intended to obtain a new access token, potentially with altered characteristics (e.g., downscoped, increased rights, different key binding). This does not necessarily affect older tokens, though an Authorization Server (AS) may choose to revoke related tokens.
- This clarification did not result in protocol changes but refined the descriptive text of existing functionalities.
IETF 113 Hackathon Preparation:
- The core protocol is deemed stable enough for a multi-implementation interoperability hackathon. A project has been proposed for IETF 113.
- The goal is to bring together implementations of different GNAP roles (client, AS, RS).
- Interoperability Parameters for the Hackathon:
  - Interaction Mode: Redirect start and finish.
  - Proofing: HTTPB signatures with RSA PSS SHA 512, and content digest with SHA 512.
  - Access Tokens: Single keybound access tokens (bearer tokens and multiple tokens are not prioritized for this phase).
  - Access Rights: Arbitrary (no specific filtering of resource access defined).
  - Client/Key Registration: Dynamic clients and keys.
- Reference implementations and libraries are planned in Java, Rust, Go, and Python. Participants are encouraged to bring implementations with other parameters as well to explore broader interoperability.
- The hackathon is expected to inform the "Mandatory-to-Implement" (MTI) discussion and facilitate the creation of an implementation status section in the specification.
W3C Verifiable Credentials (VC) Use Case Integration:
- Dmitry Zagdulin presented on a multi-step interactive workflow from the W3C VC API task force, which was partly GNAP-inspired.
- Use Cases: Refreshing expiring VCs (requiring submission of old VC + prerequisites like an OIDC access token), and issuing new VCs (requiring prerequisites from the client).
- GNAP Alignment: Dmitry noted that existing protocols like OIDC and SIOP lack a mechanism for an issuer to respond by requesting prerequisites in a multi-step flow, unlike GNAP's interact and continue properties.
- Discussion:
  - Justin suggested this workflow aligns more closely with GNAP's grant update semantics. The interact system is designed for grant-level negotiations.
  - A key question emerged: Can an existing API (like a VC API) bootstrap a GNAP flow mid-process, and what are the implications for the security model?
  - Dmitry queried if GNAP is intended to issue VCs directly.
  - Justin confirmed that GNAP's flexible interact model (e.g., parameterized start methods) could potentially accommodate the issuance of VCs or the acceptance of VCs as prerequisites, similar to how OpenID Connect extended OAuth for identity. He clarified that the specific normative definitions for VC processing would likely reside within the VC community's specifications.
Resource Server (RS) Draft: The RS draft has expired, indicating a need to re-engage on its development, covering topics such as token models, dynamic RS introduction to AS, handling multiple AS interactions, new resource access sets, and specific security/privacy considerations.

Decisions and Action Items

Decision: The working group will proceed with a hackathon project for IETF 113, focusing on the specified interoperability parameters.
Action Item: Justin (editor) will start a mailing list thread to coordinate hackathon implementations and raise awareness for contributions.
Action Item: The discussion regarding GNAP's integration with W3C Verifiable Credentials and multi-step interaction workflows will continue on the GNAP mailing list.
Action Item: Editors to continue working through the existing issue backlog for the core draft.
Action Item: Editors to prepare a new draft of the core protocol in time for IETF 113.
Action Item: Editors will need to revisit the expired Resource Server (RS) draft and re-engage the working group on its outstanding topics.
Action Item: Editors to coordinate with the "sec event" working group regarding the dependency draft, and call for volunteers if needed.

Next Steps

Finalize Core Draft: Publish a new version of the core GNAP draft for IETF 113.
IETF 113 Hackathon: Conduct the planned interoperability hackathon, gathering feedback on implementation challenges and informing MTI discussions.
Security Analysis: Continue the formal security analysis of GNAP, aiming to automate analysis and testing.
Conformance Testing: Explore the development of a conformance test suite, potentially leveraging tools like the Open Foundation Conformance Suite.
API Description Languages: Investigate support and extensions for OpenAPI, AsyncAPI, and similar API description languages.
Resource Server Draft: Re-activate work on the Resource Server draft, addressing the identified open discussion points.
Community Outreach: Continue engaging with other communities, particularly the W3C Verifiable Credentials Community Group, to explore potential overlaps and integrations.