At Wed, 24 Dec 2008 13:05:26 -0800, Narayanan, Vidya wrote: > > What you are suggesting is to still do kind-specific data > authorization and access control, but allow dynamic addition of new > kinds.
Yes. > I think this works, but, it is simpler to just do this at > the overlay level - this means indicating the type of authorization > used in the protocol (say, we define the 5 or so rules you have > below and allow that to be signaled in the protocol). I don't understand what "signalled in the protocol" means. This is being signalled in the protocol in the sense that the protocol has a mechanism for moving the configuration document around. Having it > tied to the kind allows additional verification that the particular > authorization model is indeed the right one to use for that kind - > unless we need that property, I don't see a reason to tie it to the > kind itself. I'm sorry, I'm not gettign your point here: we already have kinds which we expect to run on the same overlay which require having different access control rules. So, yes, I think that each kind needs to have its own set of rules in a working overlay. > So, I prefer that we signal the authorization rule in the protocol > rather than have this complexity of having kind level knowledge in > order to perform the authorization. > > All that said, I agree with the 5 rules you wrote below. I'd > recommend adding the following: > > - User must have a certificate with H(NodeID || "usage specific string") == > Resource-ID and > - User must have a certificate with H(user_id || "usage specific string") == > Resource-ID > > This allows the flexibility to usages to qualify the data they are storing as > they see fit. I don't really understand how this works. Usages aren't a first class concept in RELOAD. They're just a document organizational concept. The only relevant protocol concept is "kind". If I do s/usage/kind/, is that what you are suggesting? If so, where does the string come from. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
