Hi Christian, It seems I haven’t looked at this for a while. It’s been two months now 🤦♂️, so let me try to make some progress:
> On 2021-03-11, at 12:28, Christian M. Amsüss <[email protected]> wrote: > > 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). I think this needs to be further elaborated in a more general context, such as https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ (which has been parked for a while — maybe time to pick it up again?). > 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). Covered that in a half-sentence added to the second bullet (actually, all parties must agree on that meaning). > "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. Slightly edited and added. > Figures > ======= > > I didn't check the CDDL by running it through a parser, but trust you > did at some point. I just did again, and took the opportunity to use the RFC-editor-preferred type value (cddl, not CDDL). > (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 ☯ ). We’d need a bit of threading to make this work well… Stuff for CDDL 2.0! > 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. I do think that an extended example would be useful. Maybe over in the T2TRG restful design draft? All changes are in https://github.com/cabo/ace-aif/commit/8990b05 Grüße, Carsten _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
