You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fundamentally, the two registration requests in Section 10.6 are appropriate, each with an integer label to be assigned out of the Standards Action space (e.g., 13 and 14).
I have asked for a slight update of the registration request based on the following observations:
The Value Type for the kccs parameter is listed as map/#6(map). This appears to be an incomplete specification, waiting for a tag to be assigned for a CCS in draft-ietf-rats-uccs. Since EDHOC seems to be completing faster than that draft, and the alternative that includes the tag for CCS also is not strongly required, I propose to change the Value Type to just map.
The supplementary information about both kccs and kcwt in the paragraph preceding the registry template is unlikely to be picked up by people consulting just the registry. I have requested making the “description” column more complete, in particular also pointing to RFC 8392 as the source of the “CWT” and “CCS” definitions.
As an editorial observation, the description "A CBOR Web Token (CWT)/... containing a COSE_Key in a 'cnf’ claim” could be read as saying that only that one claim is to be contained in the token. Section 3.5.3.1 clarifies this by also saying "There may be any number of additional claims present in the CWT/CCS.”. Adding an “and possibly others” or similar to the description column might make this information more accessible to readers coming from the registry.
I have discussed the first two items with the authors, who agree with the suggestions, and expect them to be open to the third one as well.
The text was updated successfully, but these errors were encountered:
https://mailarchive.ietf.org/arch/msg/lake/BU4zDcEpoaFs8WW7BZ2pKoufakU/
Fundamentally, the two registration requests in Section 10.6 are appropriate, each with an integer label to be assigned out of the Standards Action space (e.g., 13 and 14).
I have asked for a slight update of the registration request based on the following observations:
The Value Type for the kccs parameter is listed as
map/#6(map)
. This appears to be an incomplete specification, waiting for a tag to be assigned for a CCS in draft-ietf-rats-uccs. Since EDHOC seems to be completing faster than that draft, and the alternative that includes the tag for CCS also is not strongly required, I propose to change the Value Type to justmap
.The supplementary information about both kccs and kcwt in the paragraph preceding the registry template is unlikely to be picked up by people consulting just the registry. I have requested making the “description” column more complete, in particular also pointing to RFC 8392 as the source of the “CWT” and “CCS” definitions.
As an editorial observation, the description "A CBOR Web Token (CWT)/... containing a COSE_Key in a 'cnf’ claim” could be read as saying that only that one claim is to be contained in the token. Section 3.5.3.1 clarifies this by also saying "There may be any number of additional claims present in the CWT/CCS.”. Adding an “and possibly others” or similar to the description column might make this information more accessible to readers coming from the registry.
I have discussed the first two items with the authors, who agree with the suggestions, and expect them to be open to the third one as well.
The text was updated successfully, but these errors were encountered: