search

THCLab / oca-ecosystem

European Union Public License 1.2
3 stars 0 forks source link

Is there a suggested approach to signing an OCA Bundle for publishing #8

Closed swcurran closed 2 years ago

swcurran commented 2 years ago

We have a requirement that an OCA Bundle be signed by the publisher. In our case, the publishers will use a public DID to sign the OCA Bundle as the publish it. Is there any plan to include signing an OCA Bundle as being in the scope of the spec. If not, any suggestions on how to do that in a useful way? It would be really nice to retrieve a bundle that includes a signature in a standard way, so that the processing of the Bundle can include verification of the signature.

We will come up with a way to do that for our use case (e.g. for use by at least Hyperledger Aries frameworks), but I think the requirement is more broadly applicable.

mitfik commented 2 years ago

Deliberately signing procedure is not part of the OCA spec and probably it would stay that way. This allows us to split data integrity layer from data authenticity.

The signing part (authentication) is taking on the level of credential issued by Governance who want's to assure about specific OCA bundle within their ecosystem. How we are recommending to do it is to construct Verifiable Credential/ACDC where OCA bundle SAID is included.

Technically speaking OCA repository provides OCA Bundles + ACDC which can be requested via signal API call. On the client side you can then verify integrity of the OCA Bundle checking SAID and authentication of the bundle verifying ACDC.

Feel free to reopen that issue if something would not be clear or would need more explanation.

Soon (~4 weeks) we would publish (and I will update that issue to reflect that) exact description how such scenario can be implemented with technical and governance details. The information would be available at https://oca.colossi.network/.

swcurran commented 2 years ago

Agree that the signing is should be independent of OCA, but was interested in any ideas you have on using it.

Likewise, I think the combining of verifiable credentials/ACDC with OCA is also unwise. Is fine as a separate component that is useful in the context of others using ACDC, but not as a core part of the OCA standard.

For us, an "OCA Bundle" will just be JSON that we retrieve, from what amounts to a file server. What we want to figure out is how to providing a binding of the publication of the OCA Bundle to a specific identity, which for us is most likely a DID. That in turn implies a signature that can be verified by retrieving a known DID to get the signing public key for the verification.

As such, we mostly care about the standardization of the OCA contents -- what core overlays exist, exactly how are they used, how do publish a new overlay type that may (or may not) become a core overlay.