> -----Original Message----- > From: Carsten Bormann <c...@tzi.org> > Sent: Tuesday, June 30, 2020 8:35 AM > To: Jim Schaad <i...@augustcellars.com> > Cc: draft-bormann-core-ace-...@ietf.org; ace@ietf.org > Subject: Re: [Ace] Extended REST model comment > > On 2020-06-30, at 16:43, Jim Schaad <i...@augustcellars.com> wrote: > > > > In trying to formalize a policy for the RD testing, I ended up with > > something that I think needs to be noted in this section. There is a > > difference between the following statements: > > > > Access is granted to resources created by the client. > > Access is granted to resources that could have been created by the client. > > > > The first is what the text seems to cover. This make sense in for the > > coffeepot where only the person who created the order should be able > > to cancel it. (Well maybe an administrator might need to as well.) > > However it does not cover the case where an installer created a number > > of entries in the RD. A QA person then comes through to make sure the > > installation was done correctly. When he finds a problem, the first > > statement requires that the original installer come out to fix it > > while the second statement allows the QA person to make the fix. > > Hi Jim, > > interesting. I was thinking about #1 — I can make a coffee, I can cancel > making it, you can make a coffee, but you can’t cancel my coffee. > Or delete my RD entry, etc. So making the resource confers ownership (really: > a separate set of permission bits) that is bound to the subject. > > In my view of how permission systems usually work, the other alternative > requires creating a group. The inherited permission would then be attached to > the group. > Since AIF is about capability lists, not about subject identities, I think we > are > covered — just have the capability list on the group.
[JLS] I would agree that there is no need to make any changes in the AIF structure. I would just like to see some text discussing that policy can enforce this in either way. Jim > > NFSv4 permissions probably also have a way to handle this kind of inheritance, > but I’ll not have time to look that up today... > > Grüße, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
