At Fri, 9 Jan 2009 23:31:48 -0800, Narayanan, Vidya wrote: > > > > > -----Original Message----- > > From: Eric Rescorla [mailto:[email protected]] > > Sent: Friday, January 09, 2009 10:40 AM > > To: Narayanan, Vidya > > Cc: Eric Rescorla; [email protected] > > Subject: Re: [P2PSIP] Dynamically introducing new types > > > > 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. > > > > What I meant was that the type of authorization rule applied will be > indicated in the message, rather than needing to look up a > configuration document.
I'm sorry, I still don't see how this is going to work: the sender and the receiver of the message are potentially adversarial: for instance, the sender may want to delete data belonging to someone else. This means that the recipient needs to be able to determine the correct access control rule in a way that the sender can't interfere with. Otherwise the sender can just choose an access control rule which is most permissive for his purposes. > I'm talking about providing application specific resource name > construction flexibility. A particular usage may decide to allow > its data to be further spread in the overlay. For instance, > sip.voip:[email protected] and sip.im:[email protected] may be > two different objects stored on the overlay by the SIP usage. Here, > "sip.voip" and "sip.im" are specified by the usage. This would be > carried in the message to ensure authorization verification by the > target node. The construction of the string itself is only of > significance to the usage. Again, usages aren't a first class construct, so there's no way for a usage to specify anything like this. That's what kinds are for. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
