This should probably be something more like
// The authentication is used to specify how the DID subject is expected to be authenticated, typically
// for purposes such as logging into a website or engaging in any sort of challenge-response protocol.
FWIW, Authentication is a verification relationship that can take any number of any kind of verification method as a value. Many are based on public keys. But the spec doesn't require that particular cryptographic solution. Schnoor or even BIP322 multi-sig methods are allowed.
What's probably important is identifying what authentication is used for wrt on-chain actions (presumably any valid verification method could be specified, but only those methods understood by the chain can be used for on-chain actions like updating a DID Document). It's only in this section of the docs where the means of control over a DID record on chain is discussed. FWIW, how a method secures its DID Document operations is entirely up to that method. Authentication is not presumed to be the expected practice.
Personally, I'd prefer to see a more capabilities driven approach where CapabilityInvocation is the verification relationship that is used to verify the invocation of on-chain actions. That ends up being far more flexible (the target of the action is explicit rather than implied like with "authentication".)
https://github.com/allinbits/cosmos-cash/blob/afa0ee5f7e1aec65f7f8eb75868cf5119d0d7f7d/proto/did/did.proto#L42
// Authentication represents public key associated with the did document. // cfr. https://www.w3.org/TR/did-core/#authentication
This should probably be something more like // The authentication is used to specify how the DID subject is expected to be authenticated, typically // for purposes such as logging into a website or engaging in any sort of challenge-response protocol.
FWIW, Authentication is a verification relationship that can take any number of any kind of verification method as a value. Many are based on public keys. But the spec doesn't require that particular cryptographic solution. Schnoor or even BIP322 multi-sig methods are allowed.
What's probably important is identifying what authentication is used for wrt on-chain actions (presumably any valid verification method could be specified, but only those methods understood by the chain can be used for on-chain actions like updating a DID Document). It's only in this section of the docs where the means of control over a DID record on chain is discussed. FWIW, how a method secures its DID Document operations is entirely up to that method. Authentication is not presumed to be the expected practice.
Personally, I'd prefer to see a more capabilities driven approach where CapabilityInvocation is the verification relationship that is used to verify the invocation of on-chain actions. That ends up being far more flexible (the target of the action is explicit rather than implied like with "authentication".)