Fix KCC schema link, comments

[tomdaffurn]

• Fix link to KCC schema after directory move
• Clarify KCC schema is an example only, not a prescriptive part of the spec
• Correct VC Data Model to version 1.1

[KendallWeihe]

What am I misunderstanding here... isn't the whole point with the schema is that it's normative to a Known Customer Credential? It's not intending to be a JSON Schema for all VC Data Model instances, which is to say a normative schema for VC's, but it is intending to be normative for KCCs specifically.

[decentralgabe]

I missed this. I agree @KendallWeihe, the schema should be normative.

[decentralgabe]

The schema needs to be a part of the spec.

[tomdaffurn]

The schema needs to be a part of the spec.

Curious why you think this @decentralgabe?

The KCC spec can be used to issue any number of VCs, so making hard requirements about schema will limit what it can be used for. In previous comments (#22) you've suggested to generalise this spec and entirely decouple it from KCC.

I see the KCC and KBC schema living here for a short time until a schema registry is available.

[decentralgabe]

@tomdaffurn

The KCC spec can be used to issue any number of VCs, so making hard requirements about schema will limit what it can be used for.

Where are these VCs enumerated? I am fine with moving the schema, as long as we have a clear pointer to where the types of K** credentials are defined along with guidance on issuing and verifying these credentials.

In previous comments (#22) you've suggested to generalise this spec and entirely decouple it from KCC.

I still think this is right, but I do not think we can make this change until #22 has taken effect.

I see the KCC and KBC schema living here for a short time until a schema registry is available.

A schema registry alone is insufficient. We still need a place to define the processing rules around the credentials. Like, what constitutes a valid KCC? How should it be verified? Who is able to issue one? How can it be interrogated for trustworthiness?

Concretely, I believe we should do a few things

1. Split this spec into a generic issuance and verification spec (similar to Change this to be a generic 'credential issuance' spec #22).
2. Add either a new repo or sub-directories in this repo that speak to the issuance and verification considerations around specific credential types, along with data schemas.
3. Also have a schema registry where the data schemas defined by (2) are mirrored.

^^^ let's hash out the path forward there before removing the KCC schema