Skip to content
This repository has been archived by the owner on Sep 9, 2024. It is now read-only.

Discuss Orbid Identifiers #12

Open
wyc opened this issue Apr 23, 2021 · 4 comments
Open

Discuss Orbid Identifiers #12

wyc opened this issue Apr 23, 2021 · 4 comments

Comments

@wyc
Copy link
Contributor

wyc commented Apr 23, 2021

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:

orbitPepper = HASH("domain.org", ":", $pkhAddress, ":", $keplerOrbitSecretKey)
orbitId = HASH("domain.org", ":", $pkhAddress, ":", $orbitPepper)

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:

kepler://<orbit-id-type>:<orbit-id>/<content-id>

cc @chunningham

@wyc wyc changed the title Discuss Orbid Identifier Schemes Discuss Orbid Identifiers Apr 23, 2021
@chunningham
Copy link
Contributor

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)?

@chunningham
Copy link
Contributor

perhaps if
orbitPepper = SIGN("Kepler Orbit: ", $hostID, $pkhAddress)
No party can create the signature except the Admin, but it can be verified by the host and then discarded. Const string at the start is just for peace of mind.

@wyc
Copy link
Contributor Author

wyc commented May 6, 2021

Recent proposal for OrbitID generation:

<nonce>:<domain>:<did>
such as
BASE58CHECK(BLAKE2B(0:tzprofiles.com:did:pkh:tz:tz1...))

@chunningham
Copy link
Contributor

Final proposal for OID generation, as discussed 14/05:
Given a set of key-value parameters for an orbit, with string keys and values, construct a URL query parameter string, sorted by key alphabetical order. Append this canonicalized query string to the OID method-specific identifier and create a CID from the result. The recommended CID parameters are codec: raw, digest: blake2b_256 and encoding: base58check. The recommended parameter values are domain and salt.

Example:

  • Using the tz orbit method, we create the identifier tz:<pkh> (e.g. tz:deadbeef).
  • Get the parameter set: domain := kepler.tzprofiles.com, salt := 12345
  • Create the canonicalized query string: ?domain=kepler.tzprofiles.com&salt=12345
  • append the two: tz:deadbeef?domain=kepler.tzprofiles.com&salt=12345
  • create a CID: CID_V1("tz:deadbeef?domain=kepler.tzprofiles.com&salt=12345")

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants