**Session Date/Time:** 23 Jan 2023 14:00

# [ACE](../wg/ace.html)

## Summary

The ACE Working Group discussed the status of several active drafts, including CMP, PubSub Profile, Revoke Token Notification, OSCORE Group Manager Admin (GM Admin), Key Group Communication OSCORE (Key Group Com OSCORE), and Ad-hoc OSCORE Profile. A key discussion point involved a proposal to split the GM Admin document to accelerate its progress, which received working group support. The Ad-hoc OSCORE Profile presentation led to a broader discussion about general features applicable across ACE profiles, suggesting the creation of a new document to house these common functionalities.

## Key Discussion Points

*   **CMP Draft**:
    *   The draft is awaiting a response from the security directorate.
    *   Mohit has responded to comments, and Paul is waiting for an updated draft version to initiate an IETF Last Call.
    *   The document is a normative reference for two other drafts in the RFC editor's queue, making its finalization important.
    *   A new version incorporating responses to comments needs to be published on the datatracker.
*   **PubSub Profile**:
    *   Progress has been limited since the last meeting.
    *   The author is awaiting updates to the CoAP PubSub specification from the CoRE WG.
    *   An update is expected within the next month, and assistance was offered for the security aspects.
*   **Revoke Token Notification**:
    *   Work is in progress for the next revision, with minor updates visible on GitHub.
    *   A new version is expected for the upcoming cutoff, aiming for a Working Group Last Call around IETF 116.
*   **OSCORE Group Manager Admin (GM Admin)**:
    *   A presentation detailed updates since IETF 113 (Vienna).
    *   **Major Changes (v5 to v6)**:
        *   Adopted a single AIF data model, inherited and extended from `key-groups-com-oscore`, to specify permissions for administrators.
        *   The `tid` (Target ID) can now represent a literal group name, a wildcard (`true`), or a tagged pattern (e.g., using a regular expression tag).
        *   A distinction between administrator and group member scope entries is made using the least significant bit of the `perm` value.
        *   Operations were categorized as mandatory or optional.
        *   An optional `group-id-recycling` parameter was added for group creation.
        *   Detailed text on authorization server policy checking (especially for group name patterns) was moved to an appendix as an example.
    *   **Major Changes (v6 to v7)**:
        *   Aligned the optional tagging of the `scope` claim in access tokens with the general definition from `ace-group-com` (using a CBOR tag on the bytestring).
        *   Defined a new error code with guidelines for administrator reactions.
        *   Parameters were classified as mandatory or optional.
    *   **Next Steps (Author's Roadmap)**:
        *   Add guidelines for multiple administrators coexisting for a single OSCORE group.
        *   Extend the security considerations section.
        *   Clarify Coral examples and convert them to use packed CBOR notation.
        *   **Proposal for Document Split**: The author proposed splitting the document into two: one focusing on link format and CBOR (to be finalized sooner) and another new, "frozen" working group document for the Coral-specific parts (to be progressed once Coral is stable). This aims to prevent the dependency on Coral from delaying the core functionality.
*   **Key Group Communication OSCORE (Key Group Com OSCORE)**:
    *   The shepherd write-up is in progress, expected to be finalized within a week.
    *   No significant changes or large amount of work for revision are anticipated from the shepherd review.
    *   A previous suggestion for another call for adoption was not broadly supported. The general expectation is to ship the documents to Paul after the shepherd review, who may then initiate a Last Call.
*   **Ad-hoc OSCORE Profile**:
    *   This profile defines provisioning access rights and asymmetric keys to a resource server and client using Ad-hoc and OSCORE.
    *   The document includes multiple options for token provisioning and OSCORE context establishment (e.g., simplified flows, optimized flows like `ad-hoc-key-update`).
    *   **Discussion Points from Christian's Comments**:
        *   **Token Provisioning**: Whether `POST /authorization-info` (client to AS, then RS) and `external_authorization_data` (in-line with Ad-hoc) are both needed. The authors believe separate options are necessary, especially for updating access rights.
        *   **Ad-hoc/OSCORE Execution**: Whether to keep independent flows (first Ad-hoc, then OSCORE) and combined requests (Ad-hoc message 3 within OSCORE request) or mandate a single approach (e.g., combined request). A participant suggested it depends on RS support, and a baseline requirement could be considered.
        *   **Parameter Negotiation**: Whether to allow negotiation of certain OSCORE parameters (e.g., master salt size) or simplify by excluding it. The authors lean towards simplifying by removing negotiation.
    *   **New Features / Generalization**:
        *   **Alternative Flow for Access Token Provisioning**: AS uploading the access token directly to the RS via `POST /authorization-info`.
        *   **Use of Certificates for AS Authentication**: Including certificate-based authentication for IoT devices.
        *   **Use of a Single Access Token for Multiple Devices/RSs**: Addressing the current limitation where `RS_CNF` ties an access token to a single resource server's public key. Proposed solutions include a new claim for multiple public keys or a trusted issuer (e.g., CA) or attribute assertion.
        *   **Discussion on Generalization**: There was a strong sense among participants that these three features are not specific to the Ad-hoc profile and should potentially be explored in a new, general "new features for Ace" document, describing their impact across individual profiles (Ad-hoc, TLS, DTLs).

## Decisions and Action Items

*   **GM Admin Document Split**: A sense of those present indicates support for splitting the `gm-admin` document. The CBOR/link-format focused part will be finalized within ACE, and the Coral-specific part will be developed as a new working group document and "frozen" until Coral progresses in the CoRE WG.
*   **CMP Draft**: The Chair will follow up with Mohit to request the publication of a new version of the draft on the datatracker, addressing comments from the security directorate.
*   **Key Group Com OSCORE**: Ricard will finalize the shepherd write-up by next Monday. Marco will then incorporate any review comments into the editor's copy and aim to ship a new revision to Paul by the end of the month.
*   **Ad-hoc OSCORE Profile**: Authors will consider the feedback on simplification (e.g., reducing alternatives, parameter negotiation) and potential generalization of features.

## Next Steps

*   **GM Admin Document**: Marco will work on cleanly splitting the document after IETF 116, as decided. The Chair will send an email to the working group to formally announce the decision to split the document.
*   **Ad-hoc OSCORE Profile**: The authors plan to resolve outstanding comments and propose simplifications (e.g., reducing alternatives for combined requests, possibly excluding negotiation) for a new version before the next IETF meeting.
*   **General ACE Features**: The authors of the Ad-hoc OSCORE profile will further explore the alternative token provisioning flow, use of certificates, and multi-device access tokens, with a view to proposing them as general ACE features, potentially in a new, separate document.