Skip to content

Update Traveler Use Case #73

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.

Sign up for GitHub

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 10 commits into from
Jun 28, 2018
Merged

Update Traveler Use Case #73

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
06f536a
Update Traveler Use Case Scenario
stonematt Jun 8, 2018
42545e7
Update Background in Traveler Use Case
stonematt Jun 8, 2018
fe32ded
Update Distinction of Traveler Use Case
stonematt Jun 8, 2018
3e136bd
Update Credential List for Traveler Use Case
stonematt Jun 8, 2018
50b96cd
Reformat Trust Hierarchy in Traveler Use Case
stonematt Jun 8, 2018
a79170a
Update Trust Hierarchy in Traveler Use Case
stonematt Jun 8, 2018
bd6f87e
Add line breaks in Threat Model for Traveler
stonematt Jun 8, 2018
a68028e
Add False Parent Thread to Traveler Use Case
stonematt Jun 8, 2018
09f5f5a
Clean up miscellaneous formatting
stonematt Jun 8, 2018
a50e93d
Update Presentation in Traveler Use Case
stonematt Jun 8, 2018
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
207 changes: 120 additions & 87 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,19 +142,15 @@

<body>
<section id='abstract'>
<p>
A <em>verifiable claim</em> is a qualification, achievement, quality, or piece of
information about an <a>entity's</a> background such as a name, government ID,
payment provider, home address, or university degree.
Such a claim describes a quality or
qualities, property or properties of an entity which establish its existence and uniqueness.
The use cases outlined here are provided in order to make progress toward
possible future standardization and interoperability of both low and
high-stakes <a>claims</a> with the goals of storing, transmitting, and receiving
digitally verifiable proof of attributes such as qualifications and achievements.
The use cases in this document focus on concrete scenarios that the technology defined
by the group should address.
</p>
<p> A <em>verifiable claim</em> is a qualification, achievement, quality, or piece of
information about an <a>entity's</a> background such as a name, government ID, payment
provider, home address, or university degree. Such a claim describes a quality or qualities,
property or properties of an entity which establish its existence and uniqueness. The use cases
outlined here are provided in order to make progress toward possible future standardization and
interoperability of both low and high-stakes <a>claims</a> with the goals of storing,
transmitting, and receiving digitally verifiable proof of attributes such as qualifications and
achievements. The use cases in this document focus on concrete scenarios that the technology
defined by the group should address. </p>
</section>

<section id='sotd'>
Expand Down Expand Up @@ -203,21 +199,18 @@ <h3>Importance of this work</h3>
</section>
<section>
<h3>Use case model</h3>
<p>This document presents an aggregate use case model, comprised of Needs, Roles, Tasks,
and Sequences. Taken together, these models define the
use cases that the Verifiable Claims Working Group will address.</p>

<p>User needs define the problem space Verifiable Claims addresses. User Roles specify the
roles different entities play when interacting
with Verifiable Claims. Tasks define the functions users can accomplish and sequences
demonstrate how tasks might be realized by
interactions between entities over time.</p>
<p>As with all models, this use case model is neither exhaustive nor complete. The listed
uses cannot exhaustively capture all possible
use cases. Similarly, the models do not completely characterize the use cases represented.
However, the combined model provides specific, coherent guidance for the work ahead.</p>
<p>This document presents an aggregate use case model, comprised of Needs, Roles, Tasks,
and Sequences. Taken together, these models define the use cases that the Verifiable
Claims Working Group will address.</p>
<p>User needs define the problem space Verifiable Claims addresses. User Roles specify
the roles different entities play when interacting with Verifiable Claims. Tasks define
the functions users can accomplish and sequences demonstrate how tasks might be realized
by interactions between entities over time.</p>
<p>As with all models, this use case model is neither exhaustive nor complete. The listed
uses cannot exhaustively capture all possible use cases. Similarly, the models do not
completely characterize the use cases represented. However, the combined model provides
specific, coherent guidance for the work ahead.</p>
</section>

</section>

