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
