Re: Comment on the paper by Rotondi, et al.
"Karp, Alan H" <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <8AD823089998C849A832D86972E69CD53E7C5C74@G4W3222.americas.hpqcorp.net> |
Some more comments. (I bet you thought you were through with me.) Section 5.4: We found that using the standard SAML Authorization assertion gave our Zebra Copy work a lot of credibility. Have you received any resistance because you’re using a non-standard schema? Section 6: You discuss the issue of privacy in two senses, delegatees can’t identify the delegator the delegator can’t identify the delegatee. I believe you can achieve the same properties using petnames and one-off public/private key pairs. Consider the example in Figure 11. Start with the root capability, which has an empty Assigner ID in your scheme. It gets delegated to [email protected]<mailto:[email protected]>, but the Assignee ID can be anything that the delegator finds meaningful, say Fred. This designation will be meaningless to Bob when the [email protected]<mailto:[email protected]> creates Access Capability A1. Furthermore, if Bob uses a zero knowledge proof to demonstrate that he should have the capability, Bob can use a one-off public key when requesting the delegation. Nobody will be able to associate this public key or the Assignee ID with Bob. Of course, you can always encrypt the Auth. Capability if contains recognizable identifiers. Section 7: I don’t believe you need a full Public Key Infrastructure, but you do need to be able to handle public/private key pairs. It all comes down to how the delegator knows that the delegatee should be given the capability. For example, Bob authenticates to SYP.com using a userid/password and presents a one-off public key. SYP.com will delegate a capability to that public key, which Bob can use because he knows the corresponding private key. PK but no PKI. Bottom line: Nice work and a nice paper describing it. ________________________ Alan Karp Principal Scientist Enterprise Services, Office of the CTO Hewlett-Packard Company 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk