search

w3c-ccg / universal-wallet-interop-spec

A data model and abstract interfaces for digital wallets
http://w3id.org/wallet
Other
56 stars 13 forks source link

Add a note about generating vs storing #73

Open OR13 opened 3 years ago

OR13 commented 3 years ago

some content like selective dislocure credentials or vps might never be stored in a wallet, but generated from one, we should add notes / guidance on data models that are expected to be generated vs stored.

sudeshrshetty commented 3 years ago

@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?

OR13 commented 3 years ago

@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.

sudeshrshetty commented 3 years ago

@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 .

OR13 commented 3 years ago

@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.

sudeshrshetty commented 3 years ago

@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.

OR13 commented 3 years ago

@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.

sudeshrshetty commented 3 years ago

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 .