"final holder" may not be "final" #577
Conversation
revisiting #363 - I think this deserves changing. "Final holder" suggests that the VC cannot be passed to another holder after this one -- but that's not so. As any step in the lifecycle can recur, and the order of those steps may vary, "final" has no place in it. (I also think this is editorial, but others may have differing opinion.)
|
It could be argued that each iteration of |
index.html
Outdated
| @@ -1820,24 +1820,24 @@ <h3>Lifecycle Details</h3> | |||
| <a>verifiable credentials</a> from <a>holders</a> for its supported actions. | |||
| </li> | |||
| <li> | |||
| The <a>issuer</a> issues a <a>verifiable credential</a> to the <a>holder</a>. | |||
| The <a>issuer</a> issues some <a>verifiable credential(s)</a> to the <a>holder</a>. | |||
There was a problem hiding this comment.
The issuer issues one or more verifiable credentials to the holder.
index.html
Outdated
| </li> | ||
| <li> | ||
| The <a>holder</a> might pass on its <a>verifiable credentials</a> to another | ||
| The <a>holder</a> might pass on its <a>verifiable credential(s)</a> to another |
There was a problem hiding this comment.
The holder might pass on one or more of its verifiable credentials to another
index.html
Outdated
| <a>holder</a>. | ||
| </li> | ||
| <li> | ||
| The final <a>holder</a> presents its <a>verifiable credentials</a> to the | ||
| The <a>holder</a> presents its <a>verifiable credential(s)</a> to the |
There was a problem hiding this comment.
A holder presents one or more of its verifiable credentials to the
Note. Now that we have more than one holder we can no longer refer to "the" holder as it is ambiguous. Final holder was not ambiguous.
There was a problem hiding this comment.
"Final holder" was not ambiguous, but it implied a termination of holder-to-holder transfers was required for a holder to present a VC to a verifier, which requirement does not exist. As I noted in my earlier comment, "The" seems not to be appropriate for any of these bullets.
Changing "the" to "a" in most cases, and adjusting text to be more easily re-ordered and/or repeated, i.e., less dependent on the current ordering.
There was a problem hiding this comment.
I'm fine w/ this change. Looks like @David-Chadwick is not. Holding off on merging until @TallTed and @David-Chadwick come to an agreement on how to move this PR forward.
|
As I see it, relative to a single VC, there are a number of actions which may be taken by its single Issuer, any number of Holders (who may receive the VC from the Issuer or from a previous Holder), and any number of Verifiers (who may receive the VC from any Holder). Some of those actions are dependent on specific previous actions (e.g., until a VC is Issued, nothing else can be done; until it is Presented, it cannot be Verified); some are not. Most (possibly all) of those actions may be performed by multiple actors in the Holder and Verifier roles. Many may be repeated by the same actor. More may happen multiple times, as they are performed by multiple actors. I am thinking that these actions might be better presented in a graphical form which indicates all of the above, than in purely textual form as they currently exist. If the presentation does stay in textual form (and possibly also if it is reworked as an image), it seems to me that each action's description should include which action(s) are necessary (immediate?) prerequisites, and which action(s) may occur (immediately?) after it. |
| The final <a>holder</a> presents its <a>verifiable credentials</a> to the | ||
| <a>verifier</a> in a <a>verifiable presentation</a>, requesting a supported | ||
| A <a>holder</a> presents one or more of its <a>verifiable credential(s)</a> | ||
| to a <a>verifier</a> in a <a>verifiable presentation</a>, requesting a supported |
There was a problem hiding this comment.
This has to say optionally since VPs are optional not mandatory. Therefore change to
A holder presents one or more of its verifiable credential(s)
to a verifier, optionally in a verifiable presentation, requesting a supported
| The <a>verifier</a> <a>verifies</a> the authenticity of the | ||
| <a>verifiable presentation</a> and <a>verifiable credentials</a>. | ||
| A <a>verifier</a> <a>verifies</a> the authenticity of a <a>verifiable presentation</a> | ||
| and the <a>verifiable credential(s)</a> contained therein. | ||
| </li> |
There was a problem hiding this comment.
The previous step had a holder passing to a verifier. So this step should be talking about the same holder and the same verifier. It makes no sense to talk about any holder or any verifier since they may not have communicated with each other. You are already talking about THE verifiable credentials and not any old VCs, so you are inconsistent. Furthermore the VP is optional so may not be there to be verified. Therefore this text should read
The verifier verifies the authenticity of the presented verifiable credentials
and the verifiable presentation containing them, if present.
| The <a>verifier</a> decides whether to accept the <a>verifiable credentials</a> | ||
| for the requested action, taking into account its policy, the <a>holder</a>, | ||
| and the contents of the <a>verifiable credentials</a>. | ||
| A <a>verifier</a> decides whether to accept the <a>verifiable credentials</a> |
There was a problem hiding this comment.
Similarly this should be The verifier for the reasons stated above. (Note you are already talking about The verifiable credentials :-)
| The <a>verifier</a> either performs the requested action or rejects the | ||
| request. | ||
| A <a>verifier</a> either performs a requested action or rejects the request | ||
| for that action. |
There was a problem hiding this comment.
This is rejected for the same reason as above. The original text was correct in using definite rather than indefinate articles.
|
@David-Chadwick - I refer you to the paragraph which follows the list of actions:
In other words, there isn't really a "previous step" nor a "next step" even though this is (currently) an ordered/numbered list. Perhaps you might read my other comment and address thereby the basis of this PR, instead of focusing on details which depend on and descend from that basis? Following on my previous -- This list of actions appears to me to be generic, and thus to apply to any/all VCs. If you want to present the lifespan of a single, example VC, I think that should get distinct treatment -- perhaps in an Appendix -- in which the indefinite articles I'm suggesting for this generic list might become definite, for that specific example (say, one in which the VC is passed from Issuer to HolderA to VerifierA which permits RequestedActionA and from HolderA to HolderB to VerifierB which denies RequestedActionB)... |
|
@TallTed Saying that the order of the steps is not fixed is actually incorrect. The order of some of the steps is fixed, and some of the others is not fixed precisely but rather is approximately fixed. Some of the steps can be repeated and others not. So, you send a request and get a response. This order is fixed. You cannot get a response to a request that you have not yet issued (unless you are a time traveller). Also you must get a VC from an issuer before you can send it to the verifier. This order is fixed. So you are reading too much into the sentence you quoted and I suggest you change that sentence rather than other sentences that apply to a fixed order. |
|
I believe there is one action which cannot take place more than once per VC, that being Issuance. (Actually, I think there are two, with the other being Revocation, which I have just realized is not currently found in this lifecycle!) I believe there are several actions which depend on one or more of the others occurring first. Most obviously, all other actions on a VC depend on an Issuer having issued that VC -- and that should be step-1, rather than the current "Verifier creates Policies" (which may not belong in this lifecycle at all, as such policies are not at all tied to a VC, per se). Bottom line, this non-normative section hasn't received the attention it deserves, in part, I think, because it is non-normative. I am increasingly convinced that the simple ordered-list is the wrong presentation. Some sort of process flow diagram is making more sense to me, with clear indication of which actions may be followed by which others, including (possible) loopbacks. I am probably not the best to create such a thing, but would be happy to work with someone who has experience with the relevant tool(s). |
|
We need more opinions on this PR in order to move it forward. I can weigh in, but would prefer that others do as well. We'll bring it up in the call tomorrow. |
revisiting #363 - I think this deserves changing. "Final holder" suggests that the VC cannot be passed to another holder after this one -- but that's not so. As any step in the lifecycle can recur, and the order of those steps may vary, "final" has no place in it. (I also think this is editorial, but others may have differing opinion.)
Preview | Diff