**Session Date/Time:** 10 Nov 2022 09:30

# gnap

## Summary

The gnap working group met to review significant updates to the core protocol document, discuss human rights considerations, and plan next steps for both the core and resource server (RS) protocol drafts. Editors presented extensive changes to the core document, positioning it for Working Group Last Call (WGLC). A dedicated discussion on human rights, specifically regarding resource owner choice of authorization server (AS) and power asymmetry, led to a nuanced debate about normative requirements versus implementation guidance. The working group decided to proceed with WGLC for the core document following a final editorial pass, and to seek increased engagement for the RS draft.

## Key Discussion Points

*   **Core Document Updates (Editor's Report)**
    *   **Major Progress**: 23 pull requests merged and 55 issues closed on the core document since the last meeting, with a focus on clearing long-standing issues.
    *   **Functional Changes**:
        *   **Key Rotation**: A new mechanism was introduced to allow for the rotation of keys bound to access tokens, with specific proofing methods defined for HTTP Signatures and Jose. Dynamic rotation for mTLS was deemed out of scope for the core document.
        *   **Cross-User Asynchronous Authorization**: Clarified and expanded text, including new signaling to differentiate the identity of the end user at the client from the resource owner (e.g., call center scenario). This capability was recognized as a potential "foot gun" for phishing if not properly secured, requiring robust security considerations.
        *   **Normative Syntax Consistency**: Simplified and harmonized object structures (e.g., proofing methods, access rights, error responses) across the protocol for greater consistency.
        *   **IANA Section**: Added extensive guidance on defining extensions to the core protocol.
        *   **Absolute URIs**: Clarified that all URIs are intended to be absolute.
        *   **Error Messages**: Expanded syntax and messaging around errors.
    *   **Editorial Changes**:
        *   **Security Considerations**: Significantly expanded throughout the document.
        *   **Class ID**: Clarified the role and meaning of the client instance class identifier as a hint to the AS.
        *   **Interoperability Profiles**: Introduced two initial profiles (Web and Secondary Device) to define mandatory-to-implement (MTI) considerations for different use cases, covering key proofing, hash/signature algorithms, subject identifiers (opaque), and assertion formats (ID tokens/SAML V2). HTTP Sig was proposed as the preferred key proofing method for its simplicity and reliance on the HTTP stack.
        *   **JSON Schema**: Decided to host JSON Schema definitions on the GitHub Wiki rather than in the core document due to their length and dynamic nature. This sparked a discussion on IETF archival practices for long-term availability, with a suggestion to consider an RFC appendix or core schema in-document with external vocabulary for registries. Expert review for the JSON Schema was also suggested.
        *   **Implementations List**: Updated list of public implementations, with a call for more contributions.
    *   **Open Issues (Core Document)**:
        *   Missing errors and discovery for key rotation (mechanical fix).
        *   Clarity needed that subject identifiers returned by an AS are scoped to that AS, even for global identifiers like email addresses, to prevent confusion and misuse. Reference to NIST 800-63c was suggested.
*   **Human Rights Considerations (Adrian Gropper's Presentation)**
    *   **Proposal**: A separate human rights consideration section is needed, with some normative aspects, to address the asymmetry of power between individuals (resource owners) and institutions (AS/RS/clients).
    *   **Key Issue**: "Forced association" in OAuth2 AS creates regulatory and human rights problems. Resource owners should be allowed to state their preferred AS.
    *   **Discussion**:
        *   **Normative vs. Guidance**: Debate on whether the spec should include "MUST" or "SHOULD" requirements or provide guidance on trade-offs (security vs. human rights) for implementers and regulators.
        *   **Placement**: Editors believe such text is better suited for the RS draft, as it pertains to the association between AS and RS, and where mitigation actions might occur.
        *   **Multiple Solutions**: It was argued that gnap's flexibility ("token factory" model) allows for various technical solutions to address human rights concerns (e.g., externalizing resource owner policies via verifiable credentials), not just dissociation of AS/RS ("bring your own AS"). The goal is to enable technical capabilities so that technology providers cannot hide behind a lack of technical means.
        *   **Regulatory Role**: The importance of providing regulators with maximum opportunity to govern technology deployments and mandate specific human rights considerations was emphasized.

*   **Hash Algorithms**: Discussion on `sha3` vs `sha256` for interaction hashes. Editors are open to standardizing on `sha256` for both for implementer ease, given the short lifetime of the interaction hash.

*   **Resource Server (RS) Draft Status**:
    *   The RS draft, which defines the association between AS and RS (e.g., token models, introspection), has received less attention. It is considered critical for addressing certain human rights concerns, as it governs how AS and RS interact.
    *   An open call was made for working group members to review and contribute energy to the RS draft.

## Decisions and Action Items

*   **Decision**: The core gnap document will proceed to Working Group Last Call (WGLC) following one final editorial revision.
    *   **Action Item**: Editors (Justin Richer, Fabian Hirschmann) to perform a final review, incorporate fixes for the remaining open issues (key rotation errors/discovery, subject identifier scoping), and publish Draft 12 of the core document within approximately one week.
    *   **Action Item**: Chairs to initiate the WGLC process for the core document (Draft 12) once published.
    *   **Action Item**: All working group members are strongly encouraged to review the core document during WGLC.
*   **Decision**: The human rights considerations discussion will continue at the HRPC meeting (scheduled for the following day) and subsequently return to the gnap working group editors for further integration. The initial text has been moved to the RS draft.
*   **Decision**: To foster progress on the Resource Server (RS) draft, the working group will hold an interim meeting.
    *   **Action Item**: Chairs to schedule an interim meeting in early January (between now and IETF 116 Yokohama) to assess the status of the core draft and plan the future of the RS draft.
*   **Action Item**: Working group members Daryl Miller and Brent Zundel (Gen Digital) volunteered to review the current RS draft and provide feedback.
*   **Action Item**: Editors to consider `sha256` for both hash algorithms in the core document for consistency and implementer ease.
*   **Action Item**: Editors to include Norton/Gen Digital's Verified.me implementation in the public implementation list.

## Next Steps

*   **Core Document**: Final editorial review and publication of Draft 12, followed by Working Group Last Call.
*   **Resource Server (RS) Draft**: Working group members are encouraged to review the current RS draft. The goal is to bring the RS draft to a state comparable to the core document by IETF 116 (Yokohama).
*   **Human Rights Considerations**: Further discussion at HRPC and continued collaboration with gnap editors to refine the text and determine the appropriate level of normative language or guidance within the RS draft.
*   **Interim Meeting**: Scheduled for early January to re-evaluate the core draft's WGLC progress and strategize on the RS draft.