Re: [Ace] Innovating

[Göran Selander <[e-mail]>]

On 2015-10-31 00:32, "Stefanie Gerdes" <[e-mail]> wrote:

>Hi all,
>
>The solutions in ACE are all reusing existing solutions, they are just
>using different solutions to a different extent.
>
>The use cases show that there is a large variety of scenarios with
>different characteristics. The scenarios differ from the web scenarios
>which is why we founded ACE in the first place. Some of the use cases
>might only require a little tweaking of existing protocols, others need
>more consideration about how those protocols can be applied.
>
>We designed DCAF to address scenarios where the client, the server or
>both can be class-1 devices (see RFC 7228 [1]), where the client and the
>server may belong to different owners with distinct authorization
>policies and where these owners may not intervene in the authorization
>process at the time of the communication. As far as I understand
>draft-seitz-ace-oauth, it only supports less-constrained clients.

No, that is not correct. What gave you that impression? Instead of me
going through how various deployment scenarios in section 6 could be used
with constrained clients, it would be helpful it you gave some reference
to the draft supporting your claim. But just to give an example see
section 6.3:

https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-6.3


In this case the interaction and processing performed by the client could
be restricted to passing a reference token, which can be made arbitrarily
small, to the resource server and then making the resource request. These
two requests could even be combined into one request/response using
optimizations described in Appendix B, see figure 23.

https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#appendix-B

As one concrete use case the client could be key fob using radio energy
harvesting.

Göran



>That
>might be fine for the use cases and devices that you have in mind. With
>DCAF, we go a bit further into the constrained world and want to enable
>constrained devices to securely communicate with other constrained devices
>
>Of course we want DCAF to interoperate with existing protocols. That is
>why we describe how such interactions can work (see
>draft-gerdes-ace-dcaf-examples [2]).
>
>Best regards,
>Steffi
>
>[1] https://tools.ietf.org/html/rfc7228
>[2] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00