cleaning-service

[jchartrand]

@kayaelle Just getting down some details for the 'cleaning-service' we talked about last week, i.e., a service that would take the raw data with which to populate a VC and run different checks on it to confirm the data works for a given VC type. The service could also check pre-populated VCs both pre-signing and post-signing.

Thinking about it more since last week, I wonder if this should be part of the template-service for a given credential type, since the cleaning checks for things specific to the given kind of credential - like a degree - and those things would also of course be specific to the template.

Further, most of the checks are likely best handled with json schema, using a very tightly defined schema for a given credential type (e.g., a degree), which could also formally define the template.

This actually kind of makes a stronger case for a template-service in general. Whereas before I think the idea of the template service was simply to provide a template that could be populated with data, now we package together both the template and also a schema that validates the populated template. There may end up being other template-specific things that could go in there. It might be too that a single template-service could manage several templates and their associated schemas. So say a DCC template service that provided a template schema for an OBv3 degree, and also for an OBv3 'simple' credential. In any case, the template-service isolates everything to do with a given credential type (like a degree).

As an example, for the case of a degree defined as an OBv3, this 'very tightly defined' schema would be exactly those parts of OBv3 that are needed for the degree. So it makes perfectly clear what goes into a degree, removing potential confusion for those trying to figure out what parts of OBv3 make sense for a degree. It could also additionally define restrictions on things like field length, where we don't, for example, want the degree name to exceed some length otherwise it won't fit in a display field.

This simple schema is essentially a highly opinionated and restrictive definition of an OBv3 for a degree. Doesn't mean everyone has to follow that definition, but my guess is many projects might be very happy to have a well defined schema that they can follow, and also a template service to which they can just supply raw data, without worrying about OBv3 at all.

So then, assuming the cleaning-service and template-service are all together in one service (still probably called a template-service) then the flow might go:

1. Data is posted to the template-service. The data could be raw data needed for the template, or it could be a pre-populated VC.
2. The service constructs a VC (or VCs) from the incoming data, using its template.
3. The service then runs a schema check on each of the VCs
4. The service returns the populated VCs and the results of the checks.

The data that is posted to the service could look something like:

{
"credentialTemplate": "degree",
"schema": "a different schema if want to override the default",
"unsignedVerifiableCredentials":
[
...pre-populated vcs go here, if we've already built them but still want to check them
],
"credentialData": {
"defaultValues": {"degree":"Bachelor of Science"}
"instanceData: [
{
"major":"Computer Science",
"recipient": "Jane Davis",
"institution":"Wonderful University",
"awarded":"1994"
},
{
"major":"Information Science",
"recipient": "Jonas Smith",
"institution":"Wonderful University",
"awarded":"1995"
}
],
},
"cleaning": {
"checkSchema": true, // might just want to use the templating and not the schema check
"maximumLength": 3000, // max length of cred, if say we want to fit it in a QR
"returnVCs": true // if we aren't just checking the data, but also want the populated VCs back
}

}