OASIS eXtensible Access Control Markup Language (XACML) TC

Section 3.1 of the SAML Profile contains the following text.

If this attribute is "True", then the PDP SHALL include the 

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.

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.

Best regards,
Erik

Hal Lockhart wrote:
> Section 3.1 of the SAML Profile contains the following text.
>
> If this attribute is "True", then the PDP SHALL include the 

> 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?

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.)

> 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.

This reminds me that we really do need to define the metadata necessary to determine the capabilities and options implemented by the PDP.

Hal

> 
> Best regards,
> Erik
> 
> Hal Lockhart wrote:
> > Section 3.1 of the SAML Profile contains the following text.
> >
> > If this attribute is "True", then the PDP SHALL include the 

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 

On Jan 14, 2009, at 9:34 AM, Hal Lockhart wrote:

> This reminds me that we really do need to define the metadata  
> necessary to determine the capabilities and options implemented by  
> the PDP.

Issue #36

Mea culpa :(

b