Cryptographically, sure, that's always been possible, and it is in fact what SSH affords: if you create an SSH keypair and drop the public half on a remote host, then the corresponding private key serves as your identifier.

The crypto part is relatively easy. Ensuring that you've got the right keys on the right hosts is the hard part.

E.g.:

- If Eve gives Bob a key Eve describes as Alice's but which is in fact Eve's, then Bob is (unwittingly, but cryptographically validly) permitting Eve access.

- If Eve can copy Alice's public key from Bob's system to one controlled by Eve, and Alice isn't scrupulous in verifying host keys, then Alice may be tricked into logging into Eve's system (and perhaps divulging further information) when she thinks she's logging into Bob's.

- There's the more common problem where Bob permits a login using Alice's key, but that key has been compromised in some fashion by Eve. The cyrptography is putatively valid,[1] but the presumption over identity is not.

The PGP "web of trust" model was designed to give some assurance that a key purporting to be Alice, or Bob, or Eve, actually was, and without relying on a central certification authority. It ... mostly kind of worked, but also mostly kind of didn't.

Trust itself isn't a cryptographic property. Aspects or indicia of trust may be cryptographically validated.

For SSH, the trust aspect has been implied in the key-delivery mechanism. Either the trusted party transmits a key directly to the recipient, or they generate the key from on the recipient's system. Further trust of that key relies on both the crypto implementation remaining valid (see again CVE-2008-0166), and control over the private key and any additional authentication factors (passphrase, physical authentication factors, etc.) remaining uncompromised. There are numerous instances in which private keys and/or passphrases have been compromised.

That said, I see some appeal in being able to use, say, SSH keys rather than passwords and other factors to authenticate to websites. In fact there's no need especially to authenticate in the case of content, I need only sign the content which would demonstrated the authenticity of 1) my having signed it and 2) it not being altered since creation. (Say, if dang were to get into the sneaky habit of surruptitiously editing HN comments by other users.)

________________________________

Notes:

1. Or perhaps not, as in the case of CVE-2008-0166, the Debian bug in which time-of-day in seconds was used in key generation resulting in a namespace of only 86,400 keys being possible, a feasibly-brute-forceable space. Those key values are now blacklisted.