Support for proven "claims" in Macaroons?

[Jason Axley]

Started playing with macaroons hands-on and it seems that the Caveats are not really usable as claims (as in JWT) to communicate attributes about an entity that carry with them proof of validity.  And it is all highly likely that I've missed something important that allows for these use cases.

Seems like any trusted system that adds caveats can only add caveats:

1. If they are ALL *required* to hold true (adding a Caveat mandates a verifier checks it in order to fully verify the macaroon -- can't only validate a subset)

2. If they can be fully reconstructed via data in a request context (verifier needs to be able to populate the predicates using request data)

3. If you can ensure that every caveat added has a corresponding verifier attestation.

This seems to preclude using macaroons to represent identity information and claims on its own if the information still needs to be provided external to the macaroon in order to verify it.  e.g. many examples show that you have to pass "user = jaxley" or similar to verify the user is who they say they are.  But in many systems, users don't pass a claimed identity in a request.  Identity is obtained from a token itself that is a limited-time representation of a proven identity and indexes to the details of that identity.  I would expect macaroons to be able to be usable as self-contained tokens already containing that identity information though so they could be used without having to inquire of another system.

It also doesn't seem like there are semantics in the APIs for extracting data from the caveats for use cases such as "what is this user's account number?" or "what is this user's internal userid?" so that you can verify a macaroon and then extract verified data that you can trust from them.

LMK where my train of thought derailed or perhaps if these kinds of use cases are not amenable to macaroons or whether there's a different way this should be modeled.

-Jason

[Tony Arcieri]

For claims that provide attested identity information, you can use the Macaroon's identity field, making it structured and including a nonce, user ID, "common name" (i.e. person or service's display name), etc.

If you'd prefer those claims come from a central identity provider rather than the target service, use a discharge Macaroon. Note that the target service will still be the one verifying the information, and that the verification path is symmetric.

If these approaches still don't meet your needs, you have exceeded what is possible with a symmetric credential format like Macaroons.

--

Tony Arcieri