"Signing a key" really means signing the binding of a uid to a public/private key pair. I had to look at the Open PGP spec to figure that out ;-)
The question is, how to do verify that a particular person is exclusive owner of a uid? Because the uid is just a piece of text, there is no general way that will work every time. It depends on what the uid is. Someone could put their Passport number in the uid and you could check the passport to verify that they own it.
Of course most people use an email address as a uid. There are some key exchange protocols that will give you a pretty good idea that someone controls an email address (although they may not be exclusive owner). Basically you email them with some information and then they email you back with an encrypted version of that information. While they can spoof sending the email, they can't easily receive the original information to encrypt it.
Generally speaking, online, email uids are what is most useful. You need to know that the person who sent the message has access to the email address in the uid. But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.
A key can actually have many uids. You can add new ones at any time. But if you do, you need to get people to sign the new uids (because while they may trust that you control one uid, they still need to verify that you actually control the other uid).
How you decide that the uid is owned by the owner of the key is up to you and you are free to sign or not sign any key. The web of trust comes where someone else has signed the uid on a key. There is a kind of second order level of trust with that signature. If my buddy Fred has signed the uid, and I am absolutely sure that Fred will never sign a uid without making sure that it is owned by the owner of the key, then I will probably trust it. But if my buddy Carl signs it, I might think "Carl is not diligent enough to check it out", so I might not trust it as much. How you assign trust of third parties to sign appropriately is up to you (and you do it for each of the third party keys that may have signed something).
> But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.
Why not just name + email? I don't think putting anything like a passport number is a wise idea. It's just putting one more semi-secret information on the internet.
I think the encryption and signing+trust gets mixed here. If I know someone only by email address, I don't trust their key very much. But I'm still going to use it to encrypt messages to them, because it's better than nothing. I'm going to trust it if it's got a track record of reasonable messages on mailing lists or git commits over some period of time.
But back to the main topic: email-only, and passport number are two extremes and the second one is even hard to verify. Most people actually just use name+email combination in uids. And that's what gpg invites you to do when generating keys. Why didn't you mention it?
The point is that the uid is just a string. You can put anything you want in it. Most people put their name + email because that's what is useful for most internet transactions. If you get an email from someone, you want to be able to verify that it is from the person who controls that email account.
For example, I work in Japan. My colleagues work in the UK. Generally speaking I know who they are because I work with them every day. However, I have never checked their real life credentials, because it doesn't matter to me. When I receive an email from them, all I am interested in is "Is this Joe Blow that I work with from the UK". I don't care if Joe Blow is their real name, or if their carefully cultivated story of growing up in Shouthampton and going to the London School of Economics is true (as opposed to growing up as an indentured clown in a travelling circus and escaping at the age of 14 on the back of an elephant). When I receive an email from them, none of that matters. I just care if it's the same person I worked with.
So most of the time people put their email address and a name (which may or may not be fictional). When I sign that uid against a key I am saying, "I verify that this person controls this email address and is the person I know as Joe Blow".
If you actually care about whether the person is who they say they are, then the uid is going to have to contain something more identifiable/verifiable. So for instance, let's suppose I'm a bank. I want to verify that orders coming from my customers are really from that person. It is important that it is really that person because there are laws about identifying where bank transactions originate. I don't care which email addresses they control. I don't care if they are spoofing their email address. What I care about is that any messages I receive from them are really from them (and that any encrypted messages I send to them is really only readable by them).
So a passport number would be a good solution. The person walks into a bank with a USB key containing their public key with a passport number uid on it. The bank physically checks their passport to see that it matches and that it does, indeed, belong to the person who claims that it does. It then signs that uid against the key and locks it away somewhere. The key never has to be on the internet. Why would it? Nobody on the internet cares who you really are (apart from the NSA, I guess). They only care that you are the person who owns a particular email address.
I agree that there is a lot of confusion over encryption, signing, trust and identity verification. To a large part, I blame the convoluted nature of Open PGP and the existing documentation which conflates many, many issues.
I don't understand why do you want to sign that UK person's key in the first place. You can't verify who they are and only communicate online. Ok - that sounds to me like you shouldn't announce "I trust this is a real name/email" in that case. You can trust it privately and still use the key anyway.
But nobody is forcing you to sign the key, or even then to publish that information on the internet. As you say - how do you know they're that person?
(I'm ignoring the part of - should we even care that the identity matches. You communicate with the (person, key) tuple - you can still trust that tuple and not care if the name matches government documents)
A bank is a slightly different case. Your key for communication with the bank is (usually) more interesting than the key you use for emails. The bank also has both interest in protecting communication and means to do something better than key signing. Some banks will actually issue you a smartcard (or some equivalent) from which you can't export the private key at all - it may even be a gpg key. The point is - that's a much better protection on average, because an average bank customer has no idea about gpg, but will likely not give the smartcard away to someone random. Finally, few people have passports and you shouldn't be required to have a passport to have a bank account.
The question is, how to do verify that a particular person is exclusive owner of a uid? Because the uid is just a piece of text, there is no general way that will work every time. It depends on what the uid is. Someone could put their Passport number in the uid and you could check the passport to verify that they own it.
Of course most people use an email address as a uid. There are some key exchange protocols that will give you a pretty good idea that someone controls an email address (although they may not be exclusive owner). Basically you email them with some information and then they email you back with an encrypted version of that information. While they can spoof sending the email, they can't easily receive the original information to encrypt it.
Generally speaking, online, email uids are what is most useful. You need to know that the person who sent the message has access to the email address in the uid. But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.
A key can actually have many uids. You can add new ones at any time. But if you do, you need to get people to sign the new uids (because while they may trust that you control one uid, they still need to verify that you actually control the other uid).
How you decide that the uid is owned by the owner of the key is up to you and you are free to sign or not sign any key. The web of trust comes where someone else has signed the uid on a key. There is a kind of second order level of trust with that signature. If my buddy Fred has signed the uid, and I am absolutely sure that Fred will never sign a uid without making sure that it is owned by the owner of the key, then I will probably trust it. But if my buddy Carl signs it, I might think "Carl is not diligent enough to check it out", so I might not trust it as much. How you assign trust of third parties to sign appropriately is up to you (and you do it for each of the third party keys that may have signed something).
I hope that helps!