Add iss and kid field to receipts

[plietar]

We're headed towards using a DID for the server's identity. This will require a few parts, but the first step would be to add iss and kid fields to the receipt's protected headers.

The iss value would be copied from an optional field in the configuration file. If the field is missing, we'll omit the iss and kid altogether. The kid should represent the current service's certificate/public key and will change on disaster recovery. For now, I think we can use the same value we use for service_identity, ie. the hash of the DER certificate, and revisit this in the future.

Even though it will be redundant with the kid, I think we shouldn't remove the service_identity field just yet, so as to not break tooling that uses it while we are still transitioning to DIDs.

[ivarprudnikov]

If I understand correctly the proposed kid already exists in the receipt as a serviceId.

The way to pull all public keys at the moment is to get them through /app/parameters/historic and filter them based on serviceId in the receipt. Which as I understand will not change.

And for the iss field, the suggestion is to provide a way to configure it with fqdn which should host /.well-known/did.json. did.json should then expose all of the /app/parameters/historic keys. Is my understanding correct?

[plietar]

Yes that's correct.

In the longer term, we will probably provide a /.well-known/did.json endpoint hosted directly in the ledger, but for now that responsibility will be outside of the ledger. It is up to the operator to correctly configure the service to the externally hosted DID document.