Hey there, I’m one of the developers on cert-wallet. I’ve noticed a common point of confusion with how our app works, and I wanted some feedback from the community to choose how to best resolve it.
Problem Statement
Right now, one of the key promises that the Blockcerts standard claims is strong proof of ownership. If a certificate is issued to me, then not only should I be able to prove that certificate is valid, but I should also prove that I’m the intended recipient of that certificate.
The problem is, this current iOS app doesn’t reflect this model. I’m able to import, display, and validate certificates without that proof of ownership. All I need to do is find a certificate with someone who has a similar name to mine, and I’d be able to (falsely) claim ownership.
Proposed Solution
I think we should focus the purpose of the wallet to only be for certificates that I own. When you import a certificate, it does a check with the on-device keychain to make sure it’s been issued to an address I own. If so, great! If not, then the import will fail with an error message simply stating that you don’t own that certificate.
This changes the app to meet the expectation that a lot of users already have – if I’ve got a verified Blockcert in my digital wallet, then it’s proof that I accomplished something.
Migration approach
Since this is a restrictive change, I want it to be gradual over the next few weeks so folks can have time to adjust. I think we can do it in 4 steps:
Add the ability to check ownership on import. This will be in the settings, but turned off by default. This will help us get confident that we’re not rejecting any valid certificates.
Make the ownership more restrictive. You can no longer view unowned certificates – now you get a message saying you don’t own this certificate and should contact the issuer to re-issue you a certificate.
At first I assumed you were heading towards a wallet feature of signing a message with a private key corresponding to the public key, to prove ownership of the key to others (e.g. sign_message capability in Bitcoin). I’ve always like the idea of a wallet signing feature; it’s valuable, because it yields external proof others can check.
But limiting import to certificates I own sounds useful as well. One concern to think through – should we also provide the ability to import private keys not created by the wallet? Otherwise I can’t import valid certificates with keys generated by another source.
We’ll definitely need that public/private key signing challenge for high-value interactions, or between different devices. But I think that’s something we can do on top of this, rather than instead of this.
As to the second point, we’ve talked about bringing in support for multiple keychains (based on multiple mnemonic passphrases), in the event that you went too quickly with your new phone and requested a certificate before transferring over your mnemonic phrase. Again, that would be in addition to this restriction.
However, are you suggesting yet another use case? Where I don’t know/own the mnemonic passphrase, but I just so happen to know the private key, so I should be able to prove ownership? Is that a real use case, or is that the case of an attacker discovering the private key and trying to claim ownership?
I can’t imagine a use case where someone would not also know the passphrase that corresponds to the private key, but the ability to import keys that were created outside of the wallet seems important. Is it still the case, that any public key that’s generated from a valid bitcoin private key could be used to request a certificate?
I also agree with this new approach. In fact, I think will have some implications for design as well. Currently, the cert-wallet really hides the passphrase from the user. As strong ownership becomes central to the app, I could see the on-boarding process having a very design-forward process for accepting a passphrase, as part of teaching users about the app. For later …
I agree with the approach as well. Being able to prove strong ownership is crucial. This can be done with a private key and additional local authenticators as well.
It seems like the discussion has mostly settled on this, and it’s generally positive. This change might require a follow-up feature to allow multiple mnemonic passphrases, allow private key imports, or possibly both, but I’ll follow that up with a separate issue.
If you’d like to follow along with development, it’ll be tracked in this issue.
Also, I started a new discussion on what multiple keychains on one device might look like. I think it basically captures everything we mentioned here, but feel free to add to that discussion if I missed anything.
Just wondering if there is an attribute of the certificate that requires proof of ownership and would require the presenter of the certificate to be challenged before the the certificate is actually verified.
Some certificates may be completely public and do not require proof of ownership before verification. For example, a doctor’s license to practice. The doctor does not need to present the certificate for verification, but rather anyone who wants to make sure the the doctor is license.
In other cases, the certificate may be private, or exclusive to the presenter (an individual proving date of birth). In this case (If I understand the scheme correctly) before the certificate is verified, the presenter is challenged with the something signed or encrypted with the recipient’s public key. If the presenter is successful with the challenge (using the corresponding private key) then this demonstrates it is the rightful recipient and then the next step of actually verifying the certificate can be completed.
Also, there might be away to bind a certificate to an authenticator, such as FIDO, so the certificate can only be presented if this authenticator is also present as well.
There’s nothing in the current certificate format that requires proof of ownership.
Your “Dr.s License” example is a good one. If I’m a patient, then if my doctor is presenting it and it’s showing his or her name, then that may be good enough for me. If I’m suspicious, then I might verify it just to be sure. But, if I’m the hospital hiring the doctor from Hollywood Upstairs Medical College then I might require proof-of-ownership in addition to simple verification.
And yes, your steps for how to prove ownership are correct, although we don’t have plans to bring that interaction to the iOS wallet yet.
Finally, I don’t know what FIDO is, but it would seem like binding a certificate to a specific authenticator would break the decentralized, recipient-owned nature of these certificates. That’s not supported today and seems like a feature we really wouldn’t ever want for certificates, no?
Thanks. Something to think about for future versions of the wallet - the ability to accept a cryptographic challenge from a verifier based on the public key of the recipient and for the wallet to provide a response based on the corresponding private key it holds. The public key challenge and private key response is the very essence of the FIDO protocol and could be easily added. Whether local authenticators are used (or not) is an implementation detail of the wallet application.
This “strong verification” function would be very useful for use cases such as unattended/automated border crossings, building access, etc.
I’ll start another topic on this challenge-based proof of ownership feature. It’s super powerful and we absolutely need it.
It might make sense for the “accepting a certificate & sending a challenge” to be a separate app in the Blockcerts ecosystem, since if we say all certificates on-device are owned by an on-device keychain, then you wouldn’t be able to import someone else’s certificate to find their public address and send them a cryptographic challenge. However, the wallet should absolutely respond to these challenges.
But I’m getting ahead of myself. I’ll make that topic now.
If “There’s nothing in the current certificate format that requires proof of ownership,” what if your current approach offered something akin to ‘unofficial transcripts’, with a different name but a similar approach to today’s hiring practices and education. Apply with an unofficial transcript and upon hire or final interview verify with official. To verify requires the new feature authentication you’re thinking of. Certificate owners would more readily be able to send or share their profile. I mention this because certificate owners most likely share several at one time rather than one or two consistently across a calendar year. Several = job hunt, application to graduate school, joining new non-profit organization. Unofficial could go out as applying, official could be validated by the one or two agencies the owner determines. Then, if it’s more complicated, it doesn’t cause ??? by the requesting agency because they know they are receiving something validated.
I think we have that today. Let’s look at it like this. What is it that makes an official transcript “official”? In my eyes, it’s:
From the school or institution in question
Accurate data on the accomplishment
Regarding the student or applicant in question
Unofficial transcripts say these things, but without any certainty. It’s done like that today because official transcripts are hard to produce & are really only done as the last step, if you’re at the point in an interview process where the truth of these claims matters.
How would you do that with Blockcerts? The good news is, they’re substantially cheaper to issue, and more portable. So I would contend they are, in fact, the unofficial transcript. You can apply with them just by uploading the file (or by sharing the URL in most cases). Let’s see how we do on our 3 points above:
From the school or institution in question
Accurate data on the accomplishment
Regarding the student or applicant in question
Verifying the certificate (which is pretty easy) can prove #1 and #2 are each true. The third check is the requirement for the applicant to prove ownership of the certificate (that we have a proposal for). This would be analogous to getting an “official transcript”, but it’s easier to perform and ideally a lot quicker to get done, since the applicant has a vested interest in getting their true claims verified quickly.
From the school or institution in question
Regarding the student or applicant in question