Topic: Lightweight ID verification for payment protocol v1.1 - page 2. (Read 3477 times)

That's an excellent summary.

How to actually implement it is an interesting question: My understanding is that BouncyCastle for Java implements low-level OpenPGP primitives well, and for Javacsript I hear good things about openpgpjs. Mainly though, when you're talking about doing new certificate authorities, rather than existing systems, my point is that the OpenPGP infrastructure is already there to a much greater degree than people realize. Even something as simple as having the ability to have multiple signatures on a payment request is a good start.

Incidentally, if we find that existing OpenPGP implementations aren't up to the task, I think it's good to use this as an opportunity to change that; we're not the only community with a renewed interest in it.
 

Agreed. I really worry that we're going to find the hard way that stealing valuable, untracable, fungible, digital money is so much more universally attractive than other types of digital malice that previous assumptions about what kind of security is "good enough" are going to be proven very wrong. We're much better off if our not-totally-secure but easy to use software has functionality under the hood to improve on the situation quickly if needed.

I agree with the base principle of both standpoints.... Mike's advocating something totally seamless that you can completely ignore if you wish, much like what happens with the present day identity information for websites.

Peter says it's not robust enough for situations where you need more assurance and/or you're working on a one-to-one basis. I can agree with that.

Mike's saying the OpenPGP solution is too much for the average user to tackle, I agree.

Peter's saying to compromise that and create an OpenPGP system that defaults to using X.509, which will in practice implement Mikes proposal, but leaves the user a nice bit of GUI to alter to use the WoT system.


Nicely implemented, what's not to like? As long as there's not loads of peculiar acronyms in menus bristling around in front of the first time Qt wallet user, then it's likely a valuable feature. As less tecchy people become more confident in bitcoin, they will feel like using it for more crucial/expensive purposes. At that stage, the idea of wrapping their mind around a concept that enables their safer use of bitcoin will be appealing, not a chore. We've moved from a world of horse and cart and telegrams into the current state of modernity through quite a few technological stop-gaps, and yet people are still willing to learn the latest thing if it improves their life. PGP will (belatedly...) come into it's own in an era like this one....

...because the 1990's e-mail + internet security model is becoming more of a real world commercial issue anyway. People will begin to come into contact with PGP just through being exposed to it at work, even if it is just that management are putting PGP signatures on their mails. What's that you're saying, that your boss wouldn't start doing that? Perhaps that may begin to be the difference between businesses that thrive and those that disappear.

If you were as smart as you pretend to be, you would have known that I am actually contributing to the Development & Technical discussion by pointing out the incompetence and conflict of interests of people who abuse a "technical discussion" to advertise themselves here as the ones who are taking care of the "development".

Let me tell you something: I've been watching you for the past few years already and you might keep fooling others, but you won't fool me.
The sad truth about the bitcoin development is: you are not taking care of any development - all you do is a "technical discussion" that leads to completely no useful development.
Either you know it and pretend to be stupid - or you are just stupid and haven't even noticed it.

So going back to a development.
The way I develop things myself is: first get rid of all the people who pretend that they try to help, though never do, just disturb because that is what they get paid for. Your friend Mike is definitively number one here, but you are also close to get on the list, so keep trying... you're almost there!

Anyway, in case if you didn't catch it yet, let me state it once again:
I have been watching you for years already and as much as I agree that you are good in "Technical Discussion", in reality the only thing that you have developed so far seems to be just your own shit - literally. And you might be very proud of this creation of yours, but probably only because you are unaware of the fact that your shit does not really smell nice to other people.

This is Development & Technical discussion. If you don't want to contribute either one of those things to the discussion, go somewhere else.

Sure man - whatever you say, your highness!
I will go to Google and buy an SSL certificate that will ensure me being me, since it seems like to be a very honorable thing to do...

May I do it tomorrow, though?
Because today I still have some actually important things to do, others than getting my shit enlisted in yet another NSA suckers database.

And those people can create specific OpenPGP identities for their forum handle, something people already do on bitcoin-otc, Silk Road-style marketplaces etc. For those who just want decent security on the other hand, they probably want to integrate multiple identities together - I go my "Peter Todd" here, petertodd on reddit, and petertoddbtc on twitter. I'd like to see all three cross-verifying my identity.

...and of course, often people want to be known only by a forum handle, one that they reuse on multiple sites! Again, OpenPGP can do that well, your proposed model doesn't.

re: smartcard, yeah, I got one of those too for my PGP key. Supports X.509 certs too.


Simple, I want the best of both worlds. Trust anchors CA style are fine when you recognize the limitations, so shoe-horn them into the system. WoT however is how the world really works, so make that available for when you need better security. OpenPGP can do both, what you are proposing can't.

Lots of people do want to be known only by their forum handle. If you want a more robust verification of your real world identity, go ahead and buy a cert that shows that. I've done it, it was quite easy and the keys are stored in a smartcard. The cert has my real name on it and when it's plugged in to the USB port my mail is signed automatically with it (so I'm a weirdo who uses s/mime :-)

Now I guess I don't understand what you're arguing in the other cases. You want pgp to be used but with a pre-defined set of trust anchors (CAs) except not the regular ones because that's too centralised? Other than some   protocol differences how would that be different to what I've just proposed and we are already doing? If you want to get trust statements but not from the merchant themselves just look up signatures by cert hash in some server.

Incidentally, this shows so clearly how foolish your way of viewing the world is: No reasonable human being is going to say that my bitcointalk username is my identity, I'm a person, not some bits in some database. Equally no reasonable person is going to say my Google email account is my identity. We've let the security of the SSL certificate authority system degrade to the point where a computer getting compromised, or some records in a domain registrar getting compromised, is enough for a full SSL cert compromise, and that's a very bad thing.

Accounts get hacked, and you're pushing a system where an account getting hacked is a disaster.

Now, as for the practical aspects: You say that X.509 can have multi-authority authentication, which is true in theory, but as I say it's an architecture that just isn't very well suited to that, you're pushing a model of using it that ignores those capabilities, and on top of all that it can't do WoT authentication.

Equally though, the OpenPGP standard does allow for certificate authority style authentication. The PGP Global Directory Verified Key Service is one example, CAcert is another, and the standard itself has good mechanisms for defining authorities and delegating trust. Going back to your idea of bitcointalk/bitcoin-otc/etc. verification you'd have those services use OpenPGP to sign a special user-id on peoples' PGP keys linking their usernames to their identity in a nice standard manner. That's really useful: I'm probably going to be familiar with someone from multiple services, so having those multiple authorities tell me they are who they say they are gives me a lot of faith.

From the UI angle, the obvious way to do all this is to give people a "keep-it-simple" version where you have a pre-built set of trust anchors that comes with all this by default. In many cases this will be enough security, just like in many cases cutting-and-pasting Bitcoin addresses from emails is fine. FWIW I pushed quite hard at the dark wallet conf to give people these kinds of "good enough" options, and the underlying OpenPGP technology is absolutely capable of implementing them, as well as importing X.509-style certificates when appropriate.

But when you do need better security for a big transaction we've given users the tools they need to take things seriously and spend the time to make sure it's done right. I fully expect that a very large number of users won't choose to use those tools at all: they'll outsource the entire thing to third-party Bitcoin banks staffed with professionals who specialize in this kind of security, and they'll place their faith in the legal system and insurance instead. That's ok, it's their money. Meanwhile those who choose to do it themselves can take the time to do it right.

Finally, by using standards like OpenPGP you synergistically improve security for more than just Bitcoins: having the option to use my OpenPGP identity with my email, my code, and my transactions improves the security of all three.

Lets start with your original assumption:


Now for me, a tech-savvy enthusiast, is the PGP model a total failure? Lets see if I can verify the latest Tor download, from scratch with a clean PGP keyring, and my PGP key that I've done a bit of keysigning with:

pete@localhost:~$ gpg --verify tor-browser-linux32-3.5_en-US.tar.xz.asc
gpg: Signature made Tue 17 Dec 2013 03:41:09 PM EST
gpg:                using RSA key 416F061063FEE659
gpg: requesting key 416F061063FEE659 from hkp server keys.gnupg.net
gpg: key 416F061063FEE659: public key "Erinn Clark <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: Good signature from "Erinn Clark <[email protected]>"
gpg:                 aka "Erinn Clark <[email protected]>"
gpg:                 aka "Erinn Clark <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8738 A680 B84B 3031 A630  F2DB 416F 0610 63FE E659

Hmm... [email protected]! Well, that sounds reputable! Of course me being one of your "tech-savvy enthusiasts" I have some knowledge about WoT and know I need to find a path(s) between Erinn and me. I've done kinda well with my key signing, and by downloading six keys, three of whom are people I personally know, I have three independent paths to Erinn's key:

pete@localhost:~$ gpg --recv-key D8F056DD 94C09C7F C8FA5258 F2CF01A8 B0413BFA 70096AD1
gpg: requesting key D8F056DD from hkp server keys.gnupg.net
gpg: requesting key 94C09C7F from hkp server keys.gnupg.net
gpg: requesting key C8FA5258 from hkp server keys.gnupg.net
gpg: requesting key F2CF01A8 from hkp server keys.gnupg.net
gpg: requesting key B0413BFA from hkp server keys.gnupg.net
gpg: requesting key 70096AD1 from hkp server keys.gnupg.net
gpg: key 143C9F41D8F056DD: public key "Adam Back <[email protected]>" imported
gpg: key DE7AAF6E94C09C7F: public key "Peter Palfrader" imported
gpg: key 438F770EC8FA5258: public key "Chris G. Davis <[email protected]>" imported
gpg: key 64A7C0A7F2CF01A8: public key "Bdale Garbee <[email protected]>" imported
gpg: key AC859362B0413BFA: public key "Gregory Maxwell <[email protected]>" imported
gpg: key 37E1C17570096AD1: public key "Asheesh Laroia <[email protected]>" imported
gpg: key EC4B033C70096AD1: public key "Asheesh Laroia <[email protected]>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   3  signed:   4  trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2016-10-18
gpg: Total number processed: 7
gpg:               imported: 7  (RSA: 2)

Of course, me being a tech-savvy enthusiast, I also know that PGP isn't magic and I need to tell OpenPGP how much I trust the identities associated with those keys:

pete@localhost:~$ gpg --update-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
1024D/AC859362B0413BFA 1999-11-27
      "Gregory Maxwell <[email protected]>"
  aka "Gregory Maxwell <[email protected]>"
  aka "Gregory Maxwell <[email protected]>"
  aka "Gregory Maxwell <[email protected]>"
  aka "[jpeg image of size 6019]"
 Primary key fingerprint: DE47 BC9E 6D2D A6B0 2DC6  10B1 AC85 9362 B041 3BFA

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision? 4
1024D/37E1C17570096AD1 2005-12-28
      "Asheesh Laroia <[email protected]>"
  aka "Asheesh Laroia <[email protected]>"
  aka "Asheesh Laroia <[email protected]>"
  aka "Asheesh Laroia <[email protected]>"
 Primary key fingerprint: D004 36A9 0C4B D120 0202  0A3C 37E1 C175 7009 6AD1

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision? 3

etc. etc. Being tech-savvy I know the marginal-vs-fully difference. Once I'm done I try the verify again:

pete@localhost:~$ gpg --verify tor-browser-linux32-3.5_en-US.tar.xz.asc
gpg: Signature made Tue 17 Dec 2013 03:41:09 PM EST
gpg:                using RSA key 416F061063FEE659
gpg: Good signature from "Erinn Clark <[email protected]>"
gpg:                 aka "Erinn Clark <[email protected]>"
gpg:                 aka "Erinn Clark <[email protected]>"


Great! Now I can go leak some NSA slides.

See, that's the thing: OpenPGP is too good. It provides way more robust security than 99% of the average user actually needs, so it's no surprise that the average user is going to think all those !@#$ steps - never mind the keysigning - was a gigantic pain in the ass and not do it. For them the CA certificates that the Tor project also uses are both good enough, and way easier to use. So of course they do. Then again, for those same users personal CA certificates have been a horrible failure too: Who the hell uses MIME outside of some tightly controlled corporate scenarios? Not many. Instead they use the much more practical, and much more centralized, DKIM email signatures that rely totally on your email provider. You yourself have "signed" bitcoinj releases with them.

But sometimes you need better security than that. Take the DNSSEC root keys: they're all verified by a stack of video-taped key ceremonies... and OpenPGP signatures. Or for a non-computer example, have you ever talked to a security professional about the procedures required to deliver large amounts of gold? Everything about when and where the shipment is going gets verified by multiple ways with procedures remarkably like the OpenPGP WoT, and for good reason: while unlike bitcoins you can undeliver gold, it's a procedure that can require armed men and violence.

You complain that users are going to balk at having "two green checkmarks" in their wallet software; I think they're going to be glad they had that the first time one of the checkmarks is bright red... and a day later they read on reddit about how a attack on some certificate authority let some Android wallet be scammed out of thousands of dollars worth of Bitcoin. Real-world attacks have a funny way of making people take security seriously, so lets not push blind reliance on centralized infrastructure any further and give those users the tools to stay safe.

Stop embarrassing yourself.

The only practical failure I see here is Mike Hearn being called a core bitcoin developer.
The fact that Google does not like PGP - it only makes us to want using it even more, though how a silly google puppet like you would even get to know that?

But sure, go ahead, man. Make sure to put more of your lame NSA sucking bullshit into the code, so people will stop using it even sooner - that's better for everyone.

OK, that’s a bit unhelpful. Here’s a longer reply.

X.509v3 does actually allow for multiple signers of one certificate, which amounts to a more scalable version of the OpenPGP WoT. In practice this feature is rarely used because for any given identity, there’s usually one correct way to validate it and so having different entities repeatedly verify the same identity doesn’t really add much. For instance, you claim (wrongly) that bitcointalk.org was victim of a CA compromise. This isn’t correct. No CA had leaked its private key or done anything wrong - bitcointalk lost control of its domain name, which is its identity, and the hacker was able to verify ownership of that identity. You can’t easily separate such a situation from the domain name being genuinely transferred from one legitimate owner to the next - at least not without extra hassles, at which point you start getting into EV territory.

Let’s put it another way. Sometimes people suggest strengthening SSL by requiring sites to present cert chains up to more than one root authority, i.e. a web of trust model. These proposals are ignored because:

a) The outcome of the trust algorithm is either display the padlock or don’t. It’s a binary yes/no outcome because users have been trained to look for the padlock when typing in their password. They don’t have any deeper training than that. What does it mean in the user interface for a site to have one vs two trust chains? Display two padlocks? That would just confuse people.

