Not following protocol specification for multiple macaroons

[gofeuer]

The protocol specification here says that the macaroon portion of the authentication token, left side of : may contain multiple comma separated Macaroons.

Trying to send multiple comma separated macaroons will fail on line 72: https://github.com/lightninglabs/aperture/blob/a30875823faa476a513f89a200899d4959bf2a2f/l402/header.go#L70-L76

I think this might actually be a specification problem and not a bug here. Because what would be the use case for multiple macaroons to be passed to a request? They are all paid for my one invoice?

[guggero]

Thanks for the report!

I think there might be use cases, where you'll want to give out multiple macaroons with different base permissions, but all tied to the same payment hash (invoice). So I think we should update the code to allow for multiple macaroons.

[gofeuer]

Oh right, then minter.MintL402(...) should return a slice of macaroons here:

https://github.com/lightninglabs/aperture/blob/a30875823faa476a513f89a200899d4959bf2a2f/auth/authenticator.go#L94-L96

That would then be encoded with comma separators if the slice has more than one macaroon here:

https://github.com/lightninglabs/aperture/blob/a30875823faa476a513f89a200899d4959bf2a2f/auth/authenticator.go#L110-L111

This will allow a use case where the minter provides a full permission macaroon followed by ever more attenuated versions of it with the properly set caveats. Allowing the client to respond with one of the received macaroons that have the caveats that grant enough access to the resource they require.

I get the client receiving multiple macaroons now. But isn't allowing for them to provide multiple macaroons to authenticate a request an unnecessary complication?

[guggero]

But isn't allowing for them to provide multiple macaroons to authenticate a request an unnecessary complication?

I don't think it's too much of a hassle. We'd just validate more than one macaroon. But they would all need to be valid at the same time.

I don't remember exactly why we wrote the spec that way (it's been a while), but since it's quite explicit I think we might have had a specific use case in mind. So I think a first step would be to just validate multiple macaroons, changing this code as you mentioned initially: https://github.com/lightninglabs/aperture/blob/a30875823faa476a513f89a200899d4959bf2a2f/l402/header.go#L70-L76

Then a second step would be to be able to issue multiple macaroons. Though I don't know how the client would tell the server that it wants multiple macaroons. So some feature shaping would be required here.