Patient with Lab and Referral Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
(Created page with "==Full Title of Use Case== Over 21 with Proof of Presence Token ==Purpose== To provide reasonably high assurance that a claim of majority is valid for acquiring restricted re...")
 
No edit summary
Line 2: Line 2:
Over 21 with Proof of Presence Token
Over 21 with Proof of Presence Token


==Purpose==
==Context==
To provide reasonably high assurance that a claim of majority is valid for acquiring restricted resources.
To provide reasonably high assurance that a claim of majority is valid for acquiring restricted resources.


==Goal and Actors==
===Goal===
To allow online purchases of legally restricted resources like alcoholic beverages in an environment where user identity attributes are distributed among many providers.
To allow online purchases of legally restricted resources like alcoholic beverages in an environment where user identity attributes are distributed among many providers.
 
===Actors:
Actor: Consumer of restricted resources.
#Actor: Consumer of restricted resources.
Actor: Supplier of restricted resources.
#Actor: Supplier of restricted resources.
Actor: Verifier of claim of majority (also can validate binding to subject)
#Actor: Verifier of claim of majority (also can validate binding to subject)
Actor: Provider(s) of late binding tokens and client-side code
#Actor: Provider(s) of late binding tokens and client-side code


==Preconditions==
==Preconditions==
The Consumer has acquired a late binding token from any provider at all.
*The Consumer has acquired a late binding token from any provider at all.
The Consumer has registered an over-21 claim with verifier using token.
*The Consumer has registered an over-21 claim with verifier using token.
The Consumer has established an account with supplier using a DID or other persistent ID.
*The Consumer has established an account with supplier using a DID or other persistent ID.


==Scenarios==
==Scenarios==
Scenario: Consumer signs into supplier and has never purchased liquor from this site.
Scenario: Consumer signs into supplier and has never purchased liquor from this site.
Consumer selects to purchase liquor item
#Consumer selects to purchase liquor item
Supplier asks user for over 21 proof with a nonce.
#Supplier asks user for over 21 proof with a nonce.
Consumer sends verifiable claim of over 21 they acquired from verifier.
#Consumer sends verifiable claim of over 21 they acquired from verifier.
Supplier asks verifier for proof. (This would be by redirect to verifier through user browser)
#Supplier asks verifier for proof. (This would be by redirect to verifier through user browser)
Verifier supplies validated claim (or statement of non-revocation) bound to nonce by redirect to Supplier, if this VC is bound to the user’s session with supplier, it can have a lifetime of the duration of bound session.
##Verifier supplies validated claim (or statement of non-revocation) bound to nonce by redirect to Supplier, if this VC is bound to the user’s session with supplier, it can have a lifetime of the duration of bound session.
Monetization is by direct micro payment (on the order of $.05) from supplier to verifier.
#Monetization is by direct micro payment (on the order of $.05) from supplier to verifier.




Alternative Paths:
Alternative Paths:
Consumer selects to purchase liquor item.
#Consumer selects to purchase liquor item.
Supplier asks user for over 21 proof with a nonce.
#Supplier asks user for over 21 proof with a nonce.
Consumer asks verifier directly for proof with nonce from Supplier.
#Consumer asks verifier directly for proof with nonce from Supplier.
Verifier asks consumer to enter token for proof of presence.
#Verifier asks consumer to enter token for proof of presence.
Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
#Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
Consumer sends verified claim to supplier.
#Consumer sends verified claim to supplier.
Monetization is by advertising from verifier to consumer.
#Monetization is by advertising from verifier to consumer.


A different path using biometrics:
A different path using biometrics:


Yoti, a London-based startup which wants to become the “world’s trusted identity platform”, is one of many attempts to provide such a service. Its system stores government id documents and biometrics. If a user wants to buy a bottle of wine at a supermarket self-check-out and needs to prove their age, they scan a qr code and take a selfie using Yoti’s app. The retailer can be sure of their age, but no one has seen their name or nationality. From the Financial Times.
#Yoti, a London-based startup which wants to become the “world’s trusted identity platform”, is one of many attempts to provide such a service. Its system stores government id documents and biometrics. If a user wants to buy a bottle of wine at a supermarket self-check-out and needs to prove their age, they scan a qr code and take a selfie using Yoti’s app. The retailer can be sure of their age, but no one has seen their name or nationality. From the Financial Times.


Failed Paths:
Failed Paths:
User does not get verified claim for some reason.
#User does not get verified claim for some reason.
Verified claims fails validation at supplier.
#Verified claims fails validation at supplier.


==Results==
==Results==
Accepted Risks:
Accepted Risks:
The consumer is not over-21 and has buddy’s token to enter into computer.
#The consumer is not over-21 and has buddy’s token to enter into computer.
Session hijacking mitigated with HTTPS and session cookies.
#Session hijacking mitigated with HTTPS and session cookies.
MitM attacks mitigated by hardware token bound to origin URL of verifier.
#MitM attacks mitigated by hardware token bound to origin URL of verifier.
Note that the late binding token could be bound to supplier as well as needed.
#Note that the late binding token could be bound to supplier as well as needed.
The identity of the verifier/validator is discoverable by the supplier.
#The identity of the verifier/validator is discoverable by the supplier.
User makes choices on which attributes are trusted for sharing with the supplier.
#User makes choices on which attributes are trusted for sharing with the supplier.


