Difference between revisions of "Proof of Control"
(→Context) |
(→Context) |
||
| Line 6: | Line 6: | ||
'''Goal''': to convert establish a level of assurance that he user is who they claim to be. | '''Goal''': to convert establish a level of assurance that he user is who they claim to be. | ||
| − | + | # the user signs a nonce with their credential and returns it to the requester. | |
| − | + | # the user signs a nonce and provides proof of the security of the device holding the credential. | |
| − | |||
===DID CORE doc on Persistence=== | ===DID CORE doc on Persistence=== | ||
Latest revision as of 15:08, 25 January 2021
Full Title
Proof of Control applies to credentials that are meant to show that the user at the end of a communications link has control of that credential.
Context
- Decentralized ID presents a problem with assurance of the trustworthiness of the wallet apps.
Goal: to convert establish a level of assurance that he user is who they claim to be.
- the user signs a nonce with their credential and returns it to the requester.
- the user signs a nonce and provides proof of the security of the device holding the credential.
DID CORE doc on Persistence
DIDs are designed to be persistent in the sense that no administrator can take control away from the controller, nor can an administrator prevent their use for any particular purpose such as authentication, authorization, and attestation. There is no trusted third party with the capability of removing an individual's—or an organization's identifier—nor can they render it inoperable.
However, it is important to note that in all DID Methods that enable cryptographic proof-of-control, the means of proving control can always be transferred to another party by transferring the cryptographic secrets. Therefore, it is vital that systems relying on the persistence of an identifier over time regularly check to ensure that the identifier is, in fact, still under the control of the intended party.
Unfortunately, it is impossible to determine from the cryptography alone whether or not the private key material associated with a given proof mechanism has been compromised. It may well be that the expected controller still has access to the private keys—and as such can execute a proof-of-control as part of a verification process—while at the same time, a bad actor also has access to (or a copy of) those same keys.
As such, cryptographic proof-of-control should only be used as one factor in evaluating the level of identity assurance for a given service. DID-based authentication provides much greater assurance than a username and password, thanks to the ability to determine control over a secret without transmitting that secret between systems. However, it is not infallible. Services that perform sensitive, high value, or life-critical operations should use additional factors as appropriate.
Solution
there are two ways to get a trusted signer on the phone.
- register an app that is trusted. If that is the method the easiest way is to register the actual instance of the wallet itself to the user.
- depend on the trusted element in the phone to boot up an assurance element - the TPM code in the TEE could do that, but it depends on a trusted server in the could. All of these depend on a web of trust that is not based on any human intervention. Not sure what the rWOT guys think about that? (nb this could be accomplished with a webauthn token like that from Yubikey)
References
- This wiki is part of the larger problem of Apps on User Devices.
- Also part of the wiki page on Proof of Presence.
- A related problem is described in the Over 21 with Proof of Presence Use Case.
