(These comments are related to PR #44.)

Example 1

In light of #44 this makes sense, but it would need some additional comments in my view

• Draw the attention on the fact that the subject of the credential is the non-augmented bar-code data that encloses the example. That aspect is crucial and easy to gloss over.
• Some explanation on "protectedComponentIndex": "uP_BA" is needed. Emphasize that (I presume) "protectedComponentIndex" is a specific feature for AamvaDriversLicenseScannableInformation and that the value (I presume again) points at the subset of the information that is to be protected.
• Again I presume (but that should be made explicit) that the uP_BA value is meant to refer to some data to be extracted from the non-augmented bar-code data, and that this additional information is added to the original ecdsa cryptosuite; i.e., that is what makes it -xi-.

Example 2

• Like for Example 1, emphasize that the subject is the MRZ data. Emphasize that, in contrast to Example 1, the full MRZ is concerned and is added to -xi- (I presume...)
• You have a note on credential status after the example, but there is no credential status in that example. Was it meant for Example 1?

Example 3

• First of all: I believe this example should be the first. Follow the same order as the introduction, and start with the fairly obvious example in the first place.
• I do not know what "JSON-LD Diagnostic Mode" means on the QR Code tab in the example. It seems to be the original VC augmented by the signature. That should be, imho, in a separate tab. Also, in the binary tab, the application/vc content is exactly the same content, it does not add any information; should be dropped (in favor of a separate, dedicated tab)
• B.t.w. I think Example 1 and 2 should follow the same tabbing approach as Example 3. There is no reason to make them structurally different: a tab with the VC, the signed VC, the binary (ie, CBOR) data, and the QR Code itself.