Re: [Ace] Review of draft-ietf-ace-oauth-authz-07 by Mike Jones

[Ludwig Seitz <[e-mail]>]

On 2017-10-10 19:30, Anthony Nadalin wrote:
> The point here about the optional extensions is that not all devices
> are constrained the same, so some devices may actually be able to
> support Oauth yet you prohibit that from happening with the mandatory
> extensions

I'm assuming that you are considering a scenario where some devices are 
less constrained while others are constrained, otherwise using ACE makes 
no sense in the first place (you could just use OAuth).

The main requirement that precludes mixing plain OAuth with ACE-OAuth is 
that protocol parameters need to be encoded in CBOR instead of JSON.

If we made this optional, a client could make a request to the token 
endpoint using plain OAuth (i.e. unabbreviated parameters).

I see the following undesirable outcomes from such a solution:

a.) The AS has to support both abbreviations and full parameter names
(more code complexity at AS).

b.) We need some protocol mechanics to tell the AS whether the client is 
using regular OAuth or ACE-OAuth (more code complexity at both client 
and AS, more protocol complexity, possibility of mixup errors).

c.) RS that need to do introspection need the same protocol mechanics as 
in b.)

I don't believe this is a good trade-off.

Note that nothing precludes you from using regular OAuth, as long as the 
client and AS support it and the RS can process the resulting access token.

/Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone [phone]