Hi again,
On 17.05.2011 01:15, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Alexander,
On 05/16/2011 02:41 AM, Alexander Knauf wrote:
Hi Marc,
thanks for your feedback!
On 14.05.2011 01:41, Marc Petit-Huguenin wrote:
My problem is with the 4th paragraph of section 3:
"Access Control Policy: To ensure write access to Shared Resource by
Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access
policy (see Section 5.4) in addition to its regular access
policies (USER-MATCH, USER-NODE-MATCH, etc.)."
I do not see in -base how two (or more) Access Control Policies can be used for
one Kind.
I also see this conflict in the XML overlay config. document that only allows a
single access control policy per Kind. If it would support multiple access
policies, something like this:
kind-parameter&= element access-control { access-control-type }*<-- note the
asterisk, compare with base -13 p.122
the receiver of a store request could iterate over the those policies, trying if
any of them is true.
Well, in this case I suggest that you talk to the -base authors to add this
behavior in the spec (Note that I am not saying that this is a good idea).
Well, we were discussing alternatives to this and have the idea of some
kind of "all-in-one" access control policy. Lets say the USER-CHAIN-ACL
could be defined like:
"a given value must be written if the request is signed with a private
key whose hash..and-so-on"
OR
"must be written if <some text for the other policy> "
We only specify one access policy per Kind that allows two variants for
storage access.
I will send a more detailed review (and will update my access control I-D with
the modifications needed to implement this) when this is decided.
As for the USER-PATTERN-MATCH policy, one problem I see is that the spec does
not define strongly enough the resource_name field. The problem here is that
when storing a value, a peer does not have access to the definition on this
value - and cannot as each kind will have a different definition. This is why
you need to say in the spec something like '... MUST define an "opaque
<0..2^16-1>" field as the first field within the Kind data structure,...". With
this field always defined as being the first in a Kind using USER-PATTERN-MATCH,
the policy code will have no problem finding it.
Also I think that the variable-resource-names element should be inside the kind
element, and that you should also define its namespace.
Thanks for this comment and I agree. We will keep this in mind for next
draft version.
best regards,
Alexander
--
/*************************************************
* Alexander Knauf B.Sc.
* AG INET
* Dept. Informatik
* HAW Hamburg
* Berliner Tor 7
* D-20099 Hamburg, Germany
* Room: 580
* Net:http://inet.cpt.haw-hamburg.de/members/knauf
* Phone: +49 40 42875 - 8067
* Fax: +49 40 42875 - 8409
*************************************************/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
