Introduction text ambituity

[Nat Sakimura]

Currently, it states:

Verifiable Credentials are very similar to identity assertions, like ID Tokens in OpenID Connect, in that they allow an Issuer to assert End-User claims. However, in contrast to the identity assertions, a verifiable Credential follows a pre-defined schema (the Credential type) and is typically bound to key material allowing the End-User to prove the legitimate possession of the Credential. This allows secure direct presentation of the Credential from the End-User to the RP, without involvement of the Credential issuer. This specification caters for those differences.

Is “verifiable Credential” always associated with JSON Schema? It just says “pre-defined schema”, and it is not clear. ID Token is not a free format and has a certain schema but does not have JSON Schema so if you mean “JSON Schema” it is correct. If it means a more general schema, the sentence is false.

Also “This allows” is a bit ambiguous. It is better to spell it out as “The binding to the key allows”.

[David W Chadwick]

the text is also wrong because the pre-defined schema is not the Credential type. It is the credentialSchema property.

[Kristina Yasuda]

Not all VCs have pre-defined schema. so I would remove pre-defined schema language.

Not sure how to express that verifiable credentials having credential type is what differentiates them from identity assertions, and whether it is actually a differentiator..? The most general description I can think of that applies to both VC types and mdocs doctype/namespaces is that VCs contain set of claims that are “namespaced”. so we can say, "However, in contrast to the identity assertions, a Verifiable Credential contains a namespaces set of claims and is typically bound to a key material allowing the End-User to prove the legitimate possession of the Credential.“ ?

cc @Torsten Lodderstedt

[Kristina Yasuda]

PR #411

[Kristina Yasuda]

PR merged