NIP-47 client-created secret #1818
Conversation
|
Thanks for working on this! One of the things we liked about NWA was the ability for our service to use one single pubkey (instead of one per user) and instead rely on the secret in the connection string to identify and link a user's wallet. It looks like this proposal would require using a unique pubkey per user as the pubkey has become the only identifier of the new connection. Is that correct? |
No, the wallet service can use a single wallet service key for all its connections if it wants. The only change here is that the client's secret is created client-side (and the corresponding pubkey is given to the wallet service) rather than the wallet service generating the client's key and requiring the user to copy the secret from the service into the client. In the Nostr flow, the client subscribes to an info event that has a Note: Using a single wallet service key for all connections is simpler but unfortunately it leaks metadata (anyone who knows the wallet service pubkey can filter events by that key to see all activity through that wallet service). For this reason in Alby Hub we now generate unique wallet service keys per connection. |
Just to be clear - I'm talking about our NWC service (not a "wallet" but a "client" or "service"). How could we identify which wallet is associated with which user if our supplied pubkey isn't unique? When we wanted to onboard a user with NWA, we would generate a unique secret to include in the URI and associate this secret with the user on our backend. When we received the 33194 event sent from the new wallet pubkey it included the secret so we could identify which of our users created this connection. The wallet service was still creating a unique pubkey per connection but nostr.wine was not.
Not if your service uses a properly authenticated relay with access control. inbox.nostr.wine supports this by default. Events can be written by anyone tagging our NWC service pubkey but only our key can request and read those events. This setup becomes untenable if we need to manage authentications and queries for one pubkey per user. |
|
Another subtle but important difference from NWA: When we (a client or other non-wallet service) pass a relay parameter in the URI, is the wallet service expected to listen on this relay for requests in perpetuity? With NWA the 33194 event broadcasted to the relay included in the client generated URI included an optional relay field for the wallet service to effectively override which relay would be used to listen for requests. Our service would then connect to the designated wallet relay to verify the presence of a 13194 info event for the corresponding wallet pubkey. Are your wallet services prepared to connect to any number of 3rd party relays? Do they support NIP-42 AUTH? |
Now nostr.wine as the "client" must generate the unique key instead of the wallet service. You just need to associate the key you generate with a particular user. (And only the corresponding public key of this unique key is given to the wallet service. You as the client will keep the secret and use it for NWC communication). Does that make sense?
This is still possible in this proposal. The wallet service can provide its own preferred relay in the Unfortunately from Alby Hub's side, we currently only support 1 relay at a time, which the user can configure via an environment variable. We do not support NIP-42 AUTH. |
Yes, I understand your proposal but this doesn't support one of the main NWA features we used which was the ability to use a single pubkey on the client side.
Will the wallet service always send the 13194 to the relay in the client provided URI? If not, how would the client know where to look to find the 13194? How does that work with a 1 relay at a time restriction? I don't think you should force the wallet service to obey the client relay request but you must send the 13194 to the relay in the URI otherwise the client does not know which relay to use. |
Ah, I see. But I don't think this works because the wallet service uses the pubkey of standard NIP-47 requests to know which app connection it is. Did you try creating two connections with the same pubkey for the same wallet service?
For Alby Hub because it's self hosted and not publicly accessible, we use Alby Go as the user-facing NWA interface which communicates with Alby Hub over nostr to initiate the connection. Therefore, I think Alby Go can listen to the hub's info event and then re-broadcast it to the client-provided relay without Alby Hub having to be connected to it. (Note: we haven't done this yet) |
I'm confused trying to understand what you mean by this. The wallet service knows who we are talking to because we are p-tagging the unique wallet connection pubkey (the one that sent the 13194 info event) with the request. NWA worked perfectly with the setup I'm describing. All we need to do is add an optional secret to the client generated URI and then have the 13194 event include that secret if it was passed. This would allow us to have a similar flow to NWA without the extra event.
If your wallet service can't drop off the 13194 on the relay included in the client provided URI, then this proposal doesn't work at all currently. @asoltys does coinos support this correctly? I think there is some disconnect because everyone always thinks of NWC as nostr clients on one side and wallet services on the other. There is a third participant and that is subscription services like nostr.wine. We have different requirements and goals. We aren't trying to manage a user's wallet, we are just trying to send them payment invoices when they are due. Reducing friction for services like us to implement NWC is important if we ever want it to be used beyond zaps. |
I don't think this is a third participant, nostr.wine is just another client. A client is any type of app or service that wants some access to the user's wallet, even if it's receive-only access. A NWC client is not necessarily a typical nostr client. It can be anything - a PoS machine, a recurring payment service, a wallet interface, a game, ... |
|
Have you read through the old NWA PR and the comments? I would highly recommend you do so because it would help us get on the same page. There is actually a LOT of confusion about what a "client" is in that thread. I feel like Ben did a really good job of explaining why all the fields were necessary and the objectives of it. We also talked about "client" key management and why some services may not want to create one pubkey per connection. We likely won't implement a NWC solution that requires us to store one private key per connection. It's not worth the added complexity on the relay REQ side alone. There are also security gains from not having to store and access potentially thousands of private keys (also mentioned in the NWA discussion). |
We don't allow the client to provide a relay. As the wallet provider we always use our own relay and inform the client of it in a postmessage that gets sent back when the user authorizes the connection. I agree using an AUTH'd relay would be a good idea to not leak events/metadata for the connection. Our relay is public at this time. I'm not very familiar with relay authentication in general yet so open to suggestions on how we could improve there. I'm running strfry with near stock configuration for relay.coinos.io |
There was a problem hiding this comment.
Looks good! It's just unfortunate that as-is, a 1-click flow from desktop web to a mobile NWC wallet without a server (like cashu.me) doesn't seem to be possible but I don't know how you want to contact the mobile NWC wallet without communicating some relay to it beforehand.
| - `budget_renewal` Optional. The reset the budget at the end of the given budget renewal. Can be `never` (default), `daily`, `weekly`, `monthly`, `yearly` | ||
| - `request_methods` Optional. The url encoded, space separated list of request types that you need permission for. For example: `..&request_methods=pay_invoice%20get_balance` | ||
| - `notification_types` Optional. The url encoded, space separated list of notification types that you need permission for. For example: `..¬ification_types=payment_received%20payment_sent` | ||
| - `isolated` Optional. The makes an isolated app connection / sub-wallet with its own balance and only access to its own transaction list. e.g. `&isolated=true`. |
There was a problem hiding this comment.
I am not sure what this means. Did I miss some development regarding NWC? The description sounds like how I would expect a NWC connection to behave isn't the default so I am not sure what the default without isolated then is.
As-is, as an app developer, I wouldn't know if I should add &isolated=true or not.
There was a problem hiding this comment.
Currently this is only implemented in Alby Hub, but I think it's a powerful feature which is why I'm proposing it as an optional parameter.
There are different usecases for isolated and non-isolated connections.
If you need access to all wallet activity or want a standard budgeted connection without having to top it up, you do not want an isolated connection.
If you wanted to create a PoS for a specific product/event/business, or sub-wallet for a friend/family member, you probably want an isolated connection, so that they can only see their own sent/received payments. Isolated connections (sub-wallets) start with 0 balance and must be topped up before they are spendable.
There was a problem hiding this comment.
Isolated connections (sub-wallets) start with 0 balance and must be topped up before they are spendable.
So if isolated is set, budget_renewal and max_amount don't make sense, right?
I think that's okay if that's the case, but I think we need to explain isolated more in this spec else it's confusing.
Just from reading the current text, I would erroneously think I want to use isolated.
I don't have suggestions to improve right now though. I mean, I get it now, but I am not sure about the next guy haha
There was a problem hiding this comment.
@ekzyis in most cases budget_renewal and max_amount don't make sense for isolated connections, but there are still use cases though: e.g. a sub-wallet you give to your kids but only allow them to spend some of their money each month to incentivize saving part of their pocket money (just as a concrete example).
|
|
||
| The **user** opens the URL in the **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI, and MUST be presented with a confirmation page. | ||
|
|
||
| If the **user** approves the request, a new connection should be created for the **client**'s public key (specified in the base path of the authorization URI). Once the connection is created, the NIP-47 info event MUST be broadcasted to the relays specified in the authorization URI, and the info event MUST include a `p` tag containing the public key of the **client** this info is for, so that the **client** can discover the public key of the **wallet service**. The `p` tag MAY contain the recommended relay url of the **wallet service**. |
There was a problem hiding this comment.
Should the client use this recommended relay? If so, I think it should be mentioned here like this:
The client SHOULD use this recommended relay url to continue communication with the wallet
but on the other hand, since it's not required, not sure what the relevant difference is between using the relay picked by the client vs the one picked by the wallet.
There was a problem hiding this comment.
Yes, based on the comments so far by @asoltys and @nostr-wine and also Alby Hub's requirements, I think the client MUST use the relay provided here, if provided. If you guys are ok with this I will update it.
There was a problem hiding this comment.
I don't mind. I think users might even trust their own wallet to choose the relay more than a client.
There was a problem hiding this comment.
I agree.
Separately, the wallet MUST use the relay provided by the client for the initial 13194 event if the client initiated 1-click-flow (via nostr, not http) is used as already mentioned in your PR. After that, the client MUST use the wallet provided in the 13194.
@ekzyis in this current proposal the flow is that a QR code would be shown on the desktop web that the user would have to scan using cashu.me, and then cashu.me would include its preferred relay in the broadcasted info event to the client's relay. I believe this is completely possible, where do you see the issue? |
We also do not run an AUTH'd relay. I think if AUTH is added it's important to not require that wallet connections be tied to user identity (I guess it can be done by using the standard NIP-47 client and wallet service keys to sign these messages, but isn't in then kind of redundant to force them to sign additional messages?). Our current solution is to use unique keys both for the client and wallet service per connection, and some minor constraints on our relay to ensure events cannot be queried without providing a filter with one of these keys (either querying by author, or a specific |
Yes, I read the comments. I understand right now you can subscribe to a single pubkey and listen to events from all different wallet service keys. This is indeed simpler for your usecase. We run multiple services which subscribe to many keys on relays so have experience with what you mention above. One of our demo apps which does scheduled subscription payments I believe is very similar to the model nostr.wine could use to charge users for relay usage on a monthly basis: https://zapplanner.albylabs.com/ However, I would like to explain the other side of what your suggested change would mean:
@nostr-wine please let me know if I miss something here. |
One of the comments is about why a secret (outside of client generated pubkey) is necessary for the client initiated nostr flow regardless of whether or not the client uses a unique key per connection. Since the wallet service never shares their pubkey with the client app out of band, what happens if multiple 13194 events are posted within a few ms tagging the same client pubkey? Should the client app always assume the first received event is the legitimate one? What if they have the same timestamp? An attacker could monitor for these events (on your unauthenticated NWC relays) and immediately create duplicate 13194s. There is no way for the client app to know with certainty which event is from the wallet service without a shared secret. The p tag is public. Pubkeys are NOT secret and we should not call them secrets.
Not right now - this only worked with the original NWA proposal and Mutiny. Without a functional nostr 1 click flow we are not using NWC at all currently.
This is a lot easier to do on unprotected relays. We would like NWC to work on authenticated relays too. There are already several functional relays that provide this service for nostr DMs (you can learn more about the architecture here: https://docs.nostr.wine/inbox/readme - we even had added 33194 events for NWA). If the service needs to authenticate for every single pubkey it is monitoring and then open individual REQs for each it would be impractical with just a few thousand wallet connections.
Actually it does not need to be unique per connection, just per wallet user. We would never (as a service) want to create more than one active connection at a time with the same wallet user anyway. With that being said, we can't imagine any wallet service would actually want to reuse keys. The privacy issues are a lot more relevant on the wallet side. You wouldn't want a random outside observer to be able to track a single user's wallet interactions. On the flip side, I don't see any issue If everyone can see that nostr.wine is sending NWC events to a bunch of random pubkeys. |
Oh, you are right, I didn't consider the QR code. I guess it can count as a 1-click flow. I was thinking of "1-click" more in terms of "the client opens the wallet" (no context switch), but with the QR code flow, the user has to manually open their wallet. But it's okay, just wanted to mention and as mentioned, I wouldn't know how to improve this anyway. |
I think it makes more sense that we add some basic recommendations for relay protection for wallet service relay runners to prevent against allowing all their notes to be crawled (e.g. how Alby's relay does it). If you wish to use a random public relay sure you are at a very small risk of this attack, but there's almost no incentive to do this attack... |
@ekzyis you could have a native lightning wallet app on your desktop which registers the EDIT: it can also technically be done with browser extensions (maybe the Alby Extension will be able to handle these links at sometime in the future) |
We think this is much more complicated, open ended, and unlikely to be properly enforced. Not all relay implementations support these type of restrictions. Including a secret is simple and only relevant for those updating their implementations to support this new "1-click" flow. We need to move on to other things so we'll step aside from here. If others are happy with it as is don't let our opinions get in the way! |
|
|
||
| - `pubkey` Required. The corresponding pubkey of the secret generated by the **client**. | ||
|
|
||
| The **wallet service** MAY ignore all the below optional parameters. |
There was a problem hiding this comment.
I think it'd be good to reference an optional NIP-68 client ID here for some basic phishing protection.
There was a problem hiding this comment.
In the long term I think it's a good idea but I am unsure if it will be adopted in the short-mid term due to much more additional work on all sides (wallet service having to fetch the event and calculate WoT, client must handle a redirect uri, developer required to publish this event).
Should it be a NIP-19 nevent so that it also contains the relay? Do you have suggestions on the field name?
|
|
||
| The client MAY generate its own secret and co-ordinate only public keys with the wallet service so that secrets are never exposed. | ||
|
|
||
| ### HTTP Confirmation Page |
There was a problem hiding this comment.
I'm really glad we're talking about standardizing this HTTP-based flow. The experience you guys have had with alby for a while is a much better UX than the copy-paste flow IMO and works especially nicely for custodial wallets.
My main worry here is that from a security standpoint, this gets very close to OAuth, but without the guarantees that OAuth has around phishing prevention, csrf, token rotation, etc. OAuth is really battle-tested and while it can be painful, trying to re-implement OAuth is a very common security foot-gun. When building out UMA Auth we spent quite a while in security review with 3P security experts and they insisted on simply using OAuth for the connection handshake when there's a wallet available over HTTP.
I do quite like that this method never has the secret leave the client application. I'd initially tried to hold that property with UMA Auth as well, but it was much trickier to get key rotation correct that way. I still think it might be doable, but doing without user interaction is awkward. Eventually I resigned myself to the idea of the wallet being the source of truth on key state, etc.
For reference:
There was a problem hiding this comment.
These are all valid points.
I think the simplicity of NWC is a big reason it has gained adoption and we should not take this lightly. I think the implications of OAuth also push hosted wallets further from self-hosted ones, which currently in this proposal I have tried to keep as aligned as possible.
@asoltys I would be interested to hear your perspective.
| - `isolated` Optional. The makes an isolated app connection / sub-wallet with its own balance and only access to its own transaction list. e.g. `&isolated=true`. | ||
| - `metadata` Optional. Url encoded, JSON-serialized metadata that describes the app connection. | ||
|
|
||
| The **user** MUST be presented with a confirmation page to be able to review and approve or decline the connection. |
There was a problem hiding this comment.
Any thoughts on how this happens? For UMA auth, we use the user's UMA (or lightning address) fetch a configuration document similar to the OIDC discovery doc. From there, we just read the authorization_endpoint field to decide what url to open. It's really similar to how oauth works in this regard and allows the user to just type a lightning address to open the right endpoint (or detect that this method won't work).
See https://docs.uma.me/uma-auth/uma-auth-client/client-manual-implementation#oauth-20-exchange
There was a problem hiding this comment.
Our current solution is to have a list of wallets to pick from (e.g. Bitcoin Connect has a list of wallets it supports and knows what flows to use, and in the http case what url to use).
I think there are pros and cons of both approaches though.
This PR introduces two "1-click" connection flows for setting up initial NWC connections. Rather than having to copy-paste a connection string, the user is presented with an authorization page which they can approve or decline. The secret is generated locally and never leaves the client.
Both flows are also implemented in Alby JS SDK and Bitcoin Connect.
This can be tested in some apps: