Re: [Ace] Transaction model

[Olaf Bergmann <[e-mail]>]

Eve,

Eve Maler <[e-mail]> 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