[Teep] Fwd: JSON/JOSE vs. CBOR/COSE

I mistakenly dropped many addresses when I pressed button gmail, this
is resend which I sent to Henk only.

>         On 20 Feb 2020, at 11:16, Hannes Tschofenig
>         <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
>         wrote:
>
>         With the impression from the Hackathon in mind I am wondering
>         whether we should make a decision about the encoding of the TEEP
>         protocol messages. Today, the spec allows two types of
>         encodings, namely JSON and CBOR (with their security mechanisms).
>
>         It is obviously a pain to implement both encodings. The spec
>         supports two encodings because the OTrP design was based on JSON
>         / JOSE and it felt logical to “inherit” this encoding. Then, we
>         added CBOR and COSE for use with constrained devices.
>
>         I believe we should only have one encoding.
>
>         CBOR and COSE appear to be the better choice (although I have
>         been working on an implementation of JSON and JOSE at the
>         Hackathon). While JSON/JOSE is easier to debug the TEEP protocol
>         is actually quite simple. The use of CBOR/COSE will allow us to
>         keep the trusted computing base smaller considering that SUIT
>         manifests as well as EAT tokens are/can be encoded in CBOR and
>         protected by COSE.

The Hackathon at  Berlin was really productive and thanks.

I personally do not mind if the protocol spec becomes having only
CBOR/COSE and drop JSON/JOSE.

I think we have two discussion on this topic, one is completing the
draft and other is whether the TAM
implementation must support support both CBOR and JSON.

It is very good to have some kind of reference implementation of TEEP
along side with the spec draft,
so I would prefer having the current implementation started on JSON to
be finished and fill out the
details in the spec for what we have discussed during the Hakathon.

The sequences of TEEP in JSON which I was wroking on at the Hackathon
are still not mature.
https://github.com/ietf-teep/teep-protocol/issues/7
The suit representation is not there yet either.

These are the links I would like to reflect on the draft before the
next IETF hackathon.
https://github.com/ietf-teep/architecture/issues/151
https://github.com/ietf-teep/teep-protocol/issues/6
https://github.com/ietf-teep/teep-protocol/issues/5
https://github.com/ietf-teep/teep-protocol/issues/4 <- we had
conclusion at the Hakathon on this

Otherwise I am bit concerned many people having different
interpretation from reading the draft and
many implementation suffering interoperability.
Once the details is addressed in the JSON then having CBOR
representation in the spec is fine.
The cbor-diag tool mentioned by Carsten at the other thread is great.
It is good if somebody starts CBOR implementation in the time being.

My thought was that switching to CBOR only and no JSON now for the
Hackathon is that the
TAM side is possible to talk CBOR relatively easy since there is "npm
install cbor" to use cbor
library with javascript, but for the implementation on TEEP device
side, there are cn-cbor and
tiny-cbor for c language which is not so easy for try and error and
changing the message
formats while the draft is also moving.

The other topic of requiring the TAM to support both JSON and CBOR in the draft,
I do not feel that it should have to support both.
TAM talking otrp with json or/either teep with cbor is fine for me.

-Akira

On Fri, Feb 21, 2020 at 6:49 PM Henk Birkholz
<henk.birkholz@sit.fraunhofer.de> wrote:
>
> Hi Tiru,
>
> I'd stay in the scope of CBOR and use cbor-diag. As cbor-diag can be
> directly translated into CBOR data items, that is the notation I am
> working with on a daily basis.
>
> If needed, a JSON data item can be derived from cbor-diag quite easily.
>
> Viele Grüße,
>
> Henk
>
> On 21.02.20 04:43, Konda, Tirumaleswar Reddy wrote:
> > The protocol draft can discuss either CBOR to JSON conversion or
> > diagnostic notation discussed in
> > https://tools.ietf.org/html/rfc7049#section-6 to ease debugging.
> >
> > -Tiru
> >
> > *From:* TEEP <teep-bounces@ietf.org> *On Behalf Of * Mingliang Pei
> > *Sent:* Thursday, February 20, 2020 10:52 PM
> > *To:* Nicolae Paladi <nicolae.paladi@ri.se>
> > *Cc:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep@ietf.org
> > *Subject:* Re: [Teep] JSON/JOSE vs. CBOR/COSE
> >
> > *CAUTION*:External email. Do not click links or open attachments unless
> > you recognize the sender and know the content is safe.
> >
> > ------------------------------------------------------------------------
> >
> > I agree we move forward TEEP protocol with one mandatory format: CBOR /
> > COSE, and focus on specifying only one for now. Thanks, Ming
> >
> > On Thu, Feb 20, 2020 at 6:26 AM Nicolae Paladi <nicolae.paladi@ri.se
> > <mailto:nicolae.paladi@ri.se>> wrote:
> >
> >
> >
> >         On 20 Feb 2020, at 11:16, Hannes Tschofenig
> >         <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
> >         wrote:
> >
> >         Hi all,
> >
> >         With the impression from the Hackathon in mind I am wondering
> >         whether we should make a decision about the encoding of the TEEP
> >         protocol messages. Today, the spec allows two types of
> >         encodings, namely JSON and CBOR (with their security mechanisms).
> >
> >         It is obviously a pain to implement both encodings. The spec
> >         supports two encodings because the OTrP design was based on JSON
> >         / JOSE and it felt logical to “inherit” this encoding. Then, we
> >         added CBOR and COSE for use with constrained devices.
> >
> >         I believe we should only have one encoding.
> >
> >         CBOR and COSE appear to be the better choice (although I have
> >         been working on an implementation of JSON and JOSE at the
> >         Hackathon). While JSON/JOSE is easier to debug the TEEP protocol
> >         is actually quite simple. The use of CBOR/COSE will allow us to
> >         keep the trusted computing base smaller considering that SUIT
> >         manifests as well as EAT tokens are/can be encoded in CBOR and
> >         protected by COSE.
> >
> >     I agree, better to focus on one format.
> >
> >     Best regards,
> >
> >     Nicolae
> >
> >
> >
> >         With this email I wanted to kick-off a discussion. What do you
> >         think?
> >
> >         Ciao
> >
> >         Hannes
> >
> >         IMPORTANT NOTICE: The contents of this email and any attachments
> >         are confidential and may also be privileged. If you are not the
> >         intended recipient, please notify the sender immediately and do
> >         not disclose the contents to any other person, use it for any
> >         purpose, or store or copy the information in any medium. Thank
> >         you. _______________________________________________
> >         TEEP mailing list
> >         TEEP@ietf.org <mailto:TEEP@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/teep
> >         <https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
> >
> >     _______________________________________________
> >     TEEP mailing list
> >     TEEP@ietf.org <mailto:TEEP@ietf.org>
> >     https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
> >
> >
> > _______________________________________________
> > TEEP mailing list
> > TEEP@ietf.org
> > https://www.ietf.org/mailman/listinfo/teep
> >
>
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep