Validate a FF asset

[moskovich]

Acceptance criteria:

• A sample asset JSON-LD that can be properly validated by the parser using FF and IID contexts
• Define the method identifier for did:bmk

Reference:

There are two basic approaches to generating a globally unique identifier from a public key:

• With the transactional approach, the controller uses the public/private key combination to perform a transaction with a blockchain, distributed ledger, or other algorithmically controlled system to generate a transaction address (such as a Bitcoin or Ethereum address). This transaction address becomes the identifier because it is globally unique and provably controlled by the controller.
• With the self-certifying approach, the controller performs a cryptographic operation, such as a one-way hash function, on the public key (and potentially other metadata) to produce a globally unique value that, by definition, only the controller can prove they control.

— Alex Preukschat. Self-Sovereign Identity mobi (Kindle Locations 5034-5040). Manning Publications Co..

[hxw]

did:bmk

• I originally thought a random value would be sufficient, but this may be a problem when we do multiple chains. I could lead to forged assets since there would be no relationship between the data and its ID.
• For the tx case I wonder if the server should add a NONCE as ask the submitter to sign this with the appropriate blockchain-specific key. I am thinking that the wallet needs to have derivation for BMK keys (we do have an assigned code) along with derivations blockchain key. For existing assets we could just derive the DID value from the tx id (Should this include a code byte from the originating blockchain?)
• self certifying may be more problematic if we want to incorporate existing assets already on the blockchain.

[hxw]

If the did:bmk is essentially the name of the asset (like URN); do we get a concept of location (like URL) from the resolver?

[nodestory]

did:abt mixes the transactional and self-certifying approach according to the RoleType. The self-certifying approach is used for assets.

[nodestory]

If the did:bmk is essentially the name of the asset (like URN); do we get a concept of location (like URL) from the resolver?

DIDs are designed to be persistent such that a controller need not rely upon a single trusted third party or administrator to maintain their identifiers, so DIDs as URNs.

As for URL, the DID does have DID URL.

The terminology URL is confusing since Usually URLs are web addresses. The DID community once had a discussion about this. It seems that they used a broader definition: URL is a dereferenceable URI.

The DID spec defines how to dereference a DID URL. A resolver should:

• resolve a DID into a DID document
• deference a DID URL into a resource (could be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document)

From the same book "Self-Sovereign Identity":

A DID is a URI that can be either a URL or a URN and that can be looked up (resolved) to get a standardized set of information (metadata) about the resource identified by the DID (as described in the next section). If the identified resource has one or more representations on the web, the metadata can include one or more of those URLs.