Possible alternative or extension to nip-46

[VnUgE]

I'm an advocate for keys never leaving a "vault" aside from an encrypted backup, my keys never leave my vault server. I personally want to see copy/paste nsec disappear, and I understand nip-07 isn't much of an option for mobile and for non browser clients. Understood, so nip46 was drafted, and makes plenty of sense for client (as in client architecture) oriented cases.

This idea does not stand as a replacement for nip46 as it requires client-server architecture thus eliminating client-arch signing options such is the case for mobile signers.

My thoughts, to avoid communicating via relays, and instead connecting directly to signing servers via HTTP, and authenticated with Oauth2 or similar. Here are some of my thoughts and would appreciate feedback.

Server discovery

1. User enters nip05
2. Client looks up nip05 identity as usual
3. nip05 is revised to include an authoritative signing server address

   Authentication

4. Client prepares an Oauth2 payload and redirects the client to the signing server, or device authorization for non-browser clients.
5. User authenticates with their signing server and grants access to the client with desired scopes (permissions) (eg: encryption/decryption/signing)
6. Server redirects user back to client
7. Client finalizes and requests an authorization code

Operations

1. Client uses authorization code to request note signing, encryption, decryption etc
2. Server performs operation and sends back signed note etc

Possible layers of encryption could be added if needed, but it is assumed you trust your signing server.

Pros:

• Multiple keypairs/identities are not needed
• Access tokens are only useful for authorization and are generally short-lived, they don't leak any permanent information.
• Signer events are now "private" between clients and signers, and can't leak user activity such as note decryption when opening a new client.
• No relay, no relay to trust
• Http attack surface is well understood
• CORS could possibly be used as a security advantage for web clients
• Reduces signing server dev complexity
• Full OAuth2 and identity management infrastructure already exists
• Since clients connect directly, network/http requests can be audited easily
• Reduces client complexity and deprecated encryption spec

Cons:

• Relies on client-server arch and server hosting
• Added RLT for signing, should likely be must less than relays
• Signing servers must be exposed to the web
• Clients must redirect users away from their apps to signing servers, which can feel clunky

A possible continuation I discussed for removing the round-trip, then broadcast, is that signing servers broadcast notes directly to user-configured relays on behalf of the client.

I understand the risk of client-server arch migrating toward centralization, which is why I don't want it to replace relay based options, but for people that have the ability to host signing servers (especially for friends and family) I think something direct and http based should be considered.

[fiatjaf]

This is already possible today, you just need a signing server that exposes a websocket, relay-like interface.

This server could do everything you want, including displaying an auth page for the user and broadcasting events on behalf of users.

The only difference is that it would expose the NIP-46 interface as it is instead of creating a new unsupported standard over HTTP.

[staab]

I would vastly prefer something with a direct-to-signer model rather than a whoever-wants-to-sign-this model, but I do think the indirection of relying on relays is important for allowing people to easily self-host their own signer, and yet another standard to do the same thing unnecessarily increases the burden on client developers.

Full OAuth2 and identity management infrastructure already exists

Could you elaborate on this? What sort of tooling exists that would make this pattern easier? Are we talking software libraries, or end-user tools?

[VnUgE]

Okay, that's fair. I think I was fixated on

1. Eliminate WSS and switch to simple HTTP requests
2. Eliminate the encrypted wrapper request
3. Eliminate extra keypair creation

I can understand it getting ugly for multiple specs to perform a similar task on the client app side of things, but the alternative being client app developers essentially get to work with oauth2 apis which is quite popular.

Could you elaborate on this? What sort of tooling exists that would make this pattern easier? Are we talking software libraries, or end-user tools?

I suppose I quite literally mean following the spec. Grants, flows and so on, following the spec more specifically, but also yes, existing identity management tools including SSO systems, and OAuth2 server libraries.