Skip to content

Mode of operation #291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Dec 4, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1497,6 +1497,95 @@ <h2>Refreshing</h2>

</section>

<section>
<h2> Mode of Operation</h2>

<em>This section is non-normative.</em>

<p>
Section <a href="#ecosystem-overview"></a> provided an overview of the verifiable
credential ecosystem. A more detailed look at the way the eco-system is envisaged
to operate is as follows.
</p>

<p>
Note that the following ordering of steps is not fixed and some steps may be repeated
multiple times.
</p>

<ul style="list-style-type:none">
<li>
Step 1. The verifier defines its policies for accepting verifiable credentials
from holders for its supported actions.
</li>
<li>
Step 2. The issuer issues a verifiable credential to the holder.
</li>
<li>
Step 3. The holder MAY pass on its verifiable credentials to another holder.
</li>
<li>
Step 4. The final holder presents its verifiable credentials to the verifier in
a verifiable presentation, requesting a supported action.
</li>
<li>
Step 5. The verifier verifies the authenticity of the verifiable presentation
and verifiable credentials.
</li>
<li>
Step 6. The verifier verifies that the holder may posses the verifiable
credentials.
</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
of the verifiable credentials.
</li>
<li>
Step 8. The verifier either performs the requested action or rejects the request.
</li>
</ul>

<p>
This specification does not define any protocol for the transfer
of verifiable credentials or verifiable presentations, but assuming that other
specifications do specify how they are transferred between the various entities, then:
</p>

<ul>
<li>
This verifiable credentials specification is directly applicable to steps
2, 3, 4, 5 and 6.
</li>
<li>
This verifiable credentials specification is not sufficient on its own for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will want to call out that those steps are typically defined by authorization frameworks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

steps 1, 7, and 8 as an authorisation framework will be needed as well.
</li>
</ul>

<p>
In particular, Section <a href="#terms-of-use"></a> and Section
<a href="#subject-holder-relationships"></a> specify how a verifier can
determine whether:
</p>
<ul>
<li>
the holder is the subject of a verifiable credential,
</li>
<li>
the relationship between the subject and the holder,
</li>
<li>
the original holder passed a verifiable credential to a subsequent holder,
</li>
<li>
any restrictions on the use of the verifiable credentials by the holder and/or verifier.
</li>
</ul>


</section>

<section>
<h2>Terms of Use</h2>

Expand Down