Update existing Rich Schema RFCs; Propose RFCs for Rich Schema's Mapping and CredDef

[ashcherbakov]

• Update existing Rich Schema RFCs according to the Rich Schema Common RFC;
• Propose RFCs for Rich Schema's Mapping and CredDef according to the Rich Schema Common RFC

[ashcherbakov]

@dhh1128 @brentzundel Can you please review?

[kdenhartog]

I'm curious to understand this a bit better. Does this mean that all contexts necessary to build and map a rich schema must be on the same ledger? Would this hold true for the use of schemas that are anchored in IPFS that sit alongside an IPFS implementation. If this is true, then does that mean that different implementations of sidetree could reuse contexts from "different registries"?

While I understand this question is a bit futuristic sounding, the main reason I ask is because it makes sense to design in a way that aligns with securekey's architecture which using sidetree with Fabric. For rich schemas, they wouldn't necessarily have to anchor them using the batch files in sidetree, and instead could use IPFS for this functionality.

[ashcherbakov]

We have this assumption in Indy, where we assume all Schemas and corresponding Contexts should be on the same Ledger. BTW this assumption in Indy may be for the first MVP implementation of Rich Schema feature only.

As for the Aries side, I think I will remove this assumption.

[kdenhartog]

How will it be known if it's a JSON vs JSON-LD object? For example, if the context is anchored in JSON-LD form, then it's acceptable that the context is IRIs that are expanded by the document loader. In the case of a JSON consumer though, I'm not certain how they would receive the necessary detail to handle processing of an IRI. Could we provide additional details on this?

[ashcherbakov]

Any Rich Schema (which is a JSON-LD object) may reference Contexts by their id. The Context's content can be used then for substituting the attributes with IRIs within the Rich Schema object.

The question is whether the Context's content itself must be a JSON-LD as well.
As I can see from https://json-ld.org/spec/latest/json-ld/#the-context, it's not.
And as I can see from the example of Contexts that we have (@brentzundel can correct me if I'm wrong), the only requirement for the Context's format is to have a @context property containing a map of terms to IRIs. A Context may not have @id and @type properties expecting from any JSON_LD object.

[brentzundel]

My understanding of the @context objects is that simple ones are JSON objects, but there may be more advanced options that require JSON-LD.
It may be a moot question though, because the object that has a @context is a JSON-LD object and and processing that object will include dealing with the @context. I think its safe to assume that a JSON-LD processor will know how to deal with @context objects.

[kdenhartog]

Ahh good points. Thanks for the clarifications

[kdenhartog]

Just a few questions from me at this point

[dhh1128]

I'm cheerful about merging this, if others are.

[kdenhartog]

I'm cheerful about merging this, if others are.

Yup looks fine from my perspective.

[dhh1128]

The questions that Kyle asked have been resolved to his satisfaction. My own review is that this looks like a reasonable improvement. I recommend that we merge.