Material: https://datatracker.ietf.org/meeting/125/session/ace
Note takers: Marco Tiloca, Rikard Höglund
Presented slides: https://datatracker.ietf.org/meeting/125/materials/slides-125-ace-ace-chair-slides-00
Tim Hollebeek doing introductions. Two documents (key-groupcomm-oscore and oscore-gm-admin) are making their way through the IESG process; hopefully RFCs to announce at the next meeting.
Paul Wouters: I'm done and handing over to Christopher.
Christopher Inacio: Yes, I will be taking over.
Tim: Thank you Paul for all your work. I'll get in touch with Christopher to get him up to speed.
Mališa Vučinić presenting.
Presented slides: https://datatracker.ietf.org/meeting/125/materials/slides-125-ace-draft-ietf-ace-coap-est-oscore-10-00
Mališa: In WGLC since September 2025. Two reviews from Marco Tiloca and Esko Dijk in October. First set of comments addressed for IETF 124. Remaining issues resolved in version -10, submitted 2 March 2026.
Mališa (p4): List of resolved issues since -09. Five issues tracked on GitHub, most editorial.
Mališa (p5): Issue 113: Should "bag of certificates" be mandatory? Conclusion: explicit chains don't support CA re-keying post-deployment. A bag is more general and can contain a chain. Made application/cose-x509 a MUST for both EST-OSCORE clients and servers. Aligned TBD numbers with draft-ietf-cose-cbor-encoded-cert.
Mališa (p6): Clarified that mixing X5U and C5U certificate references in the same multipart response is not supported, as they share the same content type and would be ambiguous.
Mališa (p7): All remaining issues resolved. Believe the document is ready to be shipped.
Paul: Any comments on readiness? No feedback from room or online.
Mališa: The WGLC is concluding and the document will proceed to Shepherd Write-up.
Marco Tiloca presenting.
Presented slides: https://datatracker.ietf.org/meeting/125/materials/slides-125-ace-draft-ietf-ace-coap-pubsub-profile-00
Marco (p2): Recapping what this is about. ACE application profile for CoAP pub-sub. Two resource servers involved: the broker and the KDC (RFC 9594).
Marco (p3): Recent developments. WGLC ended in January with positive feedback, mostly editorial. Version -03 incorporates feedback from the IETF Last Call of key-groupcomm-oscore that was also applicable here, plus a fix for an underspecified optimization.
Marco (p4): Extended introduction to clarify how this draft relates to other documents, supported by an SVG diagram.
Marco (p5): Clarified what "secure communication must be used" means. Clarified rationale for proof-of-possession (it's the private key of the prover).
Marco (p6): Expanded on scenarios for KDC group rekeying. Fixed underspecified optimization: when a client rejoins a group, it can use a sentinel value (empty CBOR byte string) for the authentication credential parameter instead of re-sending the full credential.
Marco (p7): Added Operational Considerations section covering logging at the KDC. Secret information must not be logged; logs shared with third parties must be redacted for privacy. Administration of security groups and application groups is out of scope.
Marco (p8): Next steps. Publish version -04 with additional fixes from IESG evaluation of key-groupcomm-oscore (e.g., nonce/challenge terminology from Deb Cooley's DISCUSS). Notes that the topic data resource is assumed to be at the broker; alternative hosting is out of scope. Normative dependency on draft-ietf-core-coap-pubsub (to be presented at CoRE on Friday); propose to send that document to IESG first, then follow with this one.
Tim: I wouldn't start the Shepherd Write-up yet as the other document may affect this one. Propose to wait until no longer blocked.
Marco: Will submit version -04 soon. No shepherd appointed yet, but not urgent.
Marco Tiloca presenting.
Presented slides: https://datatracker.ietf.org/meeting/125/materials/slides-125-ace-draft-ietf-ace-workflow-and-params-00
Marco (p2): Recapping what this is about. Updates to the main ACE framework (RFC 9200): new SDC workflow, new parameters, deprecating old error response format, etc.
Marco (p3): Updates for version -07. Clarified inclusion rules for parameters in access token request/response. Made explicit that certain parameters must not be included when extending an existing token series. Improved semantics of RS_CNF in access token request.
Marco (p4): Specified JSON encoding details for messages. Added missing IANA entry for the access token parameter in the AS-to-RS request. Clarified that "access token response" is successful by definition per RFC 9200.
Marco (p5): Editorial improvement per Dave Robin's feedback: moved content about SDC update of access rights from section 2.1 to section 3.7 for better readability.
Marco (p6-8): Handling special case for SDC update of access rights. When the RS has terminated a token series (e.g., due to memory constraints) and the AS fails to upload a new token, the AS can locally start a new token series and retry. This requires a new ACE error code for the RS-to-AS response. Planned improvement for next version.
Marco (p9): Filed 7 errata against RFC 9200. Please review.
Marco (p10): Next steps. Add Operational Considerations, improve "from_rs" parameter semantics, add guidance for "anchor_cnf" with group audiences (open GitHub issue from Christian Amsüss).
Dave Robin: Thanks for editorial cleanup. Good to move things into 3.7. Would like more clarification about RS_CNF in access token request — confused by "MUST NOT null" next to "SHOULD NOT false" without more explanation of when to violate the SHOULD.
Marco: Will highlight the condition "if C does not have RS's authentication credential" and elaborate more.
Christopher Inacio (in chat): Is there something meaningful to say in the Operational Considerations section? If not, it doesn't need to be included.
Marco: Understand you're still supposed to add the section with boilerplate.
Christopher: That has not been fully agreed upon. I'd prefer not to require that. If you have something meaningful to say, by all means; but don't put it in if you have nothing to say.
Marco: Probably something to say about the AS, especially logging.
Rikard Höglund presenting.
Presented slides: https://datatracker.ietf.org/meeting/125/materials/slides-125-ace-edhoc-and-oscore-ace-profile-slides-ietf-125-00
Rikard (p2): Recap on the profile. Uses EDHOC for key establishment with access token in an EAD item, then OSCORE for secure communication. Supports both forward and reverse message flows.
Rikard (p3): Removed four parameters from the EDHOC_Information object (max message size, content format option usage, endpoint identifier types, transports) as not really needed. Also removed two related IANA registries. Editorial fixes and updates from IANA early review.
Rikard (p4): Fixed CDDL notation of the EDHOC_Information object so it actually validates. Updated trust anchor definition to proper CDDL.
Rikard (p5): This transport profile can be combined with application profiles of RFC 9594 (e.g., key-groupcomm-oscore and CoAP pub-sub profile). Those profiles require the RS to provide a challenge N_S for proof-of-possession, but in this profile the first access token isn't uploaded to /authz-info. Solution: derive N_S via the EDHOC Exporter, with two new EDHOC Exporter Labels requested for registration.
Rikard (p6): Requesting early allocation of codepoints in three IANA registries: JWT confirmation methods, CWT confirmation methods, and EDHOC External Authorization Data. One requested codepoint (credential-by-value) is already in use by aiocoap and Ariel OS's coapcore.
Rikard (p7): Next steps. Elaborate on privacy/security implications of placing access tokens in different EDHOC messages (EAD_2 vs EAD_3 vs EAD_4). More examples of request creation hints EAD item. Process Christian Amsüss's review of version -09. Ensure AS has accurate information about C and RS capabilities for EDHOC execution.
No questions from the room or online.
Tim: One action item from this session: concluding WGLC for draft-ietf-ace-coap-est-oscore and proceeding to Shepherd Write-up.