Thanks for the very details - please ship it! To the WG, please state your opinion by the end of August.
Yours, Daniel ________________________________________ From: Ace <[email protected]> on behalf of Marco Tiloca <[email protected]> Sent: Friday, July 29, 2022 12:20 PM To: [email protected] Subject: [Ace] Planned updates to draft-ace-key-groupcomm Hello ACE, Following some discussions in the past months, I was planning to make two non-invasive changes to draft-ace-key-groupcomm-15 [ACE-KG], which is currently in AD Review. After giving a heads-up to Daniel and Paul at IETF 114, this mail is to check with the Working Group if there are objections to make the changes. --- UPDATE 1 Following IETF 113, there was a proposal from Christian about updating Section 7 "Extended Scope Format" of [ACE-KG]. The defined approach is optional to use, it signals the semantics of a binary encoded "scope" claim of an access token, and is referred to in the documents [ACE-KGO][ACE-ADMIN]. The result of the change, also proposed in [GH-ISSUE], would be a simpler and more efficient signaling of the scope semantics. In turn, it automatically takes advantage of the work done in CBOR at [CBOR-FM]. Question: is there any objection to update Section 7 of [ACE-KG], based on the proposal at [GH-ISSUE]? --- UPDATE 2 At IETF 113, it was discussed that the "scope" claim of a same access token could specify, at the same time, both: i) scope entries related to roles of members in an OSCORE group, as per [ACE-KGO]; and ii) scope entries related to admin permissions for Administrators of OSCORE groups as per [ACE-ADMIN]. Following that discussion and in order to make things simpler, a single AIF data model "AIF-OSCORE-GROUPCOMM" is now defined in Section 3 of [ACE-KGO]. This still builds on the general requirements from Section 3.1 of [ACE-KG], and primarily serves what is specified in [ACE-KGO]. Then, the same AIF data model is extended in Section 3 of [ACE-ADMIN] to serve what is specified therein. That is, in each Administrator scope entry <Toid, Tperm>, Toid indicates a pattern of group names, while Tperm indicates admin permissions on groups whose name matches the pattern. In particular, Toid can be: i) the CBOR Simple Value "true" used as wildcard, also part of a suggestion from Ben at IETF 113 [ACE-113]; ii) a CBOR text string specifying a literal group name; iii) a tagged CBOR item specifying a complex pattern of group names, with the CBOR tag indicating the pattern semantics (e.g., a regular expression provided by a text string). With the above background in mind, the small update for [ACE-KG] would be in its Section 3.1, about having consistent general requirements when using AIF. The requirements are currently mandating "Toid" to always be a CBOR text string, while in fact "Toid" is only _often_ a CBOR text string (also highlighted by Ben at IETF 113 [ACE-113]). The change can simply mandate the use of exactly a CBOR text string only for scope entries related to group members, i.e.: OLD: If the AIF format is used, each scope entry is encoded as specified in [I-D.ietf-ace-aif]. The object identifier "Toid" corresponds to the group name and MUST be encoded as a CBOR text string. The permission set "Tperm" indicates the roles that the Client wishes to take in the group. NEW: If the AIF format is used, each scope entry is encoded as per [I-D.ietf-ace-aif], according to the used AIF specific data model. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name and MUST be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group. Question: is there any objection to update Section 3.1 of [ACE-KG] as above? --- Reminder: there are also some minor, editorial changes that are pending, as already mentioned at point 1 of [MAIL] and during the IETF 113 presentation of [KGO]. These updates are about consistently aligning terminology and parameter names, as triggered by the WGLC review of [ACE-KGO] at [REVIEW] and by the latest updates to the CoRE document [GROUP-OSCORE]. I can certainly process these small pending changes together with the two main ones above. Thanks, /Marco [ACE-KG] https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-15 [ACE-KGO] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ [ACE-ADMIN] https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/ [GH-ISSUE] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a993cf57d4eb0424&q=1&e=f7c78eb1-ef42-4a78-b159-4fd24b9b965e&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm%2Fissues%2F144 [CBOR-FM] https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/ [ACE-113] https://notes.ietf.org/notes-ietf-113-ace?both [MAIL] https://mailarchive.ietf.org/arch/msg/ace/wBpceZW1qT1YYICzECnKqvdwQb8/ [REVIEW] https://mailarchive.ietf.org/arch/msg/ace/SIB_rte0orqkvDEtTAw-1F7Cdzo/ [GROUP-OSCORE] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3d296ae5721cac2b&q=1&e=f7c78eb1-ef42-4a78-b159-4fd24b9b965e&u=https%3A%2F%2Fwww.ri.se%2F _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
