Bill wrotes:
><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.')
Extending <AuthorizationDecisionStatement> sounds like more proper
approach.
>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)
I think so, too. Do you think that the term "post-condition" is not the
right word?
If so, what do you think the best term for the notion of this kind?
>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.
I agree.
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
From: bill parducci <bill@parducci.net> on 2002/02/15 11:51
To: "XACML TC <xacml"
cc:
Subject: Re: [xacml] [model] Proposal of Post Condition
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>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>