search

interNFT / nft-rfc

Requests for Comments
Apache License 2.0
60 stars 13 forks source link

Question about Multiple Classifications #8

Closed sunnya97 closed 3 years ago

sunnya97 commented 3 years ago

The NFT-RFC looks really great so far! One question I had that didn't seem explicitly answered in my very brief skim, was can an InterNFT have multiple classifications?

classification: a representation of the type or grouping for an interNFT, e.g. an interNFT “Toyota Corolla” will be of classification car.

So for example, can the Toyota Corolla interNFT be in classification of both car and toyota product

For Admin Use

jandrieu commented 3 years ago

@sunnya97 I believe this gets resolved by attaching a resource to the token that provides that information. This is not yet reflected in the interface spec, but is described in PR #11.

The idea is that resources can be definitively attached, either inline or by reference. These resources could, for example contain Verifiable Credentials that are queryable by example (e.g., graphql). Such credentials could contain any number of attributes of the real-world asset related to a token. For your use case, we would probably expect to see a VC from the manufacturer with details like VIN, make, model, year, categorization, etc.

Directly embedding type information like the categories you suggest as direct attributes ends up being a modeling problem, a provenance problem, and a privacy anti-pattern. It's a modeling problem because it is not possible to represent all possible attributes in a simple key:value structure. RDF solves this problem, which is the underlying approach with both VCs and DID Documents (and the proposed IID Documents in PR #11 for NFT-RFC-06 NFT Identifiers). It's a provenance problem because simply embedding the attribute in a token may not properly attribute the source of that attestation. The source of such attributes should be known to evaluate their applicability. VCs solve that. Finally, it is a privacy problem because embedded attributes are going to be on-chain, making it possible to discern details about transactions that may not be suitable for the public eye. For example, if you have NFTs for automobiles and you embed the attributes you propose into the metadata, an astute observer could trivially monitor the sales of Toyota products--something Toyota generally prefers to keep confidential. Shifting this metadata off-chain is vital to avoid unnecessary leakage of potentially sensitive information.

The newly proposed AssociatedResources property allows us to specify such attributes inline if appropriate, but also supports referring to off-chain resources which may require additional access privileges. Token creators would be able to choice which best suits their situation. The key is that the AssociatedResource pattern provides both as first class, supported options. (Like css files and inline-styles in html). If we were to start embedding resources in the metadata directly, it would likely lead to "expected" values exposed publicly, making it hard later to create a privacy respecting version should it prove necessary.

You could also use a JSON-LD AssociatedResource (instead of a VC), which extends the IID Document and simply adds the statements you want, either inline or in a separate resource. This would be the lightest weight option that keeps the first-class support for both inline and referenced resources.