Capturing Data Access Events Post Consent Using Macaroons

Consent management is a long and sprawling topic.  The likes of the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) have certainly sprung the terminology and design questions onto a bigger stage - but how many projects are really satisfying some of the nuanced use cases?

A use case I came across recently, really amplified the lack of capabilities many projects face.  Capturing consent is the main use case many focus upon.  It's a good one, pretty critical actually, and often gets looked at, through a few different lenses.  The first one is consent capture during account on-boarding or registration.  The classic "do you consent to service-x, using data a, b and c for the purpose of y"? The second part is often the huge long page of terms and conditions relating to the service use.

There's an entirely different (and equally huge) set of use cases around how that consent object is stored (schema, consent receipt format etc) and ultimately revoked.  I might touch on that in later blogs, but what happens, immediately after consent is granted?

The user gains access to the product/service/widget they so desire and the service provider has the big tick box next to the user profile, to process their data as agreed. What happens next?

Think of this use case - end user has registered for a credit card, provided the necessary personal data, signed terms and consented to the necessary data usage requests. How is that actually implemented within the service provider? Does the end user need to know how their data is being used? Does the end user get an opportunity to monitor and revoke subsequent data requests? Are those requests actually captured anywhere and can they be correlated to a specific data access event, logged and audited effectively and more importantly, can they be revoked?

I want to discuss that post consent data access request flow in this blog.

So what's happening here?

1. End user consents for enterprise to be data processor or equivalent (with 1a subsequent internal identity and access management flows to provision necessary permissions to users/services)
2. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
3. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
4. Individual employees during role fulfilment request access to PII (atomic and separate transaction)
5. End user notified retrospectively of access via weekly digest, per event or via end user request
6. User decides whether access was necessary
7. If end user decides it wasn’t, workflow triggered to remove access / trigger investigation via 8

The interesting bit...how do you capture the access request event along with the reason for access?

At this point, I want to introduce the concept of macaroons. The linked article is a good primer on the technical features of what a macaroon is. The TLDR - the AM 7 build now has added the ability to make an OAuth2 access token format be wrapped in a macaroon.

Why do that? Well this gives the ability to perform more fine grained "caveating" of the issued tokens, to allow resource servers to make more informed decisions when it comes to access control, and to potentially do this, in a more distributed fashion.

Coming back to our use case above. Internal enterprise access control in this example, is based on API's providing staff, partners and services with access to the PII (personal identifiable information).

So typically a set of scopes, managed via OAuth2, that a resource server would use to enforce access. The tokens would be issued on the back of an authentication event and scopes granted to an issued token, based on a governance process - a simple example could be the mapping of scopes based on provisioned attributes or groups in a directory.

The service or person accessing an API that contains PII (definitely need more acronyms using only the letters A, I and P..), has an OAuth2 access token with for example the READ_PII scope. Awesome, the resource server validates the token, checks signatures, nbf and exp and all that good stuff, and checks the necessary scopes.

A standard OAuth2 access_token with the READ_PII scope:

This is where the macaroon aspect comes into play. Before access is granted, the resource server is also going to look for a certain caveat. A self issued value baked into the access token, that contains the reason why access is needed.

So how do we add that?  The issued token above ^^, is actually a macaroon formatted stateful access token (it could equally be a macaroon formatted client side JWT token...). The calling client, can now add some extra meta into the token before sending downstream to the resource server. For ease of the example, the client can use helper endpoints in AM todo this, or use client side macaroon libraries.

Adding a first party caveat to an access_token, explaining the reason for access:

The resulting token, as viewed by a standard ../introspect call, now looks like the following:

Now, when the resource server is going through its token validation steps, it will be looking for the reason-for-access entry for and governance.

The reason would be unique per access request as dictated by the resource server policy, which could log the necessary reasons. If necessary, the end user would be notified as part of a digest event (perhaps weekly or on request) of all the times data was accessed within the agreed consent framework.

A revocation event would trigger the investigation of the processed scope to service/person access token issuance as well as validation of the reason.

A simple of example of moving a coarse grained access token, to be a fine grained access token using macaroons.