The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.

For the key server refresh the fingerprint should be used. But maybe I made a mistake.

Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.

I could argue that people who have keyserver in their auto-key-locate list are okay with retrieving additional keys for email addresses. I mean they will fetch a "random" key matching the email address when they want to encrypt something for this email address. But, yes, they probably wouldn't expect this if they do an update.

I could add a special key list mode GpgME::WKD which would use --locate-external-keys with --auto-key-locate clear,wkd. Or shall I remove the update via WKD? Then, how would one update a key via WKD?

I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?

Thanks, the update button this is now more what I think is expected. Still I am not sure if removing it completely was neccessary, well we have it in the history now. Because I see the need to also update via WKD. Currently we only update from there if a key is expired but we would never see revocations. That is a problem that we will need some solution for at some point. But yeah in that case calling it "RefreshOpenPGPKeysJob" would be a misleading API Name anyhow. So its probably good that you removed it before the upcoming release.

I have kept a backup copy of a WKDRefreshJob locally. ;-) But that's stuff for a different task.

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

I would suggest the following, if it is somehow possible. I think we have the API for this now that we can search for WKD keys without importing them. We should additionally check WKD, if the key from WKD has the same fingerprint, we update, if it has not, we show the user something like a search result. Give indication that a different key was found for these UserIDs and then let the user decide to import them?