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

Alan wrote:

> There is no need for a standard here.  Caveats and their format can be
> considered part of the service's API.

Yes. That is what I suspected. If a standard can't, or won't, cover the
breadth of relevant requirements, it is often best for it to remain silent,
or to simply provide non-normative guidance concerning best practices for
different classes of application.

bob wyman


On Mon, Mar 13, 2023 at 4:42 PM Alan Karp <alanhkarp@gmail.com> wrote:

> 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
>>
>>