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
