Subject: Re: [Ace] Transaction model

From: Eve Maler <[email-masked]>
Date: Sun, 5 Apr 2015 12:12:50 -0700

Hi Robert,

This nicely symmetrical diagram may be obscuring the fact that the relationship is still pretty asymmetrical. The client, by virtue of wanting a resource that it has identified (or whose location it has been provisioned with), essentially  “trusts” that resource and resource server already. And because it is in the position of requesting the resource (let’s think of it as a “request-response” pattern), there’s already an asymmetry there too. The policy that the client and its owner thus apply to the proposition thus typically happen “off-stage” with respect to the authn/authz aspects of the picture.

You can see lots of asymmetry revealed in the “Binding Obligations” discussion here <https://tools.ietf.org/html/draft-maler-oauth-umatrust-02> (hmm, looks like we need to refresh this doc — the UMA group is on the cusp of picking this work up again now that the technical substrate is stable). Although the Binding Obs doc uses different names than CO, AM, etc., it has roughly the same piece-parts; what it does is attach basic contractual obligations to pairs of parties corresponding to the software/human entities in the picture, whenever a significant state change occurs. Typical examples of significant state changes are things like token issuance.

(There is, I believe, one main difference between the UMA model and the DCAF-ish model other than terminology. In UMA, the CO/requesting party can be represented not just through an “AM”, but by claims gathered by a flexible choice of sources: the AS (on the RO side), the client, some other third-party identity/claim providers, etc.)

FWIW,

	Eve

> On 23 Mar 2015, at 6:20 PM, Robert Cragie <[email-masked]> wrote:
> 
> Further to the discussion in the ACE side meeting, I came up with this (rather complicated) model which in my mind shows what considerations there are when it comes to just a very basic instantaneous request/response transaction with respect to a resource.
> 
> https://docs.google.com/presentation/d/1qFH5zPoBWx1Rog3OkPwqKnwVd-SNsWsFZR9t7lDFdA0/edit?usp=sharing <https://docs.google.com/presentation/d/1qFH5zPoBWx1Rog3OkPwqKnwVd-SNsWsFZR9t7lDFdA0/edit?usp=sharing>
> 
> Happy to explain it further.
> 
> Robert
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 08 Apr 2015 15:59:13 +0200

Eve,

Eve Maler <[email-masked]> writes:

> This nicely symmetrical diagram may be obscuring the fact that the
> relationship is still pretty asymmetrical. The client, by virtue of
> wanting a resource that it has identified (or whose location it has
> been provisioned with), essentially “trusts” that resource and
> resource server already. And because it is in the position of
> requesting the resource (let’s think of it as a “request-response”
> pattern), there’s already an asymmetry there too. The policy that the
> client and its owner thus apply to the proposition thus typically
> happen “off-stage” with respect to the authn/authz aspects of the
> picture.

The ACE problem statement as presented, e.g., during the WG session in
Dallas, clearly states that Client and Server do not know each other a
priori. Therefore, you cannot automatically assume that there is
pre-established "trust" between the client and the resource server.

For example, the client may have discovered the resource server and its
capabilities by searching a resource directory. Now, before it can
access that resource server, it has to check if the client owner (who
may or may not be the same individual as the resource owner) allows
this.

Sure, you can do this "off-stage", as pointed out in
<http://www.ietf.org/mail-archive/web/ace/current/msg01026.html>, and
there is a lot of authorization protocols that do this. The question
here is whether or not this authorization step is documented. The actors
draft documents this to avoid always having to say that there is this
pre-requisite of having installed a policy (which might be hidden in
program code, of course) out-of-band that establishes the trust between
client and resource server.

> (There is, I believe, one main difference between the UMA model and
> the DCAF-ish model other than terminology. In UMA, the CO/requesting
> party can be represented not just through an “AM”, but by claims
> gathered by a flexible choice of sources: the AS (on the RO side), the
> client, some other third-party identity/claim providers, etc.)

DCAF follows the generic model from the actors draft where the CO/RqP
may or may not be identical with the RO or something else. The nice
thing about the actors model is that it entirely covers the UMA model
(and all others on the table). The major difference between the actors
model and OAuth/UMA etc. is that it explicitly documents the CO/RqP-AM
part in terms of the tasks that are required to check that the
propositions you have mentioned really apply.

The mechanism described in draft-maler-ace-oauth-uma, e.g., perfectly
fits into the actor model (the client and the AM in this protocol would
reside non-distinguishable in the same piece of software).

DCAF also fits into this model, but with DCAF, you have the option to
create an AM that actively performs AM's tasks. This could be a separate
box or another process on the same device, or even the AS. One nice
characteristic of DCAF is that the implementer of the client side can
decide if she wants to have an explicit AM or combine it with the
client. The latter would be the same as UMA/OAuth do.

Grüße
Olaf