b) The way identities are verified is standardised, it has to be otherwise the decision to trust a third party for the purposes of id verification is meaningless. If you can beat one authorities way of verifying identities, that means you can probably beat all of them. In the bitcointalk case having two CA’s verify the hackers ownership of the domain name instead of one wouldn’t have helped.

These issues are inherent to the web of trust concept. They aren’t something specific to PKIX vs OpenPGP.

In the case of a wallet, the outcome is also a binary yes/no decision. Do you display the string asserted by the signer, or not? More complicated output rapidly takes us into neckbeard territory. Questions a user would have to answer:

1) I see a single trust path to this identity. Is that OK or should I refuse to pay unless I get two? What if the counterparty claims they can't get two?

2) I see two trust paths to this identity. Does that mean anything or did both paths just duplicate the same work?

It might be possible to resolve these questions in very specific use cases, like if localbitcoins issued certs and then users could cross-sign each others certs when they met in person (like via a trading app - you wouldn’t expose what’s happening to the end user). Then wallets would have to find a meaningful way to explain what had happened. Maybe it could put this into the UI:

“Pay to localbitcoins.com user cooltrader, who has been met in person by localbitcoins user John Doe”

But if that second part wasn’t there, would you refuse to trade with cooltrader? Very hard to say, I don't know what I'd do in this situation.

