RE: [xacml] request and response context schema

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: RE: [xacml] request and response context schema

Hi Simon,

----------
From:   Simon Godik[SMTP:simon@godik.com]
Sent:   Thursday, May 16, 2002 9:23 AM
To:     Carlisle Adams
Cc:     xacml@lists.oasis-open.org
Subject:        Re: [xacml] request and response context schema

Hi Carlisle,
 
1) In AttributeDesignator, should Issuer be a string or an anyURI?  You currently have it as an anyURI but I wonder if string would be a better choice (note that it is a string in the SAML Assertion).

 
Issuer can be a string, although I prefer uri.

 
I have a slight preference for URI as well, but if it shows up in a SAML assertion as a string, will it be trivial to transform this to valid URI syntax?  It just seems to me that the transformation from the protocol inputs to the XACML context might be easier if we keep the type as string.  If that's not true, then I have no problem whatsoever with URI.

2) In ResourceSpecifier, I would suggest changing "ResourceURI" to something like "ResourceLocator", since this more clearly says what it is for.  Also, I would add another attribute called "ResourceName" (of type anyURI).

 
Could you please explain more what ResourceLocator will be used for?

 
What I recall from our discussion was that people wanted to have the ability to put the actual resource content in the context in some cases, and in other cases to put a pointer to the content (i.e., a URL for the resource).  When I read your schema for ResourceSpecifier, I assumed that "ResourceURI" was the (optional) locator.  Lower down in the schema (in DecisionType), you introduce "ResourceName", which hadn't appeared before.  So, all I was suggesting was that "ResourceURI" change its name to reflect the fact that it is going to be the URL form of the anyURI type, and that a new attribute be added for "ResourceName", which is what would be copied into DecisionType.

3) It is not clear to me why DecisionType has been defined.  It seems to me that in many cases it will not give sufficient information (in particular, "Permit Read FileX" is not an appropriate answer if the question is "can Joe Read FileX?").

 
Do you think 'subject' should be included as well in 'decision-type'? I was thinking that subject could be matched
from the input context, but it also could be included in the output context.
 
4) If DecisionType is kept, Action should be of type string (not anyURI), and I would recommend adding the element AbstractPrincipal (to address my concern in (3)).  All three pieces of information (i.e., ResourceName, Action, and AbstractPrincipal) should be optional.

 
I agree that we could extend decision-type with principal information (see above).
Why do you think action should be made into a string? If it is a string we need additional attributes on the <action>
element to classify it.

 
OK.  I would suggest adding principal information to DecisionType.

I only suggested changing Action to string in DecisionType so that it would match the definition for Action earlier in the schema (the <Action> element immediately under <ContextActionType> is of type "xs:string").  I'm just suggesting that the input and output contexts should have types that match whenever they're talking about the same elements...

Carlisle.