Re: Recommendations for Storing VC-JWT

For clarity, my perspective here is tinted by the idea of a verifier having
credential processing and application logic being distinct components. The
processing component manages issuer trust, network resolution, and possible
data massaging and transformations. The application component has specific
data needs and business logic based around those needs. These could be
provided by different parties.

In this sort of environment, the component with the needs for flexibility
around data structure may have incentives against data retention in e.g. a
queryable graph store. The application may very well need data retention,
but may restrict its trust and data model to the verification component,
and only retain the data needed for its particular use case.

On Tue, Feb 22, 2022 at 8:30 AM Orie Steele <orie@transmute.industries>
wrote:

> Clearly, we can do a better job of supporting database integrations with
> VC-JWT in the future.
>
> The solution I am leaning towards now is simply to store the data in
> decoded form, and then re-encode it before calling verify.
>

For some environments, the only reason re-verification would be needed
would be for non-repudiation (perhaps recovery purposes or for legal
challenges). For these, the JWT form can go to archival storage, possibly
with time based expiration. I've actually seen environments which do this
via customizations of logging infrastructure.

Sometimes a non-holder might want to retransmit the VC to another system as
evidence. This would require accessible storage of a verifiable credential.
Note that for some non-JWT cryptographic mechanisms, such third party
retransmission may not be viable because the presentation received by the
verifier is not cryptographically separate from the contained credentials.

This assumes that the data store will not tamper with the JSON member
> order... With this assumption the possible solutions become much more
> elegant and space efficient.
>
> If you stored the decoded JSON in postman for example, you can re-encode
> it before calling a verify endpoint in postman.
>

Depending on environmental needs and the diversity of expected credentials,
you might need to have a document/graph data structure to allow full
querying of arbitrary data, or might go as far as to normalize just the
credential data needed into say a user accounts table (discarding other
properties).

Canonicalization-based security mechanisms still require you to choose to
store in the upstream form (e.g. RDF or JSON fidelity, without omissions or
modifications) in order to be able to re-canonicalize and verify integrity.
Attempting to use such a model directly does put limitations on dependent
business logic.

It is also worth noting that decomposition of a message into an abstract
tree or graph of properties has its own storage and management costs beyond
application-specific schema.

For those reasons, persisting presentations (when needed) in a form closer
to the received data seems appropriate to me for a wide variety of
environments when compared to generically normalizing into a data store.
Storing a JWS as three binary (or mix of binary and
normalization-preserving text) fields seems like a good middle ground.

-DW

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._