Oddbean new post about | logout
▲ ▼
PABLOF7z | 10 months ago (raw) | root | parent | reply | flag 
 No, as those are trivially forgeable so I think it’s better to not even try to show them and just rely on the URL if there is one. Perhaps we could use the domain of the URL and use a NIP-05 _@domain to resolve to a pubkey if the flow is web-triggered.

There’s a callbackUrl that I forgot to document on the spec; I’ll write it up before I send the NIP PR
▲ ▼
brugeman | 10 months ago (raw) | root | parent | reply | flag 
 I agree those are forgeable, but having no app name/icon would hurt all normal users, while potential forgery would only hurt occasionally. 

I like your idea of using domain and nip05 of callbackUrl (I think you called it redirectUrl?). OAuth solves this by requiring app registration, but that not nostr way. 

Maybe we could require callbackUrl and redirect user to callbackUrl?token=accessToken which then has to be 'consumed' by the app with a new nip46 method to confirm it's identity? If callbackUrl doesn't belong to the attacker then they won't have the accessToken, doing this + your idea of using domain+nip05 could solve both naming and forgery. Anything wrong with this aside from complexity?

As for the native apps without deep linking support, they could stick to using bunker: links which are more cumbersome for users but don't have these issues.