On Dec 18, 2017, at 14:01, Hannes Tschofenig <[email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
