Cullen, I'm okay going with option b you mention below. I think disambiguating node and user ids might be useful. And, I don't think it is unreasonable to limit future updates to using the same id that was used at the time of creation.
Cheers, Vidya > -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > Sent: Friday, April 10, 2009 1:34 PM > To: Narayanan, Vidya > Cc: [email protected] > Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic > keyword-like storage > > > Vidya, I like this and think we should add it to the draft but one > question. I worry about it being a bit vague of it if is a > certificate with same user id or node id that is allowed to do an > update. I think we need to do one of two things > > a) define this so the nodeid and userid are stored and a certificate > that matches either the nodeid or userid is allowed ot update > > b) define two new rules here, one that requires the node-id to match > and ones that requires the userid to match. So we would have something > like > NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE > and > NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE > > I'd probably prefer approach b to aproach a but don't feel strongly > either way. > > Thougths? > > Cullen, in my individual contrubotro role > > > On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote: > > > In addition to the access control rules defined in section 6.3 of > > the draft, I think there is a need for a rule, where any node is > > allowed to write to a Resource ID, but, only the creator is allowed > > to modify or overwrite the entry by default. This allows for > > generic keyword-like storage on the overlay which will eventually be > > needed to support various types of kinds and usages on the overlay > > effectively. The notion here is that no authorization is needed on > > the Resource ID, but access control is applied to the data > > operations, once it exists. Here is suggestive text for supporting > > this: > > > > "6.3.6. NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE > > > > This policy allows storage of data with no constraints on choosing a > > Resource ID. However, by default, only the creator of the entry is > > allowed to modify or overwrite the stored data once created. The > > user name and/or node id present in the certificate of the > > requesting node MUST be used as the creator of the data. Upon > > receiving a request to store, a node MUST verify if it already has > > an entry present for the particular kind and Resource ID > > corresponding to the same user name or node id that is contained in > > the Store Request. If so, the received Store Request MUST be > > treated as an update to the existing data and the appropriate checks > > as described in section 6.4 must be applied. If no corresponding > > match is found, the StoredData contained in the Store Request > > message MUST be stored as a new entry in accordance with section > > 6.4. This rule is useful for generic keyword-like storage on the > > overlay, which is likely to be useful for several classes of > > applications that may b > > e defined for use with RELOAD. The access control allows ensuring > > that the data created by a given node is not randomly overwritten by > > any other node." > > > > It may be good to include the Resource Name in the StoredData > > structure as well. This will allow the storing node to more easily > > create an index of the resources it is storing, which can then be > > used for retrieval of data. However, I think it will work even > > without it - I'm looking for other thoughts on this. > > > > 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
