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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
