Extensibility for non-standard application data.

[TelegramSam]

I think it's a good idea to allow applications to store application-specific, not-yet standard data within the data model. This allows applications to store useful data to be used when restoring to the same application. Allowing storage within the data model will provide a gradual path to increased standardization of the elements within the model.

We'd need a way to namespace the additional data to prevent collisions between standardized data and the data of disparate applications.

Is this an idea compatible within the purpose and scope of this spec?

[kimdhamilton]

I'm interested in something that's adjacent to this; apologies if I'm hijacking this issue (I can open a new one if so).

I'm interested in these cases and whether they're in scope:

• Storage of other data types (other than those listed in the data model) to back up "universality claims".
  • E.g. if I have a credential that complies with a standard that's not a VC -- say a legacy credential standard that I can't get reissued as a VC -- can I store it here?
  • I'm not arguing for building feature parity for legacy formats, but is it feasible to also treat the wallet as a blob store for items that the holder wants to treat as a wallet item?
• Extension points for specialization
  • For example, EDU folks may care about specific VC-schemas, and want to add special wallet features for them, but this doesn't belong in the core spec.
  • This use case sounds quite different, but your namespace comment is reminiscent of this.

[kimdhamilton]

Back to @TelegramSam's original question, After this discussion #46, I'll start a proposal for this.

The idea is within the purpose and scope, but not in a generic blob store sense (as I referred to previously), but instead through the plugin / extension model.

The spec would need to describe how this works as well as guidance such as Sam mentioned (preventing collisions).

[OR13]

feels like hashlinks to binary are a good solution to this.

[OR13]

Ready for a PR.

[kimdhamilton]

(Updated)

This can be viewed as a specialization of Meta Data. IMO it's worth calling out a special type because a field containing the hashlink(s) should be expected.

• Proposed Data Model Concept: Custom Data
• Proposed Type: CustomData
• Proposed (required) field name: hashlink (single-valued or array)

^ all of these are up for debate.

Use Case: Many existing online course certificates are in PDF or other format. If I'm building an education-themed wallet, I might want to allow the user to add this content for storage and retrieval (needing separate handlers from their VCs of course).

Note: I might further want to add custom handling beyond just storage and retrieval for certain file formats. That could similarly be keyed off the "type"

Example 1

No custom handling needed

{
  "@context": ["https://w3id.org/wallet/v1"],
  "id": "urn:uuid:1d52bc38-c336-455a-8227-2c1e635df2d7",
  "type": "CustomData",           << Can also be array, for example if custom handling (of the file format) by the wallet is desired 
  "name": "Quantum Computing 101",
  "image": "https://via.placeholder.com/150",
  "description" : "Certificate of completion from an online quantum computing course",
  "tags": ["professional", "education"],
  "correlation": ["urn:uuid:d36fd219-bccd-4ebd-a84a-65ed5751ddd2"],
  "hashlink": "hl:zm9YZpCjPLPJ4Epc"    << Can also be array
}

[kimdhamilton]

Clarification: hashlink can be single-valued or an array

[OR13]

First thought is that "CustomData" will become the new "Note" or "AnyData" field... and that worries me in terms of encourage semantic ambiguity... but I also recognize that its 100% a thing that will need to be supported, we should just make it clear that folks should do their best to define common data elements uniquely as much as possible.

[kimdhamilton]

alternate idea:

• No CustomData type
• Propose this concept as a special case of Meta Data
  • Implementors define their types
  • Recommend use of hashlinks

[OR13]

yeah, I think we should say something like:

• you can define your own types.
• you should register your types if you want other wallets to support them

I am not sure hashlinks need to be a part of this, but we might say generally that they are a good idea for external (non local) content.