Re: [xacml] [model] Proposal of Post Condition

[bill parducci <bill@parducci.net>]

the difference between these approaches appears to be where the PDP's 
responsibility ends. as i see it, if you use the <Condition> element 
approach, the PDP still maintains some level of implied responsibility 
for seeing that this condition is met ('registering in the 
post-condition conponenet'). on the other hand, extending the 
<AuthorizationDecisionStatement> element releases this responsibility to 
the PEP ('i issue a GRANT, however i base that upon the stipulation that 
*you, the PEP*, will discard this access 30 days hence.')

either way, the GRANT is issued without waiting 30 days, but the latter 
approach appears more in line with the concept of this being a 
'stipulation' or 'constraint' rather than a 'condition' (which to me 
implies that it's completion is requried to generate the GRANT -- 
clearly not the case here)

obviously, a level of implied trust is inherent in this approach (hey, 
if you can't trust the PEP who can you trust? :o); this is not 
enforceable by the PDP, however if the behavior of the PEP is to DENY 
unless it can interpret (and fulfill) the stipulation, it sees that you 
would have a workable solution.

b

NISHIMURA Toshihiro wrote:

> Hi Kudo-san,
> 
> 
>>If <Conditions> element is used, your concern might be considered. But as I
>>wrote in the previous mail, my position is that the semantics of the
>>post-condition depends on each application. If the application uses simple
>>post-condition like "log", the meaning of the assertion with condition
>>differs as you described. But if the post-condition is "delete in 30days",
>>it is meaningless to wait 30days to give the grant decision to the
>>requester and I think that PEP grants the access to the request after it
>>registers the "delete in 30days" post condition to the post-condition
>>management component. In this case, there is no big difference between two
>>cases you pointed out because even if the delete operation fails after 30
>>days, there is no way to cancel the grant decision issued 30 days ago.
>>Anyway the application should deal with this exception independently. I am
>>quite optimistic that application-specific exception handling can solve
>>this kind of problems.
>>
> 
> You mean that post-conditions are just informative (as you wrote) and
> they don't affect the validity of the assertion like the example of
> "delete in 30days".
> Then I don't like see them in <Conditions> element.
> 
> When we put post-conditions in <Conditions> element, we must extend
> SAML <Condition> element (I noticed it today). Then how about
> extending SAML <AuthorizationDecisionStatement> element? SAML allows
> to extend it.
> It will look like as follows:
> 
> <element name="AuthorizationDecisionWithPostConditionStatement"
>     type="xacml:AuthorizationDecisionWithPostConditionStatementType"/>
> <complexType name="AuthorizationDecisionWithPostConditionStatementType">
>   <complexContent>
>     <extension base="saml:AuthorizationDecisionStatementType">
>       <sequence>
>         <element ref="xacml:PostConditions"/>
>       </sequence>
>     </extension>
>   </complexContent>
> </complexType>
> 
> 
> Regards,
> Toshi
> ---
> NISHIMURA Toshihiro (FAMILY Given)
> nishimura.toshi@jp.fujitsu.com
> XML Application Technology Dept., PROJECT-A XML, FUJITSU LIMITED
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>