The final problem is of course, when people talk about the “web of trust model” usually what they mean is “I hate the evil centralised certificate authorities”, implying that they’d rather their apps come with an empty key store and be manually filled up. But I don’t know anyone whose first action on installing an OS is to erase the system SSL cert store and replace it with their own, even though they could. Nobody does that because even though SSL wouldn’t technically break, in practice the number of trust decisions you’d have to make would render it impractical. That's the whole reason we outsource it.

The PGP model has been around for decades and is a practical failure. Attempting to resurrect it is a waste of time. The vast majority of people cannot be bothered with in depth key trust  management, not even the minority who understand how to do it.

But if you want to continue living in a fantasy land where ordinary Bitcoin users are all going to start configuring their web of trust by hand, go ahead!

Of course, from a practical point of view... theymos: you wanna take on the risk of running some pseudo-PKI when you know the underlying X.509 tech and UI's around that encourages trusting it totally? I sure wouldn't given there's money involved.

go11111111111: Mike Hearn is a nice and smart guy. But he's also nearly a parody of himself with his constant recourse to centralization. I dunno, I haven't paid a lot of attention to anything he's said on privacy since he's generally been pretty hostile to it in the past.

We talked about exactly this kind of use-case at Dark Wallet hackathon, and quickly concluded that OpenPGP was fundamentally the right way to do it. (specifically with stealth addresses) Why? Because OpenPGP is built around a web-of-trust model rather than the strict hierarchy that X.509 assumes.

