Added detailed lifecycle diagram and revised explanatory text details

[ken-ebert]

This replaces PR #577 . I have added a diagram and simplified the text to reflect the lack of implied ordering of actions.

---

Preview | Diff

[msporny]

Looks like a misplaced section tag is creating issues in the markup. Other than that, agree w/ the text... can't view the SVG file until I merge the PR in.

[TallTed]

Several minor tweaks to the text. I wish the SVG were visible in the preview. If it's as we drafted over the weekend, I'm probably fine with it ... but I must reserve final judgement.

[ken-ebert]

@TallTed

Several minor tweaks to the text. I wish the SVG were visible in the preview. If it's as we drafted over the weekend, I'm probably fine with it ... but I must reserve final judgement.

I made some small adjustments in the same graphic file I shared with you previously. Again, I welcome your feedback. The link is below.

@msporny Anyone should be able to view the diagram at this link:
https://docs.google.com/drawings/d/1kOMAWPFVvN6LwwTJP-Mqx0xZtVY3ozoBk5MXYEnllCM/edit?usp=sharing

[David-Chadwick]

Nice diagram. My only slight worry is that this presents the picture that VCs are designed to be swapped between holders multiple times, back and forth, without restriction, when in practice this is not going to be the case. Most physical VCs today are issued to the subject and kept by the subject. And work in ISO on electronic IDs and driving licenses is ensuring that the subject does not pass his/her VC onto another holder.

[TallTed]

I think restriction of holder-to-holder handoffs is a protocol question. Checking whether the holder is "permitted" to be the presenter seems a verifier policy question. Such handoffs may and will happen, so the model must allow for it. I don't think anything in the current diagram indicates that such handoffs are necessary, only possible.

[David-Chadwick]

I have a number of changes to suggest to this text as follows.

1. Issuance must occur before any other actions involving this credential can occur. >
   Issuance always occurs before any other actions involving this credential.

2. A holder presents one or more of its verifiable credentials to a verifier in a verifiable presentation. >
   A holder presents one or more of its verifiable credentials to a verifier, optionally inside a verifiable presentation.

3. This should include checking the credential status for revocation of verifiable credentials. >
   This should include checking the credential status for revocation of the verifiable credentials.

4. Verification occurs some time after a verifiable presentation. > null (i.e. delete)

5. The simplest useful sequence of actions envisioned would be issue, present, and verify. >
   The most common sequence of actions are envisioned to be: issuer issues to subject, subject presents to verifier, and verifier verifies.

[ken-ebert]

@David-Chadwick Do you have a suggested specific change to the diagram that I could make to communicate the exceptional rather than ordinary nature of transfers?

Your text suggestions look good. I will make the changes.

[David-Chadwick]

If I were to change the diagram I would delete the top set of holders and turn the double headed arrow that points to them into a 3/4 circle arrow that points to holders underneath the top holder in the centre of the diagram.

[ken-ebert]

Thank you @David-Chadwick for your suggested improvements to the text and diagram. I have revised the text and diagram to reflect your suggestions.

The updated diagram is located at the same link for review prior to the pull request being merged.: https://docs.google.com/drawings/d/1kOMAWPFVvN6LwwTJP-Mqx0xZtVY3ozoBk5MXYEnllCM/[email protected]&ts=5cd5b33d&actionButton=1

[TallTed]

I've made several further changes to the diagram, and suggested several minor text tweaks. I think we're close, if not there, with these.

[ken-ebert]

Thanks, Ted for your detailed review and suggestions. I think the diagram changes add clarity to the status check and the number of times actions can occur.