Post Condition:
Post Condition:
If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
#If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
Note that at the end of the process of validating the user’s age, the state issued license to sell alcoholic beverages will determine which path to use. The penalty for the supplier using the wrong path is loss of the license to sell alcohol.
#Note that at the end of the process of validating the user’s age, the state issued license to sell alcoholic beverages will determine which path to use. The penalty for the supplier using the wrong path is loss of the license to sell alcohol.


Examples:
Examples:
Late binding token - FIDO U2F token, TEE  TPM VSC, etc.
#Late binding token - FIDO U2F token, TEE  TPM VSC, etc.
Client side code - javascript in a browser, native app, etc.
#Client side code - javascript in a browser, native app, etc.


Dependencies::
Dependencies::
Web Sites must be trusted before any user information is released.
#Web Sites must be trusted before any user information is released.
Trust federations can be used to help users make informed decisions.
#Trust federations can be used to help users make informed decisions.
User consent and trust must begin with no user information transferred.
#User consent and trust must begin with no user information transferred.
Standards exist to collect needed attributes where-ever they may be.
#Standards exist to collect needed attributes where-ever they may be.


==Workflow Diagram==
==Workflow Diagram==

Revision as of 20:21, 1 February 2019

Full Title of Use Case

Over 21 with Proof of Presence Token

Context

To provide reasonably high assurance that a claim of majority is valid for acquiring restricted resources.

Goal

To allow online purchases of legally restricted resources like alcoholic beverages in an environment where user identity attributes are distributed among many providers. ===Actors:

  1. Actor: Consumer of restricted resources.
  2. Actor: Supplier of restricted resources.
  3. Actor: Verifier of claim of majority (also can validate binding to subject)
  4. Actor: Provider(s) of late binding tokens and client-side code

Preconditions

  • The Consumer has acquired a late binding token from any provider at all.
  • The Consumer has registered an over-21 claim with verifier using token.
  • The Consumer has established an account with supplier using a DID or other persistent ID.

Scenarios

Scenario: Consumer signs into supplier and has never purchased liquor from this site.

  1. Consumer selects to purchase liquor item
  2. Supplier asks user for over 21 proof with a nonce.
  3. Consumer sends verifiable claim of over 21 they acquired from verifier.
  4. Supplier asks verifier for proof. (This would be by redirect to verifier through user browser)
    1. Verifier supplies validated claim (or statement of non-revocation) bound to nonce by redirect to Supplier, if this VC is bound to the user’s session with supplier, it can have a lifetime of the duration of bound session.
  5. Monetization is by direct micro payment (on the order of $.05) from supplier to verifier.


Alternative Paths:

  1. Consumer selects to purchase liquor item.
  2. Supplier asks user for over 21 proof with a nonce.
  3. Consumer asks verifier directly for proof with nonce from Supplier.
  4. Verifier asks consumer to enter token for proof of presence.
  5. Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
  6. Consumer sends verified claim to supplier.
  7. Monetization is by advertising from verifier to consumer.

A different path using biometrics:

  1. Yoti, a London-based startup which wants to become the “world’s trusted identity platform”, is one of many attempts to provide such a service. Its system stores government id documents and biometrics. If a user wants to buy a bottle of wine at a supermarket self-check-out and needs to prove their age, they scan a qr code and take a selfie using Yoti’s app. The retailer can be sure of their age, but no one has seen their name or nationality. From the Financial Times.

Failed Paths:

  1. User does not get verified claim for some reason.
  2. Verified claims fails validation at supplier.

Results

Accepted Risks:

  1. The consumer is not over-21 and has buddy’s token to enter into computer.
  2. Session hijacking mitigated with HTTPS and session cookies.
  3. MitM attacks mitigated by hardware token bound to origin URL of verifier.
  4. Note that the late binding token could be bound to supplier as well as needed.
  5. The identity of the verifier/validator is discoverable by the supplier.
  6. User makes choices on which attributes are trusted for sharing with the supplier.

Post Condition:

  1. If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
  2. Note that at the end of the process of validating the user’s age, the state issued license to sell alcoholic beverages will determine which path to use. The penalty for the supplier using the wrong path is loss of the license to sell alcohol.

Examples:

  1. Late binding token - FIDO U2F token, TEE TPM VSC, etc.
  2. Client side code - javascript in a browser, native app, etc.

Dependencies::

  1. Web Sites must be trusted before any user information is released.
  2. Trust federations can be used to help users make informed decisions.
  3. User consent and trust must begin with no user information transferred.
  4. Standards exist to collect needed attributes where-ever they may be.

Workflow Diagram

TK

References