<section>
Expand All @@ -237,8 +230,8 @@ <h2>User roles</h2>
might be a pet who has received a vaccination. The holder of that claim is likely the pet's
owner, not the pet. A holder is typically the initiator of the transmission of a claim.</dd>
</dl>

</section>

<section>
<h2>User needs</h2>
<p>Verifiable Claims address user needs in a number of key domains:</p>
Expand Down Expand Up @@ -745,34 +738,52 @@ <h2>International Travel with minor and upgrade</h2>
<p></p>
<h3>Background</h3>
<p>Malathi is traveling internationally with her 8-month old son, Anand. His father Rajesh
is staying home. She books the plane tickets through her travel agent who adds the lap
child to the ticket. Malathi obtains permission from Rajesh stating she is allowed to take
the baby out of the country. Malathi has enough frequent flyer miles to upgrade the ticket
to first class.</p>
is staying home. Malathi has enough frequent flyer miles to upgrade the ticket to first
class.</p>
<h3>Distinction</h3>
<p>This use case is difficult because:</p>
<ul>
<li>Current US passports do not establish explicit relationship between parent and child.</li>
<li>When one parent travels with a minor, the other parent is required to grant
permission for the trip, thus implying guardianship or responsibility.</li>
<li>The DID or other Digital Identity system replaces the role of the notary in the
paper/physical world</li>
<li>Credentials must be coordinated between two verifiers (agent and airline) for two
individuals, and a digital coupon is used.</li>
<li>Permission for one parent to fly with the child and without the other parent must be
established.</li>
<li>In the Minor's case, the subject != holder. The holder(s) of the passport are parents, not the minor.</li>
<li>The relationship of the minor to the non-traveling parent must be established, in
order for the permission to be considered.</li>
<li>In the minor's passport case, the subject is not the holder of the Verifiable
Credential. The holder(s) of the passport are parents, not the minor.</li>
</ul>
<h3>Scenario</h3>
<p>HappyAir must verify that Malathi is Anand’s guardian and that she is legally allowed to
exit the country with him and without his other parent.</p>
<p>Malathi obtains permission from Rajesh stating she is allowed to take the baby out of
the country.</p>
<p>Prior to booking the trips Malathi visits HappyAir.com to requests an upgrade to first
class. HappyAir issues a Verifiable Credential redeemable for a first class upgrade on an
international flight.</p>
<p>She books the plane tickets through her travel agent who adds the lap child to the ticket.</p>
<p>HappyAir verifies that Malathi has a signed statement from Anand’s other parent stating
that she may exit the country with him</p>
<h3>Verifiable Credentials</h3>
<dl class="dl-horizontal">
<dt>Traveling Parent passport</dt>
<dt>Malathi's passport</dt>
<dd>Establishes identity of the traveling parent</dd>

<dt>Minor passport</dt>
<dt>Anand's passport</dt>
<dd>Establishes identity of the minor</dd>

<dt>Permission from non-traveling parent </dt>
<dt>Anand's Birth Certificate</dt>
<dd>Establishes relationship to parents and provides link from Rajesh to Anand that
qualifies the permission to travel </dd>

<dt>Permission to travel from Rajesh </dt>
<dd>
<ul>
<li>Grants permission from non-traveling parent for minor to travel.</li>
<li>Identity matches identity of the parent in the birth certificate, establishing
relevance.</li>
</ul>
<p class="issue">This is content from the prior discussion - remove the following points?</p>
<ul>
<li>Parents are the holders of the passport credential</li>
<li>Parents must present the passport credential</li>
Expand All @@ -782,87 +793,109 @@ <h3>Verifiable Credentials</h3>
</ul>
</dd>

<dt>Coupon for upgrading ticket to first class</dt>
<dt>Upgrade coupon for first class ticket</dt>
<dd>Introduces commercial value in a verifiable credential </dd>
</dl>

<h3>Verifiable Presentation</h3>
<p>Submitted to HappyAir, includes assertion of permission and Frequent Flyer coupon. </p>
<p>Submitted to HappyAir, includes passport, assertion of permission, birth certificate and
Frequent Flyer coupon. </p>

<h3>Trust Hierarchy</h3>
<ul>
<li>Malathi is liable for her claim of parentage as well as securing right to admission
for herself and her son at their destination (visa may be required). </li> <li>Malathi
and Rajesh are both liable for attestation of permission to fly with Anand without the
other parent. </li> <li>Malathi is liable for the cost of her ticket and her son’s
ticket. </li> <li>The agency is liable for issuing valid tickets and for verifying the
credentials provided by the travelers. </li> <li>The airline is liable for issuing
tickets and, ultimately, fulfilling the terms of travel [does the airline issue tickets
or do the agents?]. </li> <li>The airline is liable for accepting the upgrade coupons at
ticketing. </li> <li>The check-in agent, TSA agent, and passport control at the
destination are liable for identity assurance at various points of travel, using
information contained in the verifiable credentials.</li>
for herself and her son at their destination (visa may be required).</li>
<li>Malathi and Rajesh are both liable for attestation of permission to fly with Anand
without the other parent.</li>
<li>Malathi is liable for the cost of her ticket and her son’s ticket.</li>
<li>The agency is liable for issuing valid tickets and for verifying the credentials
provided by the travelers.</li>
<li>The airline is liable for issuing tickets and, ultimately, fulfilling the terms of
travel <span class="issue">[does the airline issue tickets or do the agents?].</span></li>
<li>The airline is liable for accepting the upgrade coupons at ticketing.</li>
<li>The airline is liable for verifying the credentials in the birth certificate match
the credentials in the permission letter.</li>
<li>The check-in agent, TSA agent, and passport control at the destination are liable for
identity assurance at various points of travel, using information contained in the
verifiable credentials.</li>
</ul>

