Add CryptoWalletFacet and CryptoAddressFacet

[cyberinvestigationexpress]

Background

For a growing number of investigations, there is a need to represent cryptowallets and the account(s) they contain.

Crypto wallets can be hosted by an online service, or stored in a software wallet application, or secured using a hardware wallet.

Requirements

Requirement 1: CASE must be able to represent what cryptoaddress(es) were stored in a given cryptowallet.

Requirement 2: CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress at a point in time.

Requirement 3: CASE must be able to represent multiple measurements of the balance of a crypto wallet.

Benefits

• Representing cryptowallets and cryptoaddresses is necessary for various cyber-investigations, including Dark Web activities and cryptocurrency transactions.
• (Noted during administrative review) QUDT employs owl:versionIRI, giving CDO a chance to try versionIRI practices under consideration for CASE's and UCO's versioning.

Risks

• (Noted during administrative review) Some proposals under draft are considering importing ontologies outside of the UCO/CASE ontologies. None have been accepted yet. This proposals includes incorporating QUDT. (It remains to be reviewed whether this would be adoption of certain provided classes, or importing QUDT.)
• (Noted during administrative review) One logistical risk pertaining to usage of QUDT is that its ontology resources only transmit from their namespace IRIs via plaintext HTTP. TLS fails with a 404 message. Transmission risks can be mitigated by CASE tracking the QUDT public Github repository as a Git submodule.
• (Noted during administrative review) Usage of QUDT for unitary measurements introduces a design a pattern to CASE that is not used elsewhere in UCO-housed concepts. One concept where unitary measurement could be applied is the UCO property observable:storageCapacityInBytes - that property could reduce its name to storageCapacity and use the unit:BYTE unit of measure. In short, adoption of this proposal induces a need in CASE to explain why some numeric properties are represented with qudt:unit and others aren't.

Competencies demonstrated

Competency 1

The cryptoaddress(es) that were stored in a given cryptowallet, and how much cryptocurrency they had.

Admin. note - For this proposal, the competencies should include a sample JSON-LD snippet and two SPARQL queries demonstrating satisfaction of the above competency statement, i.e. SELECT ?nCryptoWallet ?xCryptoAddress and SELECT ?nCryptoWallet ?xQuantity, with the latter demonstrating something similar to usage of http://qudt.org/vocab/unit/AUD. (?x prefix is where the admin. review was unclear on what value(s) or value form(s), node or literal, should be returned.)

Solution summary

1. Add CryptoWalletFacet with the following properties:

cryptoWalletIdentifier (string): the identifier of a wallet
cryptoWalletName (string): the name assigned to a wallet
cryptoWalletCreatedTime (date): when the wallet was created
cryptoWalletSeed (string): a series of words for accessing crypto associated with the wallet.

2. Add CryptoAddressFacet with the following properties, using qudt.org ontology to represent currency:

cryptoAddress (string): reference to CryptocurrencyAddress containing the value of the cryptocurrency address
cryptoCurrencyType (string): the type of cryptocurrency in the wallet
cryptoAddressFormat (string): P2SH (BASE58)
cryptoAddressName (string): the name assigned to the cryptocurrency address
cryptoAddressCreatedTime (date): when the cryptocurrency address was created
cryptoAddressBalance (currency - qudt): the total amount of cryptocurrency in the cryptocurrency address
cryptoAddressCompletedTransactionCount (integer): how many transactions have been completed using the cryptocurrency address
cryptoAddressTotalSent (currency - qudt): the total amount of cryptocurrency sent by the cryptocurrency address
cryptoAddressTotalReceived (currency - qudt): the total amount of cryptocurrency received by the cryptocurrency address
cryptoAddressPendingTransactionCount (integer: how many transactions are pending for the cryptocurrency address

3. Add CryptocurrencyAddress observableObject (subClassOf observable:DigitalAddress)

4. Create example using public data: Wallet Explorer (https://www.walletexplorer.com/wallet/335f3892f622984f

5. Add unit test showing potential errors in property usage and how to avoid them

Coordination

• Tracking in Jira ticket ONT-478
• Administrative review to be completed
  • Development of competency queries is in progress here.
• Requirements to be discussed in Ontology Committee (OC) meeting, date TBD

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Implementation has not been merged into develop

• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

It is likely a crypto wallet will have several state-inspections done over the course of an investigation, e.g. to see its balance before some event and after some event. In QUDT, these would be measurements. CASE and UCO do not currently have demonstration of repeated measurements. (observable:Observation has no demonstrations of usage, and further as would help this proposal, no demonstrations of usage on the same object.)

Hence, I've modified Requirement 2, which before read:

CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress.

to now read:

CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress at a point in time.

(An aside: I'd also adjusted the grammar previously to fit a "Must" form. That did not otherwise alter the meaning.)

I've also added Requirement 3:

CASE must be able to represent multiple measurements of the balance of a crypto wallet.

An example of how QUDT is used to do multiple measurements is in another ontology, the Semantic Sensor Network ontology, under consideration elsewhere in UCO. See the Apartment 134 temperature example.

[ajnelson-nist]

This branch and directory houses current development of treating a cryptowallet's balance as a repeatably-measurable property using the SSN, SOSA, and QUDT ontologies. The development currently needs to represent a link between a wallet and an address, and establish CASE classes and properties that are subclasses and subproperties of the corresponding SOSA classes.

[dannyr101]

Alex, I may be missing something, but there are a few things that seem a bit off here:

1. I am not sure if a Wallet Address should have a name, I understand the name at the Wallet level, but not at the address level.
2. The cryptoWalletSeed should probably be a list/array of strings and not a singular string field.
3. You mention that CASE must be able to express the balance within a wallet at a given pint in time, on the other hand you express the properties as singular values without multiplicity, or any timestamp associated to the measured fields. Specifically, I would expect all of the following properties to change over time:
   cryptoAddressBalance
   cryptoAddressCompletedTransactionCount
   cryptoAddressTotalSent
   cryptoAddressTotalReceived
   cryptoAddressPendingTransactionCount

[ajnelson-nist]

Thanks for the feedback, @dannyr101 . This was likely an important nudge before people review this for Tuesday's meeting.

Re: the list in 3:
I fully agree with you on the fields you noted. Those were presented in the original proposal draft as fixed properties on a Facet. I counter-proposed to @cyberinvestigationexpress that they be measurements, drafted the measurements, but then hadn't gotten to removing their fixed-point values from the Facet. That usage is now cut from the drafting.ttl and cryptowallet.json file.

Re: 2, seed values:
I'm fine with removing this cardinality. Do you know of a cryptocurrency that uses more than one seed value? I assume seed-order matters, but it's helpful to have documentation to cite noting so.

Re: Wallet Address name
I defer to @cyberinvestigationexpress on that one. Is this the wallet address behaving like an address book contact, where 1 or more remote parties are providing a name?

[ajnelson-nist]

I believe this proposal will require UCO Issue 535 to be resolved before it can progress.