OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Returning a Request Context in the Decision RequestProtocol


> 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 <xacml-
> context:Request> element in the <XACMLAuthzDecisionStatement> element in
> the <XACMLResponse>. This <xacml-context:Request> element SHALL include
> all those XACML Attributes supplied by the PEP in the
> <XACMLAuthzDecisionQuery> that were used in making the authorization
> decision. The PDP MAY include additional XACML Attributes in this <xacml-
> context:Request> element, such as external attributes obtained by the PDP
> and used in making the authorization decision, or other attributes known
> by the PDP that may be useful to the PEP in making subsequent
> <XACMLAuthzDecisionQuery> requests.
> >
> > I propose we change it to:
> >
> > If this attribute is "True", then the PDP SHALL include the <xacml-
> context:Request> element in the <XACMLAuthzDecisionStatement> element in
> the <XACMLResponse>. This <xacml-context:Request> element SHALL include
> all those XACML Attributes supplied by the PEP in the
> <XACMLAuthzDecisionQuery> that were used in making the authorization
> decision. A conforming PDP MAY omit those XACML Attributes which were not
> referenced in any policy which was evaluated in making the decision. 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.
> >
> > Hal
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]