Subject: [Ace] Relaxing OAuth-ACE profiles

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Dec 2017 13:01:04 +0000

Hi all,

In off-list discussion the differences between OAuth-ACE, OCF and LwM2M was discussed. One of the distinguishing features of OAuth-ACE is that it allows user authentication and authorization to be conveniently provided and integrated into an already existing ecosystem.

However, after re-reading the OAuth-ACE draft I noticed that the use of a smart phone / tablet for accessing IoT devices is actually not well supported due to the decisions made around profiles.

Hence, I created a pull request that relaxes the OAuth-ACE profiles in the following way:
* It allows profiles to specify what protocols and encodings they use on the client to AS interface (in addition to the client to RS interface).
* It allows the use of HTTPS and JSON encoding on the client to AS interface. Hence, this allows a client to request a CWT-based PoP token using HTTPS from an RS.

Here is the pull request:
https://github.com/ace-wg/ace-oauth/pull/129

Thoughts?

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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Dec 2017 14:14:46 +0100

> * It allows the use of HTTPS and JSON encoding on the client to AS interface. Hence, this allows a client to request a CWT-based PoP token using HTTPS from an RS.

Sure.

draft-ietf-ace-actors tells you that aceclient-AS is a less-constrained interface, so it doesn’t need to be limited to protocols for constrained devices.  aceclient-RS is a constrained interface.  (And at some point the client authorization manager CAM will escape from the aceclient and we get back the more rational four-legged architecture.)

Not sure why you need JSON to use HTTP, but of course this can be opened up because it is the less-constrained CAM-SAM interface.  More generally, the CAM-SAM interface (aceclient-AS in current terminology) really is about business logic, so go ahead and do XMLDSig and BPEL and SOAP and whatever makes the software architect happy.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Dec 2017 11:21:54 +0000

Hi Carsten,

~snip~

> draft-ietf-ace-actors tells you that aceclient-AS is a less-constrained interface, so it doesn’t need to be limited to protocols for
constrained devices.  aceclient-RS is a constrained interface.  (And at some point the client authorization manager CAM will escape from the aceclient and we get back the more rational four-legged architecture.)

We have certainly envisioned this use case early on in the group and it is good that the actors draft covers it. Samuel, Erik and I had used this scenario at ARM TechCon a few years ago as a showcase using a door lock to illustrate what ACE-OAuth does. It is just that the current ACE-OAuth draft version doesn't support it well IMHO.

Even though that interface is not limited we would still have to use some of the newly defined parameters (and features (e.g., CWT).

> Not sure why you need JSON to use HTTP, but of course this can be opened up because it is the less-constrained CAM-SAM interface.  More generally, the CAM-SAM interface (aceclient-AS in current ter…

I might not have used the terminology appropriately but what I was trying to accomplish  is to use RFC 8252 on the phone/tablet and to request a CWT (instead of a JWT). RFC 8252 uses a mixture of technologies, including a JSON-based encoding for the Access Token Response.  The Access Token Request, on the other hand, would be form encoded. Maybe I should include an example in the appendix to make it clearer.

Ciao
Hannes