Re: [Ace] Relaxing OAuth-ACE profiles

[Hannes Tschofenig <[e-mail]>]

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 terminology) really is about business logic, so go ahead and do XMLDSig and BPEL and SOAP and whatever makes the software architect happy.

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

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.