-
Notifications
You must be signed in to change notification settings - Fork 14
Discuss Orbid Identifiers #12
Comments
Offboarding (performing the verification method) in this case requires cooperation of the host/operator as the inception event would require use of the secret key. As well, leakage of the secret key by the host would compromise the Orbits control (using the Admin's PK/PKH would prevent an attack on the host from being able to generate malicious inception events). Is there a way we can require secret salt from the Admin (e.g. a signature generated over some pre-defined message)? |
perhaps if |
Recent proposal for OrbitID generation:
|
Final proposal for OID generation, as discussed 14/05: Example:
|
What's in an Orbit ID? Is it just a uuidv4? Content-related hash, such as a Patricia Merkle trie root? Something else?
For now, we've defined what it could look like for blockchain accounts that use public key hashes, such as those represented by did-pkh, where HASH is some hash function to be determined:
This would allow us to in the future set default permissions by defining a verification method as part of this scheme which authenticates the keyholder as the orbit administrator during the authorization policy log inception event.
What other types of Orbit ID types should we support? Do we have a prefix for designating the different orbit types? Perhaps something like:
cc @chunningham
The text was updated successfully, but these errors were encountered: