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 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.
Actor: Consumer of restricted resources.
Actor: Supplier of restricted resources.
Actor: Verifier of claim of majority (also can validate binding to subject)
Actor: Provider(s) of late binding tokens and client-side code
Preconditions:
1. The Consumer has acquired a late binding token from any provider at all.
2. The Consumer has registered an over-21 claim with verifier using token.
3. The Consumer has established an account with supplier using a DID or other
persistent ID.
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)
5. 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.
6. 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:
● 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 TimesTRAFFIC
LIGHT PROTOCOL (TLP)
FIRST Standards Definitions and Usage Guidance — Version 1.0
1. Introduction
a. The Traffic Light Protocol (TLP) was created in order to facilitate greater sharing
of information. TLP is a set of designations used to ensure that sensitive information is
shared with the appropriate audience. It employs four colors to indicate expected
sharing boundaries to be applied by the recipient(s). TLP only has four colors; any
designations not listed in this standard are not considered valid by FIRST.
b. TLP provides a simple and intuitive schema for indicating when and how
sensitive information can be shared, facilitating more frequent and effective
collaboration. TLP is not a “control marking” or classification scheme. TLP was not
designed to handle licensing terms, handling and encryption rules, and restrictions on
action or instrumentation of information. TLP labels and their definitions are not
intended to have any effect on freedom of information or “sunshine” laws in any
jurisdiction.
c. TLP is optimized for ease of adoption, human readability and person-to-person
sharing; it may be used in automated sharing exchanges, but is not optimized for that
use.
d. TLP is distinct from the Chatham House Rule (when a meeting, or part thereof, is
held under the Chatham House Rule, participants are free to use the information
received, but neither the identity nor the affiliation of the speaker(s), nor that of any
other participant, may be revealed.), but may be used in conjunction if it is deemed
appropriate by participants in an information exchange.
e. The source is responsible for ensuring that recipients of TLP information
understand and can follow TLP sharing guidance.
f. If a recipient needs to share the information more widely than indicated by the
original TLP designation, they must obtain explicit permission from the original source.
2. Usage
a. How to use TLP in email
TLP-designated email correspondence should indicate the TLP color of the information
in the Subject line and in the body of the email, prior to the designated information itself.
The TLP color must be in capital letters: TLP:RED, TLP:AMBER, TLP:GREEN, or
TLP:WHITE.
a. How to use TLP in documents
TLP-designated documents should indicate the TLP color of the information in the
header and footer of each page. To avoid confusion with existing control marking
schemes, it is advisable to right-justify TLP designations. The TLP color should appear
in capital letters and in 12 point type or greater.
RGB:
TLP:RED : R=255, G=0, B=51, background: R=0, G=0, B=0
TLP:AMBER : R=255, G=192, B=0, background: R=0, G=0, B=0TLP:RED
TLP:GREEN : R=51, G=255, B=0, background: R=0, G=0, B=0
TLP:WHITE : R=255, G=255, B=255, background: R=0, G=0, B=0TLP:AMBER
CMYK: TLP:GREEN
TLP:RED : C=0, M=100, Y=79, K=0, background: C=0, M=0, Y=0, K=100
TLP:AMBER : C=0, M=25, Y=100, K=0, background: C=0, M=0, Y=0, K=100
TLP:GREEN : C=79, M=0, Y=100, K=0, background: C=0, M=0, Y=0,
K=100TLP:WHITE
3.
TLP:WHITE : C=0, M=0, Y=0, K=0, background: C=0, M=0, Y=0, K=100TLP definitions
a. TLP:RED = Not for disclosure, restricted to participants only.
Sources may use TLP:RED when information cannot be effectively acted upon by
additional parties, and could lead to impacts on a party's privacy, reputation, or
operations if misused. Recipients may not share TLP:RED information with any parties
outside of the specific exchange, meeting, or conversation in which it was originally
disclosed. In the context of a meeting, for example, TLP:RED information is limited to
those present at the meeting. In most circumstances, TLP:RED should be exchanged
verbally or in person.
a. TLP:AMBER = Limited disclosure, restricted to participants’ organizations.
Sources may use TLP:AMBER when information requires support to be effectively
acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the
organizations involved. Recipients may only share TLP:AMBER information with
members of their own organization, and with clients or customers who need to know the
information to protect themselves or prevent further harm. Sources are at liberty to
specify additional intended limits of the sharing: these must be adhered to.
b. TLP:GREEN = Limited disclosure, restricted to the community.
Sources may use TLP:GREEN when information is useful for the awareness of all
participating organizations as well as with peers within the broader community or sector.
Recipients may share TLP:GREEN information with peers and partner organizations
within their sector or community, but not via publicly accessible channels. Information in
this category can be circulated widely within a particular community. TLP:GREEN
information may not be released outside of the community.
c. TLP:WHITE = Disclosure is not limited.
Sources may use TLP:WHITE when information carries minimal or no foreseeable risk
of misuse, in accordance with applicable rules and procedures for public release.
Subject to standard copyright rules, TLP:WHITE information may be distributed without
restriction.
Notes:
1. This document uses “should” and “must” as defined by RFC-2119.
2. Comments or suggestions on this document can be sent to tlp-sig@first.org.
●
● .
Failed Paths:
1. User does not get verified claim for some reason.
2. Verified claims fails validation at supplier.
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.
Formatiert: Schriftartfarbe:
Benutzerdefinierte
Farbe(RGB(17;85;204))
Formatiert: Mit Gliederung + Ebene:
1 + Nummerierungsformatvorlage:
Aufzählungszeichen + Ausgerichtet an:
0,63 cm + Einzug bei: 1,27 cm
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
Formatiert: Mit Gliederung + Ebene:
1 + Nummerierungsformatvorlage:
Aufzählungszeichen + Ausgerichtet an:
0,63 cm + Einzug bei: 1,27 cm
