Seemingly contradictory readme

[benjumanji]

Sorry if this is a really silly issue but the following two seemingly paradoxical paragraphs are killing me.

Both:

More importantly, the verifier will also work for macaroons we've not yet seen,
like one that only permits Alice to deposit into her account:

>>> N = M.add_first_party_caveat('action = deposit')
>>> V.verify(N, secret)
True

and

Equally important is the verifier's ability to reject improper macaroons because
they are not authorized. An improper macaroon could have additional caveats not
known to the verifier, or have false general caveats. Worse, an unauthorized
macaroon could be an attempt by a determined attacker to break into our bank.
The verifier we've built will reject all of these scenarios:

>>> # Unknown caveat
>>> N = M.add_first_party_caveat('OS = Windows XP')
>>> V.verify(N, secret)
Traceback (most recent call last):
Unauthorized: macaroon not authorized

(emphasis mine)

cannot be true. It cannot be true that we can add a caveat that the verifier doesn't know about, and have it both succeed and fail, and indeed if you add a caveat like action = deposit to the macaroon and try to use the verifier without updating it, verfication fails.

What am I missing?

[arnar]

Disclaimer: I didn't write those docs.

The server doesn't have to have seen that precise macaroon, but it has to know how to interpret all first party caveats. You can change your emphasized part to "caveats that the verifier does not understand or know how to enforce", if that makes more sense.

[benjumanji]

Thanks for the clarification!