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
