View source for Proof of Control

==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 [https://wiki.idesg.org/wiki/index.php/Over_21_with_Proof_of_Presence_Use_Case Over 21 with Proof of Presence Use Case].


[[Category: Glossary]]
[[Category: Authentication]]
[[Category: Assurance]]