Re: Lightning Service Authentication Tokens (LSATs)

Hi Michael,

Thanks for taking a look and for your comments! Glad to hear that some of this work has helped to re-pique your interest. 

I haven't spent much time working on DIDs for lightning so can't comment too much there, although my instinct would be to agree with your evaluation that perhaps L2 isn't as well suited to it. 

As for the first point with regards to the lightning protocol not including macaroons, I think it's worth clarifying ahead of the call (though I will go into more detail w/ slides) that the use of macaroons in LND is completely separate from the idea of LSATs and the way they use macaroons. LND's use of macaroons is not a protocol level concern as far as I'm aware and so there would be no need to have a BOLT or protocol-level spec for it. LND simply chooses to use macaroons as the authentication system for accessing its node and RPC. This gives an admin of an LND node a lot more flexibility in how to manage, distribute, and attenuate access to its node, but lack of support in c-lightning or eclair has no bearing on compatibility or even (more importantly) to whether another lightning implementation could use the LSAT proposal.

The use of LSATs simply requires an implementation to be compatible with the normal RPC commands. The macaroons are composed, verified, and attenuated completely external to the lightning node. The only thing in the proposals so far that will require an official update to the spec and support across implementations is the experimental "oauth" construction proposed in the GitHub issue linked to previously [1] which requires keysend support as a way to non-interactively send an "ephemeral key" for verification of 3rd party caveats. That said, the fall back version of this proposal (which I'll talk about tomorrow) doesn't even require this and only needs a node and its rpc server to support signmessage and verifymessage.   

Hopefully this helps clarify any points of confusion and maybe even gets you more interested in the possibilities of LSATs!

[1] https://github.com/lightningnetwork/lnd/issues/288#issuecomment-559896636

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, February 22, 2020 2:09 AM, Michael Hawkins <michael@runcrypto.com> wrote:

> Hi Buck,
> 

> I've had a quick scan through the links and am impressed with what you've produced, it's helped me understand macaroons and LSAT much more.  I had some reservations about LSAT but as I've been looking into this some more I can definitely see the potential.
> 

> I found reference to using macaroons in a identity credentials report from December which is "very high-level, incomplete, and rough" so focusing discussions on this area could help to identify where LSATs fit and some of the work mentioned below could really help flesh out details in this section.
> 

> A couple of points I would put here for consideration would be;
> 

> -   One of my concerns with macaroons (for payments on lightning) had been that they are specific to the lnd implementation and not a part of the lightning protocol.  When looking into whether there were plans for c-lightning to implement macaroons the only reference I could find was from cdecker suggesting that authorization would be better suited in a proxy in-front of the lightning client, which makes sense to me as a separation of concerns.  If looked at it from that perspective then a proxy infront of a lightning client could implement a macroon, VC, LDAP, Kerberos or any other authorization layer which could e a nice little project to work on :)
> 

> -   I explored the possibility of lightning based DIDs which might be what Anthony was referring to.  I concluded (at the time) that the DIDs didn't really fit on layer 2 and are better suited to being on Layer 1 and so left the idea there ( a lot of effort has already gone into BTCR).  One of my problems with the LN DID method was leaking privacy by rooting identity to a lightning node where BTCR uses a transaction which is much easier to obfuscate.
> 

> thanks
> 

> 

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, February 20, 2020 11:44 PM, Anthony Ronning <anthonyronning@gmail.com> wrote:
> 

> > Hey Buck,
> > 

> > +1 on this, really excited to see you share it here. The sort of “pay-per-permission” model this enables is really interesting to me. For another example of LSAT in the wild, my implementation here: https://www.satreon.net
> > 

> > Would love to see and help contribute to any w3c standardization efforts / documentations related to it. As 402 hasn’t been implemented much to date, there’s a real opportunity for it here.
> > 

> > Further, I am curious how those in the Verifiable Credentials scene think of macaroons and how LSAT fits into it. I can see how a mapping over to VC’s could work and be verified by more than just the macaroon signer - that’s one of the shortcomings I see with macaroons, without diving into 3rd party caveats which is something I do need to look into more. I have seen a lightning based DID method at a hackathon before which could help here but even then, any DID / signing method could work as long as they are signing the preimage hash.
> > 

> > Looking forward to next Tuesday!
> > 

> > Anthony Ronning
> > 

> > On 20 Feb 2020, at 14:28, Buck O Perley wrote:
> > 

> > > Hello CCG Mailing List,
> > > 

> > > As a quick introduction, I was introduced to the list via Christopher Allen who I've been chatting with recently regarding work around authentication with Lightning (Bitcoin's Layer 2 payment network) payments, macaroons, and the 402 HTTP status code. Specifically, with the support of Tierion, I've been implementing a JS version of the Lightning Service Authentication Token (LSAT) proposal shared by Lightning Labs last Fall. Christopher thought this would be of interest to the work you all are doing and invited me to share some of this work in a call next week. 
> > > 

> > > To provide some context before then, here are some relevant links:
> > > 

> > > Blog Post: https://medium.com/tierion/lsats-pseudonymous-authentication-using-bitcoin-lightning-payments-459e209b4b36
> > > 

> > > Slides: These will be updated before next week's call, including with some more information on some of the mechanics of how Lightning payments work for those that aren't familiar, but it should be enough to help get started! https://docs.google.com/presentation/d/1YE5UJk05Q9I2k7hhlM6oSVARGIajPF5u50r1LNCe-x4/edit?usp=sharing
> > > 

> > > Boltwall: (Nodejs server middleware for using LSAT auth) https://github.com/Tierion/boltwall
> > > 

> > > LSAT-JS: JavaScript implementation of the LSAT proposal from lightning labs. Includes helper functions and utilities for interacting with LSATs https://github.com/Tierion/lsat-js
> > > 

> > > LSAT Playground: UI Playground for interacting with, testing, parsing, and creating LSATs: https://lsat-playground.bucko.now.sh/
> > > 

> > > - Buck
> > > 

> > > Sent with ProtonMail Secure Email.
> > 

> > >