Re: AW: [xacml] Walkthrough of multiple profile (related to publicreview issue #11)

[Erik Rissanen <erik@axiomatics.com>]

Paul,

 From my experience in working within the XACML TC, I would say that in 
many cases the best way to discuss things is to propose concrete 
changes. There are several problems with discussing just ideas. Ideas 
are ambiguous since the idea still needs to be transformed into a 
concrete spec. It is much clearer to go directly to the spec. 
(Naturally, there is also a role for idea sketching as well early on 
since a full proposed change can be lots of effort to do.) I understand 
Rich's ideas much better with his proposal, than without it.

Another benefit of a concrete proposal is that if the proposal is good, 
then that's part of the delivery of the spec, meaning that we have done 
meaningful work. So it may be waste of time to spend lots of time 
writing down ideas in a form which cannot be a part of a spec in the end.

So, I think it is time to start presenting the ideas in more concrete 
form. Then all the problems as well with the ideas will surface. For 
instance, it is easy to say that we need to define a form of xpath 
expressions which can be regexp-matched. I don't think that is so easy, 
and I would invite a concrete proposal from the proponents of that idea. 
Then you will see all the issues. ;-)

Anyway, I get the feeling that the multiple and hierarchical profiles 
are not going to be ready anytime soon, and I think we should consider 
dropping them from this round and give them another six months or so to 
mature. I think the attribute selector with the offset can fix the 
multiple profile for XPath, so we can put that in the current core and 
go with that, and do the rest of multiple and hierarchical when they are 
ready.

Best regards,
Erik



Tyson, Paul H wrote:
>  
>
>   
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com] 
>> Sent: Wednesday, October 14, 2009 10:19
>> To: Jan Herrmann
>> Cc: xacml@lists.oasis-open.org
>> Subject: Re: AW: [xacml] Walkthrough of multiple profile 
>> (related to public review issue #11)
>>
>> Yes, it appears to me too that the discussion is going in circles.
>>
>> So can you make a concrete proposal with specific text for 
>> how you would like to change the profile, so we can move forward?
>>
>>     
>
> I do not think we are ready to consider textual amendments to the
> profile without further discussion of the issues.
>
> We might be close to putting specific proposals up for vote, so we
> should try to collect those proposals.  Unfortunately, they are not
> orthogonal, but we can at least group the related ones together and
> consider each group.
>
> I think Jan is proposing:
>
> #1: Specify the form of the generated xpath resource-id when creating
> single decision requests from a multiple decision request, so that it
> can be tested with regexp match.
>
> I have several objections to this proposal, but I think another defect
> should be addressed first:
>
> #2: Do not allow context handler to change attribute values supplied in
> the original request context.
>
> The notional model of creating single decision requests from a multiple
> decision request introduces this requirement in the case of xpath
> resource-ids.  It should be remedied, either by changing the original
> request attribute id to "resource-selector", or the generated attribute
> ids to something like "authorized-node-id", or "decision-resource-id".
>
> Rich has proposed:
>
> #3: Provide an alternate resource identification method, using
> namespaced URIs to describe portions of an XML document that is not
> available in the decision context.
>
> And my favorite:
>
> #4: Provide an optional attribute on AttributeSelector to set the
> context for xpath evaluation at the node on which the decision is
> requested.
>
> And there are more.
>
> We should try to move from discussing issues to submitting proposals
> that can be voted on.  But the discussion has been very good, and we're
> not through yet (or maybe I'm just slower than than the rest).
>
> Regards
> --Paul
>