OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] Walkthrough of multiple profile (related to public review issue #11)

Erik, you're right about the two different ways of thinking about this.
I always think of it in terms of request/response protocol, where the
PEP knows nothing of what goes on inside the PDP, and the PDP makes no
assumptions about what the PEP will do with the result.  In this model,
the PEP must have a sufficiently well-defined vocabulary for requesting
what it needs to do its job.  And, the semantics of the response must be
sufficiently well-defined to prevent variant interpretations.

I think we've established that "IncludeInResult" needs better
definition.  But there may be a better way to meet at least one of the
purposes of IncludeInResult--specifying how multiple returned Decisions
will be identified.

Defining a DecisionKeyAttributes construct in the Request vocabulary
would allow the PEP to declare how it wants the Decisions identified in
the Response.  "IncludeInResult" is a round-about way of doing this, but
does not carry the direct semantics that you want in a formal system.
It is also limited to attributes that the PEP already has a value for.

Suppose we want to ask which versions of a document Athena can read, and
which she can modify.  The PEP doesn't know what versions of the
document exist, so can't send Attribute[@AttributeId = 'version-id'].
But it could send a request that included the access-subject, the
document identifier, the two action-ids, and a DecisionKeyAttributes

	<AttributeDesignator AttributeId="access-subject" .../>
	<AttributeDesignator AttributeId="document-id" .../>
	<AttributeDesignator AttributeId="version-id" .../>
	<AttributeDesignator AttributeId="action-id" .../>

The policies may not even consider "version-id", but the context handler
would be expected to supply all version-ids for the document, and the
Individual Requests would then be formed for each unique combination of
the DecisionKeyAttributes, which would all be included in the Result for
each Decision.

Aside from the benefit of being able to request attribute return values
that weren't in the orginal request, it is easier to describe the
expected behavior of this approach.  You could also define a
transformation from any request that has "IncludeInResult=true"
attributes to an equivalent request with a DecisionKeyAttributes element
(assuming that the only purpose of IncludeInResult is to provide a sort
of "key" functionality).


> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Monday, October 12, 2009 08:07
> To: Tyson, Paul H
> Subject: Re: [xacml] Walkthrough of multiple profile (related 
> to public review issue #11)
> Paul,
> I think the main issue here is that the XACML Request is 
> described as an abstract concept, not a wire protocol. In 
> most implementations there would be
> 1. An initial access request defined with the XACML <Request> schema. 
> (Possibly embedded in some transport unit.)
> 2. A context handler which can potentially fill in additional 
> attributes.
> The issue here is that the XACML spec is more like:
> 1. A full XACML request exists in an abstract form, which is 
> the combined result of the PEP and the context handler.
> In other words, the core XACML spec does not differentiate 
> between an initial request and stuff that the PEP is not 
> aware of, with regard of the processing model. It hasn't been 
> a problem in the past since the request has been fully hidden 
> to the PEP, but now with IncludeInResult, parts of it are 
> reflected back, which introduces the distinction between an 
> initial request and a full context handler augmented request. 
> Whatever the spec says on this matter is purely by accident, 
> since we have not discussed this distinction, and now is time 
> to fix this.
> So, we should say something on the issue. The model which 
> would place the least burden on the implementation would be 
> to explicitly say that only the attributes sent by the PEP 
> must be reflected back, but I am not sure that is the most 
> useful mode.
> I don't understand your "key attribute" proposal. Could you 
> elaborate on it? How is this different from setting 
> IncludeInResult on several attributes in the request?
> Thanks,
> Erik


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]