See the Matrix chat for context, reproduced here:
nicfab:
Hi,
My profile is https://keyoxide.org/9a85d44ae2d38f19d5ffe2c8655812fca35b817f, but - as you can see - on Keybase, a red X.
The proof I used is as follows:
Keybase => proof@ariadne.id=https://keybase.io/nicfab
Where am I wrong?
aspensmonster:
I'm not sure. At first glance, the public key fingerprint, 9a85d44ae2d38f19d5ffe2c8655812fca35b817f, is where it should be in the KeyOxide API response (['them', 'public_keys', 'primary', 'key_fingerprint']). The claim itself looks good in the public key. When I run the app locally, I sometimes get a timeout when attempting to fetch the proof from the Keybase API (but sometimes don't).
However, I think the main issue is that the proof from the API ultimately has just the fingerprint itself, 9a85d44ae2d38f19d5ffe2c8655812fca35b817f, while the proof checker is looking for the string openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f. This fails, and thus the proof check fails. I'm thinking that there might be a bug in whatever is setting params.target to openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f when calling containsProof. From what I can tell, the Claim itself has its _fingerprint property as openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f. But... all the other claims seem to have _fingerprint set that way and they verify fine. So perhaps the bug is elsewhere.
Indeed, the only serviceProviders that have target.format as E.ClaimFormat.FINGERPRINT rather than E.ClaimFormat.URI are Keybase, Lichess, and Owncast. That led me to looking at generateClaim inside of containsProof:
function generateClaim (fingerprint, format) {
switch (format) {
case ClaimFormat.URI:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint
}
return `openpgp4fpr:${fingerprint}`
case ClaimFormat.FINGERPRINT:
return fingerprint
default:
throw new Error('No valid claim format')
}
}
Interestingly, this code has what looks like a defensive check for the wrong input fingerprint in the case Claim.Format.URI scenario, ensuring that openpgp4fpr:123456789 is returned regardless of whether fingerprint was set that way originally or not. But on the case Claim.Format.FINGERPRINT scenario, the fingerprint input is trusted as-is and returned. When I adjust the code to the following and run locally, the keybase claim verifies successfully:
export function generateClaim (fingerprint, format) {
switch (format) {
case ClaimFormat.URI:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint
}
return `openpgp4fpr:${fingerprint}`
case ClaimFormat.FINGERPRINT:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint.split(':')[1]
}
return fingerprint
default:
throw new Error('No valid claim format')
}
}
I'll file a bug report on the doipjs repo.
See the [Matrix chat](https://matrix.to/#/!dEfJkFpQpwvbzcegRX:matrix.org/$ESWc427xVJKw7jKJCKxo9vNodNofzzwdv69TROyDfWE?via=matrix.org&via=mackenba.ch&via=tchncs.de) for context, reproduced here:
nicfab:
>Hi,
>My profile is https://keyoxide.org/9a85d44ae2d38f19d5ffe2c8655812fca35b817f, but - as you can see - on Keybase, a red X.
The proof I used is as follows:
>
>Keybase => proof@ariadne.id=https://keybase.io/nicfab
>Where am I wrong?
aspensmonster:
>I'm not sure. At first glance, the public key fingerprint, `9a85d44ae2d38f19d5ffe2c8655812fca35b817f`, is where it should be in the KeyOxide API response (`['them', 'public_keys', 'primary', 'key_fingerprint']`). The claim itself looks good in the public key. When I run the app locally, I sometimes get a timeout when attempting to fetch the proof from the Keybase API (but sometimes don't).
>
>However, I think the main issue is that the proof from the API ultimately has just the fingerprint itself, `9a85d44ae2d38f19d5ffe2c8655812fca35b817f`, while the proof checker is looking for the string `openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f`. This fails, and thus the proof check fails. I'm thinking that there might be a bug in whatever is setting `params.target` to `openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f` when calling `containsProof`. From what I can tell, the `Claim` itself has its `_fingerprint` property as `openpgp4fpr:9a85d44ae2d38f19d5ffe2c8655812fca35b817f`. But... all the other claims seem to have `_fingerprint` set that way and they verify fine. So perhaps the bug is elsewhere.
>
>Indeed, the only `serviceProvider`s that have `target.format` as `E.ClaimFormat.FINGERPRINT` rather than `E.ClaimFormat.URI` are Keybase, Lichess, and Owncast. That led me to looking at `generateClaim` inside of `containsProof`:
>
```
function generateClaim (fingerprint, format) {
switch (format) {
case ClaimFormat.URI:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint
}
return `openpgp4fpr:${fingerprint}`
case ClaimFormat.FINGERPRINT:
return fingerprint
default:
throw new Error('No valid claim format')
}
}
```
>
>Interestingly, this code has what looks like a defensive check for the wrong input `fingerprint` in the case `Claim.Format.URI` scenario, ensuring that `openpgp4fpr:123456789` is returned regardless of whether fingerprint was set that way originally or not. But on the case `Claim.Format.FINGERPRINT` scenario, the fingerprint input is trusted as-is and returned. When I adjust the code to the following and run locally, the keybase claim verifies successfully:
>
```
export function generateClaim (fingerprint, format) {
switch (format) {
case ClaimFormat.URI:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint
}
return `openpgp4fpr:${fingerprint}`
case ClaimFormat.FINGERPRINT:
if (fingerprint.match(/^(openpgp4fpr|aspe):/)) {
return fingerprint.split(':')[1]
}
return fingerprint
default:
throw new Error('No valid claim format')
}
}
```
>
>I'll file a bug report on the doipjs repo.