traceability-vocab

traceability-vocab copied to clipboard

need product clearly identified in intent to import minimum properties:

• product name
• product description
• hts
• gtin
• plu ( can be left off if we permit additional fields)

@OR13 I agree but interfaces like issue, prove never save VCs or VPs. Wallet has to call add() manually to persist the credentials. Shouldn't we add notes to interfaces instead?

@sudeshrshetty yes exactly, I think we should just be more explicit about this, for example:

1. wallet.issue returns a credential which MAY be stored with wallet.add
2. wallet.derive returns a credential which MAY be stored with wallet.add
3. wallet.prove returns a presentation which MAY be stored with wallet.add
4. wallet.query with QueryByFrame MAY return a derived credential which MAY be stored with wallet.add

etc...

We don't want to tell people what to do, but we also don't want to imply that issued credentials are always stored, or that derived credentials for presentations are always stored.

@OR13 Derived credential typically has original VC's id from which it is derived. In that case saved derived credential may end up replacing original credential in wallet content store unless we don't use credential.id as store key.

Not: just noticed we are missing wallet.derive feature in the spec, created #81 .

@sudeshrshetty yeah, thats an excellent point... I wonder if thinking of content as an array vs a map with id keys is worth formalizing... I have been thinking of wallets as arrays / lists not indexed maps.

@OR13 treating wallet content as array will introduce some complexity with add/remove by id features. Also, when we use wallet.prove(), we pass ids for credentials in request and in this case a single credential id can be resolved to multiple stored VCs.

we can leave store key (i.e. id) as wallet implementation specific, a wallet implementation can choose to use JSON LD document id or a uuid as a key for each data model.

@sudeshrshetty yes, in our implementation of the spec, we are doing a lot of this:

wallet.contents.find (c) => c.id === "..."

This is loosely equivalent to SELECT ONE WHERE....

Its not a good idea for assume the presence of id... https://w3c.github.io/vc-data-model/#identifiers

If the id property is present:

And there are blank nodes in JSON-LD:

https://json-ld.org/spec/latest/json-ld/#identifying-blank-nodes

I think its wise for us to RECOMMEND that all objects in a wallet have an id and type... but I am not sure we can safely require that to be the case.

I think treating wallet contents as array makes sense. We can modify add() function to use uuid if JSON LD document id is missing and add() can also throw error if it finds a data model with same id & type already exists in store .