I absolutely would not put the CWT CDDL into RFC8152bis – it is a payload definition, and RFC8152 is nicely agnostic as to payload right now – it makes sense to keep it that way. I agree with Laurence that RFC8152bis needs a way to indicate the payload type.
I think it most logically fits into CWTbis, but depends if: 1. There is appetite in ACE to prioritize work on CWTbis and availability of editors for CWTbis 2. How well this fits the ACE charter (probably OK, by my reading) One problem that would need to be addressed with the CWTbis approach is that CWT does not significantly envisage extension, as far as I can tell. Such a change should not break existing CWT implementations (“all claims that are not understood by implementations MUST be ignored”, RFC8392, section 3), but no doubt it would do so in practice. Note that JWT contains almost identical text, and likely has same considerations. The most generic approach would be to have a new standards track document that defines how to extend both a CWT and a JWT. It would mainly contain the CDDL below, with some explanatory text. Advantage would be that other WGs, and even non-IETF orgs, could use this as the starting point for standardized extensions on both token types. This should be fully in scope for RATS (see “Program of Work”, item 4 in the RATS charter). Notwithstanding all of the above, I can live with keeping this CDDL in EAT – particularly if alternatives would meaningfully delay publication of a complete standardized attestation format. Best regards Jeremy On 18/12/2021, 18:54, "COSE" <[email protected]> wrote: WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Dec 17, 2021, at 1:46 PM, Michael Richardson <[email protected]<mailto:[email protected]>> wrote: Laurence Lundblade <[email protected]<mailto:[email protected]>> wrote: So the question is: where should the CDDL for a CWT go? Here’s the main options I can think of: - EAT - UCCS - CWTbis (a revision of CWT to include CDDL) - Some other new standard - no where, never create it I'd say that it should go into RFC8152bis. Seems it would be as odd going into COSE as it would EAT. It would create a circular dependency between CWT and COSE. COSE payloads can be lots of different things. We don’t want to collect the CDDL for various the COSE payloads in COSE. The separation between COSE and its payloads is very clean right now. What should go into COSE is modifications to the COSE CDDL that defines a template by which the type of the payload can be specified (that template would use a .cbor control; see it done in the replicated COSE CDDL in CoSWID section 7 and 8), but that is not what this thread is about. Below is the CDDL that this thread is about. If the below CDDL went into its own document, it would be short. Below is the bulk of the document. What WG and what charter? It needs to be standards track. LL ; This is the fundamental definition of a Claims-Set for both CBOR ; and JSON. It is a set of label-value pairs each of which is a ; claim. ; ; In CBOR the labels can be integers or strings with a strong ; preference for integers. For JSON, the labels are always strings. ; ; The values can be anything, with some consideration for types that ; can work in both CBOR and JSON. Claims-Set = { * $$claims-set-claims, * Claim-Label .feature "extended-label" => any } Claim-Label = int / text string-or-uri = tstr time-int = #6.1(int) ; This is CDDL for the 7 individual claims that are defined in CWT ; and JWT. This CDDL works for either CBOR format CWT or JSON format ; JWT. $$claims-set-claims //= (iss-label => string-or-uri) $$claims-set-claims //= (sub-label => string-or-uri) $$claims-set-claims //= (aud-label => string-or-uri) $$claims-set-claims //= (exp-label => ~time) $$claims-set-claims //= (nbf-label => ~time) $$claims-set-claims //= (iat-label => ~time) $$claims-set-claims //= (cti-label => bytes) iss-label = 1 sub-label = 2 aud-label = 3 exp-label = 4 nbf-label = 5 iat-label = 6 cti-label = 7
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
