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