Subject: [Ace] CBOR and/or JSON

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2016 18:33:05 +0100

Hi all,

specifying the ACE OAuth solution the following design question turned
up: Should both CBOR and JSON be supported in the WG document? Or only
one of them?

What should be described in the WG document:
* Alternative 1: CBOR and JSON
* Alternative 2: CBOR only
* Alternative 3: JSON only

Additionally, there is the question about HTTP and CoAP support.

Should the WG document only describe
* Option 1: Use of CoAP,
* Option 2: Use of HTTP,
* Option 3: Use of HTTP & CoAP

Here are the slides from the ACE virtual interim meeting providing
further background information:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-3.pdf

Deadline: 16th March 2016

Ciao
Hannes & Kepeng

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 2 Mar 2016 20:03:31 +0100

I think that the original scope of ACE should have been more then just
constrained devices. It's a continuum between larger and smaller devices
and it should have been a solution that fits both. We are where we are, so
right now we are building for constrained devices only. That's off course
totally as it should be because that's what the charter and name say so I
don't have any problem with it. But the thing is that I can't imagine that
the industry is using CBOR to a larger extent then they are using JSON.
JSON is the default go to protocol. Alternative 1 option 3 (that's actually
alternative 4 in the PPT) makes it work with both CBOR and JSON over both
CoAP and HTTP and that's my preferred way forward. I am however fine with
alternative 2, option 1 (that's alternative 2 in the PPT), making it CBOR
over CoAP only and later extending it with JSON.
/ Erik

On Wed, Mar 2, 2016 at 6:33 PM, Hannes Tschofenig <[email-masked]
> wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 2 Mar 2016 14:33:17 -0500

On 3/2/2016 2:03 PM, Erik Wahlström wrote:
>  But the thing is that I can't imagine that the industry is using CBOR 
> to a larger extent then they are using JSON. JSON is the default go to 
> protocol.

This is today a true statement.  The balance, however, will shift.

http://openconnectivity.org/resources/specifications, Core Spec...

"An OIC Device shall use CBOR as the default payload (content) encoding 
scheme for resource representations included in CRUDN operations and 
operation responses"

CBOR will also find a home within LPWAN architectures, maybe also 
802.11ah, etc.  Wherever power, bandwidth, and compute resources are 
limited.

One of the advantages of the RESTful approach is the potential to swap 
in/out transport and payload options to fit the deployment. Use HTTP and 
JSON if you can, CoAP and CBOR if you must.  Ideally with as stateless a 
translation as possible between HTTP/CoAP and JSON/CBOR.

> Alternative 1 option 3 (that's actually alternative 4 in the 
> PPT) makes it work with both CBOR and JSON over both CoAP and HTTP and 
> that's my preferred way forward. I am however fine with alternative 2, 
> option 1 (that's alternative 2 in the PPT), making it CBOR over CoAP 
> only and later extending it with JSON.
> / Erik
>
> On Wed, Mar 2, 2016 at 6:33 PM, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 2 Mar 2016 12:03:42 -0800

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, March 02, 2016 9:33 AM
> To: [email-masked]
> Subject: [Ace] CBOR and/or JSON
> 
> Hi all,
> 
> up: Should both CBOR and JSON be supported in the WG document? Or only one
> of them?
> 

This is viable only if we think that we are going to use the same authenticators for both general OAUTH and ACE OAUTH.   It also requires a good mechanism for party A to know which is going to be acceptable for party B and be able to ask for it.  There is a negotiation problem that would need to be solved.

> * Alternative 2: CBOR only

Preferred choice.
> * Alternative 3: JSON only

Based on sizes of messages I don't think this alternative is viable.

> Here are the slides from the ACE virtual interim meeting providing further
> background information:

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2016 12:32:55 +0100

-- chair hat off

I have included the wrong link below. Here is the correct one:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-0.pdf

I would focus on CBOR in the document. This does not mean much from a
presentation style in the document since it will be shown as a JSON
diagnostics form anyway (or at least I think it should for readability).

The CWT content is not in the ACE OAuth document and so it will have no
impact. When we define extensions in CWT they also need to be defined
for the JWT.

For the token introspection we already have the HTTP version in OAuth
and no changes are needed there. I still believe we need a version that
runs over CoAP as well.

For the client I would make a distinction between the type of client:

* For rich clients, like mobile phones, I would allow them to work with
HTTP and no changes should be needed to the OAuth framework.

* For constrained clients, we will have to define a CoAP-based version.

Ciao
Hannes

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 3 Mar 2016 19:21:37 +0100

Hi,
See below.

On Thu, Mar 3, 2016 at 12:32 PM, Hannes Tschofenig <
[email-masked]> wrote:

> and no changes are needed there.

A part from it needs to be extended with aif and cnf claims. A cnf claim is
needed anyway by the oauth http based PoP draft so that will happen anyway.
Aif is very ACE-specific to help a device make an authorization decision.

> I still believe we need a version that
> runs over CoAP as well.
>

Agree, that''s a part of the code ACE framework.

> HTTP and no changes should be needed to the OAuth framework.

The standard oauth http based token response would also need to send csp
with information of how C should connect to the RS and also include trust
anchors to be able to authenticate RS.

> * For constrained clients, we will have to define a CoAP-based version.

+1

All in all, I think this can all be done by only focusing on CoAP and CBOR
in the core ace framework. But I also think that a JSON/HTTP version must
also be crafted very soon after with an alternative draft.

/ Erik

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 5 Mar 2016 22:17:25 +0100

Hi,

My first choice is
Alternative 1 with option 1.
My second choice is
Alternative 2 with option 1.

My reasoning behind this is that, when mapping and extending OAuth
functionality form HTTP and JSON to CoAP and CBOR there will will be cases
where we add new parameters e.g csp (communication security protocol) in
PoP token response or aif in introspection response. In these cases I think
it would be simpler to first register the new parameter in the old OAuth
space and then map it to CoAP and CBOR. If doing like this we might end up
with a Alternative 1 option 3 solution but I think it would be the most
straight forward approach if we want to keep close to OAuth.

With that said I think focus in the spec and in the work should be CoAP and
CBOR.

//Samuel

---

From: Mike Jones <[email-masked]>
Date: Sun, 6 Mar 2016 21:56:42 +0000

For the first question, I support Alternative 1 – the use of JSON and CBOR.  I agree that Erik that JSON is the go-to data format today and that it must be first-class in our specifications.  I am OK with also supporting CBOR.  I *am not* OK doing them at separate times in separate specs, because that’s a recipe for them getting out of sync and one being better supported than the other.

Likewise, for the second question, I support option 3 – the use of HTTP and CoAP.  HTTP is the go-to protocol for most services and MUST be first-class.  CoAP support is OK too, but like the first question, both need to be supported in our specifications in parallel.

All that being said, if the working group wants to go with just JSON and/or just HTTP, I would also be OK with that.

                                                          -- Mike

From: Ace [mailto:[email-masked]] On Behalf Of Erik Wahlström
Sent: Wednesday, March 2, 2016 11:04 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] CBOR and/or JSON

I think that the original scope of ACE should have been more then just constrained devices. It's a continuum between larger and smaller devices and it should have been a solution that fits both. We are where we are, so right now we are building for constrained devices only. That's off course totally as it should be because that's what the charter and name say so I don't have any problem with it. But the thing is that I can't imagine that the industry is using CBOR to a larger extent then they are using JSON. JSON is the default go to protocol. Alternative 1 option 3 (that's actually alternative 4 in the PPT) makes it work with both CBOR and JSON over both CoAP and HTTP and that's my preferred way forward. I am however fine with alternative 2, option 1 (that's alternative 2 in the PPT), making it CBOR over CoAP only and later extending it with JSON.
/ Erik

On Wed, Mar 2, 2016 at 6:33 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes & Kepeng

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 Mar 2016 09:21:06 +0100

> * Option 3: Use of HTTP & CoAP

I would prefer to keep the document short, easy to read and focused on 
constrained environments (it's the 'CE' in ACE remember). Therefore I 
prefer alternative 2 (JSON can be done in a separate document) and 
option 1 (with HTTP in a separate document as well).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2016 13:55:42 -0500

Paul Duffy <[email-masked]> wrote:
    > in/out transport and payload options to fit the deployment. Use HTTP
    > and JSON if you can, CoAP and CBOR if you must. Ideally with as
    > stateless a translation as possible between HTTP/CoAP and JSON/CBOR.

This is true only if you ignore security and signatures.

So let me suggest that the question is mistated.

It's not between JSON and CBOR.

It's between JOSE and COSE, and due to the signature, they are not
mechanically transcodeable.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-