W3C home > Mailing lists > Public > public-credentials@w3.org > February 2020

Re: Lightning Service Authentication Tokens (LSATs)

From: Michael Hawkins <michael@runcrypto.com>
Date: Sat, 22 Feb 2020 07:02:43 +0000
To: "public-credentials@w3.org" <public-credentials@w3.org>, "buck.perley@protonmail.com" <buck.perley@protonmail.com>
Cc: "anthonyronning@gmail.com" <anthonyronning@gmail.com>
Message-ID: <UFzsTGkoVZndej6IBFY7LIfS0os25HhEo8E_ckJMRovwrWRJVUHd-varlkg85qhSjhPCveVj5O0_x9QNlHXKthY6cq31xWalUl8g6USKYbk=@runcrypto.com>
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](https://opencreds.org/specs/source/identity-credentials/#introduction) 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](https://github.com/lightningnetwork/lightning-rfc).  When looking into whether there were plans for c-lightning to implement macaroons the only reference I could find was from [cdecker](https://github.com/ElementsProject/lightning/issues/3303#issuecomment-563452486) 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
Michael

‐‐‐‐‐‐‐ 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](https://protonmail.com) Secure Email.
>
>>
Received on Saturday, 22 February 2020 21:18:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 22 February 2020 21:19:07 UTC