Mode of operation #291
Mode of operation #291
Conversation
Rebasing (I hope!)
update my fork
Update my copy
index.html
Outdated
|
|
||
| <p> | ||
| Section <a href="#Ecosystem Overview"></a> provided an overview of the verifiable | ||
| credential eco-system. A more detailed look at the way the eco-system is envisaged |
index.html
Outdated
| <em>This section is non-normative.</em> | ||
|
|
||
| <p> | ||
| Section <a href="#Ecosystem Overview"></a> provided an overview of the verifiable |
There was a problem hiding this comment.
"#Ecosystem Overview" -> "#ecosystem-overview"
index.html
Outdated
| </p> | ||
|
|
||
| <p> | ||
| Note that the following ordering of steps is not fixed and each step may be repeated |
index.html
Outdated
| and verifiable credentials. | ||
| </li> | ||
| <li> | ||
| Step 6. The verifier verifies the right of the holder to posses the verifiable |
There was a problem hiding this comment.
"right" seems to be a bit strong here, but don't know what to change it to.
There was a problem hiding this comment.
changed it to
The verifier verifies that the holder may posses the verifiable
credentials.
There was a problem hiding this comment.
Perhaps it should say "Is authorized to possess"? "May possess" doesn't seem clear. Perhaps even "is authorized to present" would be better. Even that doesn't seem quite right -- it's not up to the verifier to make that determination. The verifier simply controls how it reacts to the use of the credential. So really, maybe this should be something like "The verifier verifies that the presentation of the credentials by the holder is acceptable for its intended purpose."
There was a problem hiding this comment.
"The verifier verifies that the presentation of the credentials by the holder is acceptable for its intended purpose."
Yes, this.
There was a problem hiding this comment.
"its intended purpose" is ambiguous. Is this the purpose of the verifier or the purpose of the issuer, or the purpose of the subject etc. Furthermore, the next step (7) checks what you are proposing. All step 6 is checking is if step 3 took place or not, and if it did, if it conforms to the standard.
How about "The verifier verifies that the holder may posses the verifiable credentials in conformance to the standard."
Rationale: We are testing whether the verifier conforms to the standard or not, not whether the verifier wishes to accept a VC or not. A verifier can accept all VCs and all VPs, even ones that have expired and that have been revoked.
index.html
Outdated
| </li> | ||
| <li> | ||
| Step 7. The verifier determines whether to accept the verifiable credentials for | ||
| the requested action, taking into account its policy, the holder and the contents |
There was a problem hiding this comment.
Add oxford comma after "the holder"
| 2, 3, 4, 5 and 6. | ||
| </li> | ||
| <li> | ||
| This verifiable credentials specification is not sufficient on its own for |
There was a problem hiding this comment.
We will want to call out that those steps are typically defined by authorization frameworks.
There was a problem hiding this comment.
Changed to
This verifiable credentials specification is not sufficient on its own for
steps 1, 7, and 8 as an authorisation framework will be needed as well.
index.html
Outdated
| </ul> | ||
|
|
||
| <p> | ||
| In particular, Section <a href="#Terms of Use"></a> and Section |
There was a problem hiding this comment.
"#Terms of Use" -> "#terms-of-use"
index.html
Outdated
|
|
||
| <p> | ||
| In particular, Section <a href="#Terms of Use"></a> and Section | ||
| <a href="#Subject-Holder Relationships"></a> specify how a verifier can |
There was a problem hiding this comment.
"#Subject-Holder Relationships" -> "#subject-holder-relationships"
index.html
Outdated
| determine whether: | ||
| </p> | ||
| <p> | ||
| - the holder is the subject of a verifiable credential, |
There was a problem hiding this comment.
These should be a bulleted list <ul><li>...</li></ul>
|
@David-Chadwick in issue #252 you made the statement that "the DM model is 100% responsible for step 3". How is that the case? |
|
@burnburn . If you read section 1.2, Ecosystem Overview you will see that it describes how VCs are issued, passed to the holder and from there to the verifier. The ecosystem forms part of the data model, it is the context of use, otherwise it would not be described informally in the standard. This is why I said it was a DM issue (perhaps more correctly I should have said it is an ecosystem issue, and the ecosystem is supported by, or is part of, the overall DM - for example, this is why a VC contains an issuer field). Now the verifier has no knowledge about the actual issuing process, as it took place independently of, and before, the holder passed the VC to the verifier. The verifier does not know if the holder was the original holder or a subsequent holder, unless there are some properties in the DM that tell the verifier this. Furthermore, if the holder is a subsequent holder, is he/she a thief or was the VC passed on with the full knowledge and agreement of the original holder. Again the DM can inform the verifier about this, independently of the protocol that is used i.e. this is not a protocol issue, but an ecosystem issue, and the DM supports the ecosystem. |
A new section outlining the 8 steps in the VC ecosystem
Preview | Diff