Closed TelegramSam closed 3 years ago
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:
Back to @TelegramSam's original question, After this discussion https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/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).
feels like hashlinks to binary are a good solution to this.
Ready for a PR.
(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.
^ 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
}
Clarification: hashlink can be single-valued or an array
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.
alternate idea:
yeah, I think we should say something like:
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.
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?