Re: [xacml-users] Chronicle Attribute

[David Chadwick <d.w.chadwick@kent.ac.uk>]

 > Seth Proctor wrote:

Hi Seth

I tend to agree with you, and I think that the obligations proper, using 
ASN.1 jargon, should be of type ANY DEFINED BY OID (or URI), and the 
OID/URI defines what goes in the obligation syntax. Then all of the 
discussions are outside the core XACML work. All the PEP needs to know 
in this case is which OID/URIs it supports, and that this OID/URI needs 
to be passed to this module X for processing at some point in time. So 
currently one can argue that your definition of Obligation as an 
attribute assignment is too restrictive! But at least you do have the 
obligation ID which is good, since this serves a similar purpose to the 
any defined by OID. So I agree with you that very little about 
obligations should be specified in the core XACML standard. This can be 
done in an Obligations Service standard.

> 
> Hi David.
> 
>> Your suggestion is precisely what we do NOT want to do. The PEP should 
>> not need to look inside the obligation attribute assignements. The 
>> obligation ID should tell it which service to call, and the Chronicle 
>> tells it when to call it.
> 
> I understand that you are trying to avoid this, but this is how 
> Obligations are defined. They are obligations to the PEP, not to 
> anything else. Of course, if the PEP wants to delegate responsibility to 
> other entities that's perfectly valid, but from the XACML model point of 
> view, this is the defined relationship.
> 
> My concern here is that everyone seems to want to do something different 
> with Obligations, and sees their definition as subtly different.


In which case they define their own URI, and obligation syntax, and 
build an obligations service which can handle it


  The
> more we define in the core standard, the less useful I fear Obligations 
> will become. 

I agree

As it is, there is confusion about when and where to handle
> Obligations, and what it means to "discharge" them. If I have to include 
> a "when" tag on Obligations that are handled directly by the PEP, what 
> does this mean? 

the semantics of "when" should spell this out.

For your specific application the meaning may seem
> clear, but for a lot of systems I've worked on, I can think of many ways 
> to interpret the meaning.
> 
> Personally, I would far rather see Obligations remain opaque in the 
> core,

agree

  and have a group start work on a best practices styled document;
> something that captures the way people use Obligations, and defines some 
> standard structures and identifiers to build around. I believe this 
> would be of great general utility.
> 
> One reason for such a document is that it would give us a place to 
> collect all of these features requests. There are many things people 
> would like added to this feature, but it's hard to say how we're 
> deciding what actually goes into the core. For instance, everyone (no, 
> I'm not exaggerating) who first looks at Obligations thinks that you can 
> include an AttributeDesignator which is evaluated at the PDP before 
> Obligation are returned to the PEP. This comes from an example in the 
> XACML specification that implies this behavior, even though this isn't 
> part of the specification. Arguably, this feature would be very useful, 
> and is in high demand. We could add it by including a tag on 
> AttributeAssignment (e.g.) that says "evaluate this at the PDP and 
> include the result as an attribute of type foo." Should we add this 
> overhead to the PDP? I don't know.

We had a very similar requirement in our work, but our evaluation is 
done by an external obligations module called by the PEP, and it is not 
done by the PDP.


> 
> All this said, there is clear interest from others on the TC in having 
> some "when" facility, so I suspect that something will be added in 3.0. :)
> 

I see a fundamental difference between a WHEN attribute and an 
assignment. WHEN is only saying when to do something and is not actually 
asking for anything to be done itself.

regards

David


> 
> seth
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************