You're example of a bitcointalk-specific PKI is an excellent example of why this matters: I don't trust bitcointalk because they've been hacked multiple times. Nor do I or should I trust centralized certificate authorities that have been compromised - bitcointalk itself recently fell victim to a CA compromise. On the other hand between bitcointalk, bitcoin-otc, and hopefully some shortish PGP WoT path from me to the recipient I've got a reasonable assurance - much more assurance than if I'm trusting the centralized bitcointalk PKI system.

So don't repeat the mistakes of the past all over again by encouraging blind reliance on centralized PKI. Support OpenPGP first, and hack in whatever X.509 support you need to use X.509 PKI when available as secondary authentication. This isn't merchant websites we're talking about after all, this is individuals.

Summary: I propose that each wallet developer include a custom root cert in the set of roots they accept for the payment protocol and that we establish our own mini PKI / X.509 extensions for the Bitcoin early adopter community.

---

Background

bitcoinj 0.11 will soon be ready for release. Just before we release it I'm planning to merge some initial support for the BIP 70 payment protocol, though it won't be very sophisticated. In particular it won't support generating payment requests, only consuming them. But ... after a bit more work to do such as adding support to the wallet-tool command line app (the bitcoinj equivalent of sx) and ensuring that we can load the key store on every supported platform, we'll be ready.

One of the criticisms levelled at the design of the payment protocol is that it uses the PKI, a system of certificate authorities that validate ownership of "identities" (arbitrary small pieces of text, actually) and charge money for the privilege.

These days you can get free certificates for email addresses and domain names. Comodo has a very simple and easy to use way to get them based on HTML5: you just provide your email address and name, which isn't validated so it can be fake, and then your browser generates the private key locally and stores it. Then you click the verification link delivered to your email address, and the process completes with the fully signed cert being installed by the browser into your operating system keystore. It's as easy as signing up for a website and after doing that, if you use a desktop mail client like Apple Mail.app, Thunderbird etc then you can sign your mails and receive encrypted mails from other people without PGP. The same certificate can be used to sign payment requests. Try it out, it won't take long. The keygen tag actually works for any website.

Issues with the current system

Although getting an email address or domain cert is easy and free these days, there are still some inadequacies here:

• There are over a hundred CA's, of which only two issue free certs (Comodo and StartCom). Others also did in the past but they tended to get bought by Symantec which then discontinued the free services. Free is important to get wide usage.
• Often people communicate using identities which are not email addresses, like forum/reddit handles/social network profiles/IM network handles/etc. CA's do not issue certificates for these kinds of identity.
• Even for a free Comodo email address cert, you have to sign up via a web browser. There's no API to do it from apps.

