Re: [Ace] Relaxing OAuth-ACE profiles

[Carsten Bormann <[e-mail]>]

On Dec 18, 2017, at 14:01, Hannes Tschofenig <[e-mail]> wrote:
> 
> 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.

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