Re: [Anima] [Iotops] [netconf] what to call different RFC8366 format artifacts

Agree with Juergen, these artifacts are all CMS signed-data content
Type, so COSE signed CBOR, JWS signed JSON is more nature to me.

-Qin
-----邮件原件-----
发件人: Iotops [mailto:iotops-bounces@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2020年11月4日 4:24
收件人: Michael Richardson <mcr+ietf@sandelman.ca>
抄送: netconf@ietf.org; anima@ietf.org; iotops@ietf.org
主题: Re: [Iotops] [netconf] what to call different RFC8366 format artifacts

On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote:
> 
> So to bikeshed the whole thing, please comment on preference in naming:
> 
> 1) RFC8366:    CMS-signed-JSON  vs JSON-in-CMS.
> 2) CV:         CMS-signed-CBOR  vs CBOR-in-CMS.
> 3) CV:         COSE-signed-CBOR vs CBOR-in-COSE.
> 4) future ID:  JWS-signed-JSON  vs JSON-in-JOSE.
> 
> I note that for some of these "signed" is redundant.
> We do not have COSE-signed-JSON, or JWS-signed-CBOR.
> 
> Which feels more natural to you?
>

For me, all the $foo-signed-$bar expansions make sense and they stress the signature aspect:

CMS-signed-JSON  = Cryptographic Message Syntax signed
                   JavaScript Object Notation CMS-signed-CBOR  = Cryptographic Message Syntax signed
                   Concise Binary Object Representation COSE-signed-CBOR = CBOR Object Signing and Encryption signed
                   Concise Binary Object Representation JWS-signed-JSON  = JSON Web Signature signed
                   JavaScript Object Notation

The $foo-in-$bar alternative somehow stresses containment but I assume the primary reason for using CMS / COSE / JWS is for signatures, not for containment.

/js (German, in case that matters.)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

--
Iotops mailing list
Iotops@ietf.org
https://www.ietf.org/mailman/listinfo/iotops