Subject: [Ace] Reviewing ace-aif

From: Christian M. Amsüss <[email-masked]>
Date: Thu, 11 Mar 2021 12:28:37 +0100

Hello Carsten, hello AIF,

as promised I've had a look at AIF:

"need to ascertain that other devices they place requests on are the ones they intended"
========================================================================================

This is an important statement which I don't see taken up outside the
introduction. Especially considering how the requester not only needs to
be sure it places the requests on the intended target, but also how to
get from the intention to the operation.

It's hard to place concretely, given that most of the remaining document
talks about the REST and it *is* trivial there (once there is clarity of
the target).

Suggested addition for seccons bullets:

* ensure that both subject and target map Toid/Tperm pairs to the same
  operations.

(This links back to the CoRE RD discussion about a client that wants to
perform a single Toid/Tperm action, but got fed metadata by an untrusted
party that makes it express that to a differen URI on the same target
host, causing a different Toid/Tperm that it may also be authorized for
but did not intend).

"AIF MUST be used in a way that it is unambiguous who is the target"
====================================================================

There might be a case for many alike targets that all receive the same
configuration (thinking of homogenous sensor cloud where a client gets a
token to access any device's /s/temp); s/unambiguous/clear/ would open
it up for that.

REST model / Uri-Query
======================

The way the path tstr includes the Uri-Query seems to indicate the
strict resource definition in which /foo is completely distinct from
/foo?x=y, which I appreciate.

To a reader coming from different mindsets that could be pointed out
more pronouncedly, for example by extending (double asterisks marking
additions):

  One might be tempted to extend the model towards URI templates
  [RFC6570]; **this would open things up for local-parts like
  `/s/temp{?any*}`**. However, that requires some considerations of the
  ease and unambiguity of matching a given URI against a set of
  templates in an AIF object.

Figures
=======

I didn't check the CDDL by running it through a parser, but trust you
did at some point. (Someone with a bit of time at their hands might
want to add support for this at the datatracker, and then we'd have a
nice 🌊🐗 logo where YANG based documents have their ☯ ).

REST on "point of enforcement"
==============================

In all the examples the point of enforcement is a full authority. I'm
currently thinking of a media device roughly described as follows

</media/>,
</media/incoming/>,
</media/animations/>,
</media/sounds/>,
</media.public>;cf="application/aif+cbor";applicable-for=unauthenticated-users,
</media/>;rel=policy-for;</media.policy>

where whoever is authorized to write to /media.public may decide what
inside /media/ is public and what is not (but doesn't get to open up
/config/ to the public).

I *think* from reading the spec that all is in place for such
applications to work (where the way of linking AIF documents to the
subjects is out of scope, as is the relation type and how the relation
type is used to set the target unambig... aeh, clearly).

If it is, I'd leave it up to your judgement whether it's worth words or
not. If it is not, please help me understand why not (maybe it can be
helped) or what I missed that rules it out.

Looking forward to implementing this as an authroization model,
thanks for this document
Christian

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)