I do think this functionality is useful even for P2P SIP applications (perhaps not for the exact SIP usage we define first), but, I'd be okay with specifying this in a separate document. However, when we do specify that, we will be potentially going through an exercise of revisiting our authorization design and that's the main reason I'd like us to spend a bit of time thinking about it at this stage. Whether we use RBAC or classic ACLs, when an authorized user/node updates data that is stored previously by a different creator, it will no longer match the h(user id) or h(node id) requirement and that should intentionally be allowed.
This can be done, but, there are still a couple of non-trivial questions here. Is there a primary user/node that applications need to use as the resource names? What happens when there is no such obvious primary user/node? Especially in the context of RBAC, it gets more complex than that - since you are assigning access to roles and mapping users/nodes to various roles, authorization needs to happen against the role and not against the user id specifically. And it also brings the question of who defines the roles (and no, it can't be the enrollment server :)) - the roles may be specific to usages and I can't immediately see how it can universally apply to all overlay nodes and kinds supported. RBAC is arguably more useful for supporting groups, but, it is unclear to me that there is an advantage or even a straightforward applicability for normal overlay storage authorization. I'm concerned that going down a path for authorization now that might limit definition of ACLs later might be a problem. I'm willing to keep the documents separate for simplicity, but would like to have a better indication that we are going down the right direction to add this capability later. Cheers, Vidya > -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > Sent: Friday, April 10, 2009 1:46 PM > To: Narayanan, Vidya > Cc: [email protected] > Subject: Re: [P2PSIP] Access control lists for RELOAD storage > > > As a generic concept, I like this and I'm sure there will be cases > where this will be useful but it's not needed for the P2P SIP > application and it is going to open up lots of interesting topics on > how to created ACLs. (I for one will argue more for RBAC instead of > classic ACL). So as an draft that is an extensions to the base, I'd > certainly be keen on this and see it as useful but I would argue it > should not go in the base draft - it's not needed for many > applications and it will take some time to get done. > > Cullen <in my individual contributor role> > > On Mar 26, 2009, at 6:57 PM, Narayanan, Vidya wrote: > > > At the moment, RELOAD defines some access control rules that allows > > authorization of a node/user to store at a particular location. > > However, only that node/user may modify or overwrite the data. It > > does not allow a mechanism to authorize other nodes or users to > > modify the data. I think it is very useful to also have provisions > > for authorizing other node ids or user names that can modify the > > data. As a simple use case for this, consider multiple members of a > > family being able to modify the mapping for the SIP AOR of their > > home phone. There are plenty of other cases as well where data > > created by one node may be modified by other authorized nodes. > > > > For this purpose, I think defining an ACL that is allowed to be > > stored with the data might be appropriate. The creator may specify > > a list of node ids or user names that are authorized to modify the > > data. > > > > We can discuss further on the actual solution options, but, I'd > > first like to get feedback on the topic itself to see if people > > agree this is worth addressing. > > > > Thanks, > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
