Prefer Arrays and Objects. about vc-data-model

[brianorwhatever]

@gobengo issuer in data integrity is "better" than jwt iss as it can be extended as an object whereas iss is always a string. He thinks the example should be

"issuer": {
  "id": "https://university.example/issuers/565049"
}

as it shows off it can be extended.

I tend to agree adding code for finding the issuer did has always bothered me.

I think issuer should always be an object with an id

[OR13]

It is recommended that roles be expressed with objects instead of strings.

objects are easily extended, strings are not.

graph nodes are a major part of the value of the spec, graph node id's hide that value.

switching types will cause higher burden in safer languages like go and rust.

It is recommended that types be expressed with arrays instead of strings.

arrays are easily extended, strings are not.

switching types will cause higher burden in safer languages like go and rust.

• these recommendations will make the VCs have more bytes (e.g. compared to JWTs with iss and string value), so these recommendations shouldn't be used later as part of any argument about which VC serialization costs more bytes/processing time.

I don't need to use bytes to make that argument, I actually encountered this issue first using JSON Pointers with ecdsa-sd.

consider the following:

"/issuer/id",

"/issuer",

The shape of the JSON changing causes extra burden to all algorithms that process the data model.

You will find extra logic checking for string, array, object everywhere polymorphism is encouraged.

There will be more bugs.

JSON shape is not the primary performance issue with the spec anyway, its "sign and verify time" when you do canonicalization / media type conversion... instead of just signing bytes.

https://transmute-industries.github.io/vc-jwt-sd/

[gobengo]

Seems reasonable. Caveats:

• If possible it is nice to have a rationale with any recommendations, both to help noobs understand why they were recommended in the average case while also helping advanced users understand why/when it may be appropriate to deviate from the recommendations
  • @OR13 since you filed the issue proposing these recommendations, would you be willing to include your rationale for recommending them?
• these recommendations will make the VCs have more bytes (e.g. compared to JWTs with iss and string value), so these recommendations shouldn't be used later as part of any argument about which VC serialization costs more bytes/processing time.

[dmitrizagidulin]

@gobengo

• @OR13 since you filed the issue proposing these recommendations, would you be willing to include your rationale for recommending them?

I think @OR13's point is more -- it would make developers' lives easier if we picked ANY combination, and enforced it (via json schema, etc). The individual choices matter less, if devs don't have to constantly be like "if this field is a string, do this, if it's an array, do this" etc.

👍 to this issue, @OR13. I don't know if we have time for this change, CR-wise, but I think it would be better for the spec.

[gobengo]

I'm +1 on all of the above too because I've also had to write tedious code to check for the polymorphism. Because of that I tend to follow the above recommendations anyway, but have at least once had a reviewer balk at { "type": ["VerifiableCredential"] }.

Thanks @OR13 for elaborating on the rationale, which includes some reasons I hadn't thought of.

One reason I asked is I didn't understand what this meant

This is missing an opportunity to show why issuer is "better" than iss