There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) and data format. COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS.
Grüße, Carsten > On Oct 2, 2019, at 14:00, Cigdem Sengul <[email protected]> wrote: > > Hello all, > > I am trying to implement this discussion in the draft. A point is raised > about COSE keys in JSON messages. > Could it be possible to go with: > (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT > or > (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT > without mixing anything? > > (1) we thought to describe by default in the document, and (2) we said MAY be > supported. > Is there a problem with this approach? > > Thanks, > --Cigdem > > > On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul <[email protected]> wrote: > Hello, > Yes, we thought supporting JSON option would be good, though indeed there is > no issue with transporting CBOR.. > If there are no other concerns, we can define the new media type in the MQTT > draft. > Will add the issue to GitHub repo. > > --Cigdem > > On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad <[email protected]> wrote: > > > > -----Original Message----- > > From: Ace <[email protected]> On Behalf Of Ludwig Seitz > > Sent: Monday, June 3, 2019 11:51 PM > > To: [email protected] > > Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs > > JSON > > > > On 01/06/2019 02:51, Jim Schaad wrote: > > > Ludwig, > > > > > > I have been doing some adaptions of my codebase for dealing with the > > > MQTT specification. In the process of this, I have identified the > > > following items that I think needs some discussion. They may not need > > > changes in any documents and maybe should get a new document. > > > > > > 1. The MQTT document is using the content type "application/json" > > > over HTTPS for transporting messages. Does there need to be an > > > "application/ace+json" defined as a media type, but not necessarily a > > > CBOR media type? I think the answer may be yes, but it could be a new > > document. > > > > > I would argue that the first draft using such a media type would be the > > right > > place to specify it. However I'm not sure using JSON is the right approach > > for > > an ACE specification at all, aren't we supposed to cater for the constrained > > world? > > What is there to prevent us from transporting CBOR over HTTP? > > There would be no reason that one cannot transport CBOR over HTTP. During > the discussions for these drafts Hannes was very explicit that he wanted to > be able to use JSON rather than CBOR with the protocol that was defined by > ACE. This would mean that there needs to be an ability to use JSON with the > ACE framework document. > > I would have no problems with the statement that the MQTT document would be a > good place to define the new media type. > > > > > > 2. If I use a "COSE_Key" confirmation method inside of an > > > application/ace+json message, there is a potential problem and it > > > could be dealt with in a number of different ways. > > > * The JWT confirmation method is identified as "jwk". The COSE key > > > must be translated into JOSE even if there is no equivalent key in > > > JOSE. I.e. that is a fatal error > > > * This does not make sense and the confirmation method should be > > > changed to "cwk" so that either key format could be used in either > > encoding. > > > > > > > If we use JSON messages mixing in COSE becomes awkward. If the use case > > calls for JSON, I'd argue it should also use RFC7800 instead of > > draft-ietf-ace- > > cwt-proof-of-possession. > > I would not have a problem with this, it was one of the options above. I was > just expanding my code to allow for JSON to be used and ran into this. I > just wanted to get a clear group decision on this before I put things into > stone. > > Jim > > > > > > 3. If the confirmation is changed, you would need to convert the COSE > > > key to a binary string, base64 encoded it and pass as a string when > > > occurring in a JSON encoding. There is not any other valid way to do > > > this (except see above of just converting the key format). However, > > > the opposite of putting a JOSE key into a COSE confirmation has three > > > different options that could be used. > > > * Encode the JOSE key to a string and pass as a string > > > * Encode the JOSE key top level map as CBOR but leave all of the > > > elements alone. > > > * Encode the JOSE key in CBOR including conversion of base64 strings > > > to binary data. > > > (My first preference is probably the second option, but either of the > > > first two make sense.) > > > > > > Jim > > > > > > > I'm still unsure that there is a good use case for transporting JOSE keys in > > CBOR, but if such a case turns up, I would agree that touching the encoding > > as little as possible is a good idea (=option 1 or 2). > > > > /Ludwig > > > > -- > > Ludwig Seitz, PhD > > Security Lab, RISE > > Phone +46(0)70-349 92 51 > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
