You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".)
The text was updated successfully, but these errors were encountered:
cosmos-cash/proto/did/did.proto
Line 42 in afa0ee5
// 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".)
The text was updated successfully, but these errors were encountered: