Subject: Re: [Ace] Solution comparison

From: Olaf Bergmann <[email-masked]>
Date: Sun, 01 Nov 2015 14:18:20 +0100

"Kepeng Li" <[email-masked]> writes:

> I uploaded the chairs slides for the ACE session tomorrow morning.
>
> The last slide is the solution comparison table:

Thanks for collecting this.

Adhoc, I have a few addtions (more are likely to follow soon): 

* "Architecture"
  * "Have CAS"/"No CAS" is not that catchy. Maybe it would be better
    to describe the consequences: DCAF supports cross-domain multi-owner
    scenarios, while the OAuth-profile only supports cross-domain or
    multi-owner, but not both at the same time.
  * Another consequence of having a CAS is that DCAF protects both sides
    of the communication between C and S, not only the resource side as
    done by the single-AS models such as the OAuth-profile.

* "Fit into Constrained Environments"
  * OAuth-interoperability has been demonstrated, token introspection is
    not covered by DCAF itself because it is another protocol; but
    nothing in DCAF precludes doing that
  * it should be noted that both, the client and the server can be
    constrained (for "OAuth-Profiling", the client can be constrained
    only in the single-domain scenario, though)

* "Security"
  * The constrained C and RS get a dynamically created symmetric session
    key. All other communication, especially between CAS and RAS can be
    asymmetric, of course. This includes the OAuth-typical scenario,
    where C and CAS are combined (as in "OAuth-Profiling").
  * DCAF can be used with DTLS or COSE (even intermixed)

* I suggest to add an additional item "Privacy"
  * DCAF does not need identifiers on the constrained-level that could
    be tracked
    
* "Communication Models"
  * in addition to the client-initiated ticket request model and the
    server-initiated ticket request model (Selander/Seitz call them
    "push" and "pull"), DCAF also supports the "client-pull" model.
    RS can be offline in the client-initiated ticket request model and
    in the "client-pull" model;
    C can be offline in the server-initiated ticket request model

* "Implementations"
  * Do "Less" and "More" mean the number of implementations? Given that
    draft-seitz-ace-oauth-authz has been submitted two weeks ago, and
    draft-ietf-cose-msg is not that old either, while the core of DCAF
    is stable for over two years now, I doubt that there will be a
    significant difference in the number of implementations.   

Grüße
Olaf