Re: [zcap-spec] Request for Clarification (Is it "what" or "why?" and cross-matching)

On Mon, Mar 13, 2023 at 10:33 AM Bob Wyman <bob@wyman.us> wrote:

> Manu,
> I believe I understand capabilities. But, I still don't fully understand
> the argument against using a richer syntax for expressing caveats (such as
> ODRL).
>

There is no need for a standard here.  Caveats and their format can be
considered part of the service's API.  That's a good thing, since every
service is likely to have its own, idiosyncratic caveats as you rightly
pointed out.  Some services may need a means to describe complex caveats,
but many may not.  We don't have to burden providers of simple services in
order to support more complex ones.

My opinion may be colored by experience.  When we did our Zebra Copy work,
which used SAML 1.1 certificates as capabilities, XACML was the expression
language of choice.  We learned that parsing XML is not for the faint of
heart.

--------------
Alan Karp


On Mon, Mar 13, 2023 at 10:33 AM Bob Wyman <bob@wyman.us> wrote:

> Manu,
> I believe I understand capabilities. But, I still don't fully understand
> the argument against using a richer syntax for expressing caveats (such as
> ODRL). It appears to me that the complexity of caveats has no impact on the
> "proper layering of security primitives" since the result of evaluating
> either simple or complex caveats is the same -- the capability either may
> or may not be used, but, if used, the benefits of "proper layering" will be
> enjoyed. (Note: I will ignore, for now, the anti-JSON-LD charge levied
> against ODRL.)
>
> The ZCAP document says that an appropriate caveat for a specific vehicle's
> "Drive" capability, when issued to a parking valet, might be:
>
>> "caveat": [{"type": "DriveNoMoreThan", "kilometers": 123859}],
>
>
> Naturally,  this leads me to think that the following might also be
> useful additional caveats:
>
>> "caveat": [{"type": "DateDriven", "date": "2023-03-13"}],
>> "caveat": [{"type": "DriveNoFasterThan", "kph": "20"}],
>> etc.
>
>
> I believe that you wouldn't object to any of those additional caveats.They
> all reference attributes of the resource identified by the capability. Just
> as "distance driven" can be monitored by the car's control system, so can
> "date driven" or "speed driven." But, there is a problem with using
> enumerated types like "DriveNoMoreThan" and "DriveNoLaterThan" in that such
> application-specific types need to be defined and enumerated before they
> can be used. This means that if some method for constructing logical
> combinations of these caveats isn't specified, I'll sometimes need to
> provide multiple capabilities, each having different caveats, when my
> intent is to only provide what I consider to be just a single permission
> for the use of a single capability.
>
> For instance, being a control-freak, if I'm giving permission to my
> daughter to use my car on a three-day road trip, and if I'm worried that
> she might not take enough breaks on each day of driving, I might want to
> specify a maximum odometer reading for each day of her trip. I'd like to do
> this by ORing together three caveats that each combine "DateDriven" AND
> "DriveNoMoreThan" and ANDing that disjunction with an additional
> "DriveNoFasterThan" caveat. Unless I can logically combine caveats, as I
> could using a syntax like ODRL, I'd need to issue three separate
> capabilities, one for each day. The caveats for each day's capability
> would  be one of several normalizations of the single logical expression
> that describes my intent. This is cumbersome. Of course, one might argue
> that the auto manufacturer should define a "MilesDrivenPerDay" caveat to
> address such needs. But, if they didn't, I would need the
> multiple-capabilities work-around and if I come up with some other novel,
> unanticipated Boolean combination of caveats, the manufacturers may not
> have anticipated it.
>
> In any case, it is likely that there are many interesting "logical
> caveats" that one can construct by combining a small set of basic
> caveats. It would be unfortunate if the ability to do so were withheld,
> but it would certainly be reasonable to constrain caveat expressiveness
> if it impacted security. So, would security be impacted by allowing more
> expressiveness? It seems to me that having the ability to specify
> arbitrarily complex caveats would *not* affect the "proper layering of
> security primitives" since the end result of evaluating either a simple or
> a complex caveat would still be the use of a capability.
>
> What am I missing?
>
> bob wyman
>
>