Types as strings are duplicative of type mechanism

[msporny]

The type mechanism used in W3C VCs provide something similar to the identifierType and similar properties in this section (and others):

https://identity.foundation/credential-schemas/#identifiers-object

Arbitrary strings as types, while they might seem like a good idea, are usually not a great idea since it harms interop (if you don't know the full possibility of types, the liklihood that you end up with a failure in the ecosystem due to an unknown type is high).

Try to re-use the type mechanism provided by the serialization languages instead of creating an arbitrary string-based one.

[kimdhamilton]

@msporny clarifying question: does the fact that this is an abstract data model, where identifierType could map to that type mechanism make a difference? I'm not sure if we're talking at the same level of abstraction.

[ottomorac]

@msporny Would the "type" in the W3C VC data model that you refer to expect the usage of JSON-LD? As you can see in the diagram shared above by Kim, our "abstract data model" intends to support JSON-LD, VC-JWT and other ways of defining credential schema structures.

[msporny]

@msporny clarifying question: does the fact that this is an abstract data model, where identifierType could map to that type mechanism make a difference?

It does make a difference, but then we're just talking about complicating the abstract data model to not map one-to-one to the serializations. You're effectively creating a metamodel at that point that will serialize to other metamodels and then, finally, a serialization.

Contrast that with just using type in all the serializations and having a clear story about how the value of that field is understood (across all the serializations). If you don't do that, then you push the burden of having to know "instanceType" maps to type in JSON-LD and typ in JSON and typeInfo in (pick another random serialization format).

If you are too abstract with this stuff, and serializations can vary greatly (or at all), then you're in ISO 20022 metamodel land, where you can serialize the metamodel as /anything/ (some say that's wonderful, others say that's awful).

@msporny Would the "type" in the W3C VC data model that you refer to expect the usage of JSON-LD?

My personal answer, with all of my hats off, is "No"... but the WGs have made different decisions (mandating JSON-LD out of a fear of semantic ambiguity... which they didn't have to do, but the people that didn't understand JSON-LD (or chose not to for political reasons) insisted that VCs needed to mandate JSON-LD). We have a counter-example of that mandate in the DID Core specification.

In any case, it'll just come down to how painful you want to make all of this on developers. If you don't keep the fields the same between all the different serializations, you're asking developers to do some heavy lifting (IMHO).

Also, note that you don't have to make me happy here -- I was asked to review the spec, I was curious and reviewed and raised some issues... if you're going for a metamodel here, where the name/value pairs can change in the serialization, then that is a design decision and is a way to put this stuff together. My experience indicates that doing so requires you to have a very robust organization, industry, and set of people that keep that metamodel aligned with the serializations... and all that drives up the cost of implementation.