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

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