4 ms·
> nothing’s stops discharge macaroons from containing embedded third-party caveats ... to consider My understanding is that the receiving app has to contact e
by jiofih 7y ago
> nothing’s stops discharge macaroons from containing embedded third-party caveats ... to consider
My understanding is that the receiving app has to contact each third party to retrieve the “discharge macaroon”. What stops someone from adding a bunch of dummy caveats to cause *N requests on the server?
- arnarbi 7y agoNo, the discharge is indicated to the verifier cryptographically. The user of a 3p-caveated macaroon has to request that discharge from the 3p before sending it to the server.
- jiofih 7y agoI don’t know what else to say - maybe the macaroonjs documentation is wrong? Full quote: > nothing stops discharge macaroons from containing embedded first- or third-party caveats for the verifier to consider during verification. So the user requests discharge tokens on his own, but the discharge tokens have to be verified by _my_ server and might contains nested third-party caveats which I’ll have to verify.
- arnarbi 7y agoIf the discharge has another 3p caveat, then generally you'd have to get that discharged also before sending it to a server. Either way, in each deployment a server supports a set of caveats that makes sense and rejects others. Or that's the intention of the original idea (I'm an author of the paper). I can't speak for macaroonjs specifically.