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] Additional authorization data?


Hi John,

I think the <Obligation> element is what you should use if you want to 
pass additional data. There is nothing in the spec that says that an 
obligation may not have a "null action", and in any case, the act of 
logging extended authorization data is an action in the sense of 
obligations.

You may want to also have a look at the "obligation families" working 
draft which contains additional functionality for combining obligations 
which are in conflict or to provide metadata about obligation 
enforcement. Though, note that the working draft is still in a fairly 
early state.

Regards,
Erik

Tolbert, John W wrote:
> Preface:  I recently joined the XACML TC, and have been quietly
> attending the teleconferences for a couple of months.  I've reviewed the
> XACML 2.0 and 3.0 core specifications, the supplementary documents, the
> current Wikis, and issues list.  I have a use case for the group to
> consider.  
>
> Use case:  We have applications acting as PEPs that need authorization
> data from the PDP beyond a simple "permit" or "deny".  For example, the
> PEPs may need to know why a deny decision was made.  In certain deny
> decisions, attributes may not be missing, it may be that the request
> doesn't meet certain criteria that the PEP should know about.
> Conversely, applications may need supplemental authorization data for
> permit decisions, sometimes defined as authorization codes.  The PEPs
> need to be able to record the data for auditing purposes.  Furthermore,
> in a federated model, one organization may provide PDP services for
> another organization's PEPs.  In this case, the organization hosting the
> PEPs would need to be able to log extended authorization data for its
> own auditability purposes.
>
> Would it be possible to create the following optional addition to the
> <Result> set:  <AuthorizationCode>?  Other than taking a string value,
> this element could be left intentionally unspecified, so that it could
> be extended and used for lots of other applications.  I considered the
> <Status Message> element, but since it can't be used to return data for
> "OK" status decisions, that wouldn't meet our business need.  I also
> considered the <Obligations> element, but sensed that the purpose of an
> <Obligation> was to perform an action, rather than to simply pass data. 
>
> Thoughts?
>
> Thanks,
> John Tolbert
>
> ---------------------------------------------------------------------
> 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]