What stops someone simply setting up a new CA as part of the existing system and adding all these features? In theory, nothing. In practice, a lot. Existing users of the PKI are things like operating systems and web browsers, all of which get distributed to hundreds of millions or even billions of people. Often, CA certs are put inside embedded devices like cameras or TV sets. Update cycles are slow. This makes the cost of a leaked root private key astronomically large - potentially billions of devices must be updated and millions of identities revoked and reissued.

Because the PKI system is so large, and the cost of root cert revocation so huge, browser and OS makers require a high degree of professionalism before they'll consider adding you as a root CA. Reducing risk means expensive measures are taken to preserve security:

• Root keys are stored offline and used only to sign intermediate certificates. This is a bit like a "cold wallet".
• Intermediate keys are stored in dedicated tamper-proof hardware security modules.
• CAs must allow users to mark their certs as revoked so when users get hacked or lose their private keys, people automatically stop trusting those keys. That means servers have to be funded and run to serve real-time revocation data via OCSP. The bandwidth and CPU's for this is a cost of business.
• Employees must be background checked and business processes put in place to stop rogue employees issuing fake certs to themselves.
• All the above is too hard for Mozilla/Chrome/Apple/Microsoft/Debian/etc to check themselves, so they outsource verification to professional auditing firms, who of course don't work for free.
• Because all the above is costly, CAs tend to charge for their certificates, which in turn means people expect tech support and other expensive things, raising the cost still further.

The above requirements are just a flavour of what it takes to get into the Mozilla or Windows/MacOS root cert stores. That's why you can't do it, and if you did, you'd end up charging money and selling out to Symantec as well.

An alternative

Is all the above really necessary for every use case? Sometimes the answer is definitely yes - if you see your Trezor say, "Pay 5 BTC to Overstock, Inc of Salt Lake City, USA" you want that statement to actually be meaningful and hard to forge, and Overstock can easily swallow the cost of paying someone to verify who they are. The PKI and existing CAs get us that functionality.

On the other hand, for a message like "Pay 0.5 BTC to bitcointalk user satoshi" you don't really need that level of security. You know that bitcointalk is just a web forum that gets hacked from time to time and that forum handles don't mean much, but you're probably OK with that for small purchases. And if all your communication was on this forum with a particular user handle, then seeing an email address or a real name doesn't actually help because that's not the identity you're expecting and have built trust in.

There is no way in hell that Mozilla is going to accept a root authority run by Theymos for a couple of reasons:  bitcointalk has a terrible security track record so it'd be very likely to get revoked, and forum names don't mean anything to a web browser anyway. But nothing stops wallet app authors from trusting Theymos for this purpose.

What does this mean in practice? Let's say that when bitcoinj 0.11 rolls around it checks all the OS provided root certs, AND also a set of custom root certs for various providers that the Bitcoin community uses a lot like this forum, or reddit, or the Bitcoin Foundation, etc. A final root cert owned by the wallet author (or possibly me in this case) can also be added so new providers can come online without waiting for wallet users to upgrade.

These certificates are regular X.509 certs but with a new extension field that indicates how subcerts should be displayed to the user, for instance:


Now when this forum issues someone a cert with CN=satoshi, wallet software knows to display it in the UI like this:


... same for reddit, #bitcoin-otc, localbitcoins, etc.

What does this look like for the user? Try it out and see. For a browser like Chrome or Safari, when the browser installs the cert it does so into a global keystore that is accessible to wallet apps too, so that's all that's required to install it.

This would upgrade the security for many common payment scenarios without much cost. Of course the chances of hacks/screwups and global revocations are pretty high, but we're still a small community mostly made up of tech-savvy enthusiasts so we can tolerate that for now.

The nice thing about making minor extensions to X.509 rather than trying to support a second PKI is that we get to reuse all the infrastructure, software and protocols built to support the existing system. For instance, if the bitcointalk admins are handling people who get their accounts hacked and helping them restore access then they could also start running an OCSP server so any certificates issued during the time the account was hacked get automatically revoked. From the perspective of wallet devs and site admins it just requires reusing existing software, so it's a small amount of extra work.