Hi Bill,
And thanks for the enlightening discussion. :-)
You express yourself well and I do agree with you that there is a
difference between "Why" and "Do", but I still think that it will be
difficult to separate the two from each other in real world use cases,
where the two tend to get mixed together. Where do you put something
which is both? But maybe that is not such a big problem?
And, yes I agree with you that use of extension points should be
discouraged, but that is really a separate issue from what I have been
arguing for. I am really saying just one thing: I don't think it is a
good idea to have two different features which are "mechanically"
identical. (Or, at least until you convince me otherwise. ;-)) It's
another issue that even having one such feature might be bad from an
interoperability point of view.
If we focus back on the original issues for the 3.0 core we are working on:
1. Do we want to define a special mechanism for "Why" (and/or "What")?
2. If so, what is the concrete proposal for that?
3. Would it be mechanically different from obligations in any way?
(And would it be a problem if it's identical. Well, I know you position
on this Bill.;-))
Best regards,
Erik
Bill Parducci wrote:
>>> Since neither is required to be supported it is a decision of the
>>> implementer as to what overhead is appropriate.
>> Yes, but if there is only one mechanism, then it's less work to
>> implement both uses.
>
> This assumes that one wishes to implement both sets of functionality.
> You can argue that you get both for "free" but that feeds into my
> position that what you really get is an implementation black hole.
> Having this in place as proposed implies that any supporting either
> use supports both (whatever that is).
>
>> What I mean is that if we end up with two mechanisms with the same
>> functionality, where the only difference is the "philosophical"
>> interpretation of the terminology, then it will be difficult to
>> explain to users what belongs in which category. For instance, are
>> the classifications of these clear?
>
>> 1. "For your information, access was allowed because of Freedom of
>> Information Policy".
>>
>> 2. "For your information, access was allowed because of Freedom of
>> Information Policy, and also make sure you note this in the logs".
>>
>> 3. "For your information, access was allowed because of Freedom of
>> Information Policy, and it may mean that you have to do something
>> special because of this".
>>
>> 4. "For your information, access was allowed because of Freedom of
>> Information Policy". And the recipient does something special,
>> without telling anyone about it, even though the policy writer did
>> not ask for it when he communicated the meaning of the identifier.
>>
>> Which of these are information, which are obligations. Could they be
>> both? If we have two mechanisms, I can see users arguing about it on
>> the users list taking different standpoints. :-) And in general, why
>> would someone provide "information" if he did not expect the other
>> party to act on it in some way. So in some sense all information can
>> be seen as "commands" to the recipient.
>
> So what you are saying is that as a TC we cannot sufficiently describe
> a mechanism or mechanisms to differentiate this but it is soluble by
> providing implementers with a magic box that can contain
> anything--actionable or not--and this is OK? We cannot enforce
> specific usage of the framework, however I think we should avoid
> design that exacerbates non-portable information. I am not concerned
> if the payload is "clear" I am arguing that the context must be where
> possible. The Use Cases I heard seemed quite explicit, common and
> begged for some sort of causality attribute to be returned. This is
> not ambiguous or superfluous in my opinion and I can see many people
> using it and choosing to implement Obligations.
>
>> Yet another aspect is that the architecture of a PDP/PEP implies a
>> trust model where the PDP does not control the resource. This means
>> that in some sense the PDP is ultimately just providing enforcement
>> advice to the PEP, which means that a rock solid genuine obligation
>> in a sense is just advice/information to the PEP since if the PEP
>> does not follow through, the PDP might not be able to do anything
>> about it.
>
> Not entirely true. The intent of an Obligation is that while it's
> ramifications exist outside of the decision/enforcement context that
> should the PEP not be able to fulfill it a systematic error condition
> would be generated. Of course how this works is implementational but
> that doesn't discount the concept that a Policy Writer would
> reasonably expect that an Obligation is carried out and if not there
> are subsequent actions. This is not necessarily the case with
> causality as it is a logical attribute of the decision, not a
> component of it:
>
> Obligation: "PERMIT + DO"
> Cause: "DENY + WHY"
>
>> Anyway, maybe it's just me, but I have a hard time seeing a clear
>> difference between information and obligations.
>>
>> Portability will "not be an issue" as long as users understand the
>> meaning of each individual obligation identifier. (I'm ignoring the
>> complication that each obligation id requires dedicated code, but I
>> don't think that is relevant because if the TC would define the
>> obligation identifier, then it would be portable, and if the TC
>> doesn't, then it's a extension point, and cannot be expected to be
>> portable. And for now I'm not going to open up the discussion if
>> there are any particular obligation ids that the TC should define. ;-))
>
> By channeling increased functionality that is not portable we are
> encouraging the wrong behavior IMO. I make this same argument every
> time we want to add an extension point for the same reasons. Sometimes
> you must bite the bullet and do such things, but because there is
> overlap in mechanics doesn't seem like one of those times.
>
>> What I am saying is that it could be difficult to define in a clear
>> cut way for each individual obligation identifier whether it belongs
>> in the "information" or "obligation" category.
>
> What I am saying is that I don't consider Cause a subset of
> Obligation. It simply isn't. The mechanisms can be identical (in which
> case I would argue that implementation overhead would be quite light),
> but they are fundamentally different.
>
>> But in any case, I can think of a valid reason for a separate
>> "information" mechanism. Currently the PEP must not ignore
>> obligations, and must fail if it sees an obligation id which it
>> doesn't recognize. If it knew that an obligation is information only,
>> then it could safely ignore the "information". If this were the case,
>> then it would really be two different mechanisms with distinct
>> behaviours, beyond the mere "internal interpretation" of the
>> obligation identifier. (The same effect could of course be achieved
>> with a 'MayBeIgnored="true"' in the obligation.)
>
> [side note] a PEP that *accepts* Obligations must behave thus. I could
> be wrong but I seem to recall that a PEP that chooses not to support
> Obligations may ignore them and proceed (one of the places where I
> believe PDP meta data could come in handy ;).
>
> I understand that you can look at this mechanically and say, "If i
> just put all the stuff there isn't an explicit mechanism to handle
> into this field then I can 'extend' the Policy to do whatever I need."
> What I am saying is that I think it is a Bad Idea to encourage it.
>
>> What I am opposed to are two mechanisms with the exact same effect in
>> all respects, except that they are supposed to be used for two
>> different categories of interpretation of the identifier. There must
>> be some explicit difference between them.
>
> I think there clearly are, just maybe not mechanical :)
>
>> No, I am not taking the position that naming does not matter. What I
>> am saying is that in this case the error is not so big, so I can live
>> with it. And changing it might be worse.
>
> Sorry, but "junk drawers" bubble up to the top of my pet peeve list,
> so I have a hard time "living with it" ;)
>
> b
>
> ---------------------------------------------------------------------
> 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