Re: [xacml] Returning a Request Context in the Decision Request Protocol

[Erik Rissanen <erik@axiomatics.com>]

Hi Hal and all,

See inline.

Hal Lockhart wrote:
>> Hi Hal,
>>
>> This sounds ok to me provided that I have understood corretly that a
>> simple way to implement this is to simply echo back the whole request.
>>
>>     
>
> That has always been my intention and still is. Do you think we need additional wording to make this clearer?
>   

I think the wording is good. I just wanted to make sure I understood it
correct and did not read anything unintended in it. :-)

> As an aside, there are 2 primary use cases for this functionality.
>
> 1. A signed response can act as an auditable proof that access was officially authorized.
>
> 2. A signed response could be presented to a PEP as a ticket to enable access (capability model).
>
> As I said on the last call, policy debugging is not an intended use case.
>
> Sending all the attributes works fine for case #1. For case #2, the fewer attributes present, the more situations the ticket will apply to. Also the PEP's task of determining if the ticket is applicable to the situation in questions will be easier the fewer attributes are present.
>
> (Standards best practice says that specs should not specify the intended use of features, simply their syntax and semantics. However, we should document this kind of thing someplace.)
>   

I agree with the above.


>> Also, I would like all this to be optional to implement since it's an
>> overhead to reconstruct a new request with all the "internally found"
>> attributes.
>>     
>
> I would prefer requiring it to be implemented, but allowing a minimal implementation to simple echo the original request context. (That is what my proposed wording says.) The TC will have to decide this issue.
>   

My worry is not echoing back the original request. It's about collecting
the dynamically fetched attributes. But, when I read it again, I see
that it's already a MAY: 'If the value of the InputContextOnly Attribute
in the Request is "False", the PDP MAY include additional XACML
Attributes in this <xacml-context:Request> element, which were obtained
by the PDP and used in making the authorization decision.'

So, I am all fine with your proposed text.


> This reminds me that we really do need to define the metadata necessary to determine the capabilities and options implemented by the PDP.
>   
Agreed, but let's wrap up the core first. :-)

Best regards,
Erik