<h3>Threat model</h3>
<ol>
<li><strong>Threat: Stolen Key.</strong> Malathi steals Rajesh’s key in order to fake travel permission. (Kidnapping
her own kids and fleeing Rajesh.) </li>
<li><strong>Threat: Stolen Key.</strong> Malathi steals Rajesh’s key in order to fake
travel permission. (Kidnapping her own kids and fleeing Rajesh.) </li>
<ul>
<li><strong>Response:</strong> Rajesh could store his key with a trusted third party, such as an attorney.</li>
<li><strong>Response:</strong> Rajesh could store his key with a trusted third party,
such as an attorney.</li>
<li><strong>Response:</strong> Rajesh could use a hardware wallet with pin or biometric.</li>
<li><strong>Response:</strong> Rajesh could use a passphrase on his key </li>
</ul>
</ul>
<li><strong>Threat: <span class="issue">Stolen Key 2</span></strong> Ticket purchaser has Malathi’s credentials, impersonating her to purchase a ticket.
This could enable a third party kidnapping.</li>
<li><strong>Threat: <span class="issue">Stolen Key 2</span></strong> Ticket purchaser has
Malathi’s credentials, impersonating her to purchase a ticket. This could enable a third
party kidnapping.</li>
<ul>
<li><strong>Response:</strong> Travel permission can be restricted to specific date and or trip minimizing
abuse potential.</li>
<li><strong>Response:</strong> Embed identifying characteristics or biometric into the credentials so that
verifiers can independently verify the subject in front of them is the subject in the credential.</li>
<li><strong>Response:</strong> Malathi could use a hardware wallet with pin or biometric.</li>
<li><strong>Response:</strong> Travel permission can be restricted to specific date
and or trip minimizing abuse potential.</li>
<li><strong>Response:</strong> Embed identifying characteristics or biometric into
the credentials so that verifiers can independently verify the subject in front of
them is the subject in the credential.</li>
<li><strong>Response:</strong> Malathi could use a hardware wallet with pin or
biometric.</li>
<li><strong>Response:</strong> Malathi could use a passphrase on her key </li>
</ul>
<li><strong>Threat: Impersonating traveler.</strong> Handled by identity assurance, using
information within the credentials </li>
<ul>
<li><strong>Response:</strong> Identity assurance based on the presentation and other data,
above and beyond what is in the presentation and the claims.</li>
<li><strong>Response:</strong> Identity assurance based on the contents of the claims,
potentially with enhanced data embedded in the claims, i.e., data not currently in
passports, birth certificates, or marriage license. For example, a biometric template
could be embedded in the birth certificate claim and that template could be used for
interactive identity assurance at the time of submitting the presentation.</li>
<li><strong>Response:</strong> Identity assurance based on the presentation and other
data, above and beyond what is in the presentation and the claims.</li>
<li><strong>Response:</strong> Identity assurance based on the contents of the
claims, potentially with enhanced data embedded in the claims, i.e., data not
currently in passports, birth certificates, or marriage license. For example, a
biometric template could be embedded in the birth certificate claim and that template
could be used for interactive identity assurance at the time of submitting the
presentation.</li>
</ul>
<li><strong>Threat: False Parent</strong> Someone other than than Rajesh, e.g., Fred,
signs the travel permission with a valid key, allowing Malathi to travel without Rajesh’s
permission.</li>
<ul>
<li><strong>Response:</strong> Fred’s actions are fraudulent. Captured in the signed
statement, it would provide evidence for prosecution.</li>
<li><strong>Response:</strong> Fred’s credentials won’t match those in Anand’s birth
certificate. By comparing the credentials, HappyAir can prevent this attack</li>
</ul>
<li><strong>Threat: Exposure of private information.</strong> By storing potentially compromising information in
credentials and sending them over the network, we are increasing the attack surface for the subjects of those
credentials.</li>
<li><strong>Threat: Exposure of private information.</strong> By storing potentially
compromising information in credentials and sending them over the network, we are
increasing the attack surface for the subjects of those credentials.</li>
<ul>
<li><strong>Response:</strong> Encrypt the claims (once by issuer, every verifier gets the same encrypted
blob)</li>
<li><strong>Response:</strong> Encrypt the claims uniquely for each verifier. This may leak usage data to the
issuer, assuming the Holder must ask for a new, encrypted credential for each Verifier.</li>
<li><strong>Response:</strong> Encrypt the claims (once by issuer, every verifier
gets the same encrypted blob)</li>
<li><strong>Response:</strong> Encrypt the claims uniquely for each verifier. This
may leak usage data to the issuer, assuming the Holder must ask for a new, encrypted
credential for each Verifier.</li>
<li><strong>Response:</strong> Blind the claims uniquely for each verifier.</li>
<li><strong>Response:</strong> Encrypt the presentation uniquely for each verifier. No issuer involved</li>
<li><strong>Response:</strong> Encrypt the presentation uniquely for each verifier.
No issuer involved</li>
</ul>
<li><strong>Threat: Stolen coupon</strong> Rajesh falsifies the upgrade coupon.</li>
<ul>
<li><strong>Response:</strong> HappyAir signs the coupon with secure credentials.</li>
<li><strong>Response:</strong> Travel agent verifies the coupon through a distributed status registry,
verifying it is still valid</li>
<li><strong>Response:</strong> HappyAir signs the coupon with secure
credentials.</li>
<li><strong>Response:</strong> Travel agent verifies the coupon through a
distributed status registry, verifying it is still valid</li>
</ul>
</ol>
</section>
</section>
<section >
<!-- Editor - @halindrome -->
<h2>User sequences</h2>
<p>The transaction examples in this section show basic ways in which Verifiable Claims
might be used. They are not meant to be architecturally constraining. Instead,
they are meant to help illustrate the basic way it <em>could</em> be done in a
typical commerce situation.
Again - please remember that it is just an
example, and should not be thought of as the canonical way such
a claims environment must be implemented.</p>
<p>The transaction examples in this section show basic ways in which Verifiable Claims might be
used. They are not meant to be architecturally constraining. Instead, they are meant to help
illustrate the basic way it <em>could</em> be done in a typical commerce situation. Again -
please remember that it is just an example, and should not be thought of as the canonical way
such a claims environment must be implemented.</p>
<section>
<h2>How a verifiable claim might be created</h2>
<p>In this first example, a user will request a Verifiable Claim - a
Expand Down