From 77eae2e703a174d4a7ee08102f75371a7669a402 Mon Sep 17 00:00:00 2001 From: infominer Date: Mon, 3 Jun 2019 09:31:54 -0400 Subject: [PATCH] remove page container --- .../01-Day-1-Welcome-and-Procedural_1.html | 1 - .../02-Day-1-Understanding-Verifiable-Credentials.html | 2 +- .../04-Day-1-Understanding-DID-Auth.html | 2 +- ...Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html | 2 +- ...ay-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html | 2 +- .../07-Day-1-Breakout-Sessions.html | 2 +- ...ket-Verticals-Understanding-Current-and-Future-Problems.html | 2 +- .../09-Day-2-Procedural-Agenda-Gardening.html | 2 +- .../10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html | 2 +- .../10.3-Day-2-PindarWong_1.html | 2 +- .../11-Day-2-Avoiding-Mistakes-and-Minefields.html | 2 +- .../12-Day-2-Breakouts.html | 2 +- .../13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html | 2 +- .../13.5-Day-2-Attestation-Arm.html | 2 +- .../14-Day-2-5-Year-Roadmap-Authenticators.html | 2 +- .../14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html | 2 +- ...15-Day-2-Browsers-work-with-Authentication-and-Identity.html | 2 +- .../Health-Care-IDology.html | 2 +- .../Use-Case-21-with-FIDO-Proof-of-Presence-Key.html | 2 +- 19 files changed, 18 insertions(+), 19 deletions(-) diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/01-Day-1-Welcome-and-Procedural_1.html b/collections/_2018-W3C-Authentication-Identity-Workshop/01-Day-1-Welcome-and-Procedural_1.html index fb541a13..2301bec2 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/01-Day-1-Welcome-and-Procedural_1.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/01-Day-1-Welcome-and-Procedural_1.html @@ -6,7 +6,6 @@ header: -
Strong Authentication and
Identity Workshop
https://www.w3.org/Security/strong-authentication-and-identity-workshop/
real-time chat & minutes (irc): http://irc.w3.org/ #auth-id
World Wide Web Consortium
“Leading the Web to its full potential.” Voluntary consensus standards:
cooperative solutions for open, interoperable platform improvement.
The Art of Consensus.
Web for all. Accessible, Internationalized, Secure, Private
Royalty-free patent policy.
475 members as of December 2018, including technology builders and users;
for-profit companies, academics, non-profits, and government agencies.
Code of Ethics and Professional Conduct: Treat each other with respect
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/02-Day-1-Understanding-Verifiable-Credentials.html b/collections/_2018-W3C-Authentication-Identity-Workshop/02-Day-1-Understanding-Verifiable-Credentials.html index 6001138c..5ce37e53 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/02-Day-1-Understanding-Verifiable-Credentials.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/02-Day-1-Understanding-Verifiable-Credentials.html @@ -6,7 +6,7 @@ header: --- -
+
Understanding Verifiable
Credentials
Dr. Daniel C. Burnett, PegaSys Blockchain Standards Architect, W3C VCWG Co-
chair
W3C Workshop on Strong Authentication & Identity
Redmond, WA, Dec 10-11, 2018
Credentials
2
<passport photo>
<driver’s license photo>
(Cryptographically) Verifiable Credentials
● We aim to provide the same thing, but
electronically
●
A Verifiable Credential is
○ Issued by an Issuer (school, corp, govt, ind.)
○
Held by a Holder (student, employee, customer)
○ Presented to a Verifier (employers, security, websites)
●
A Verifiable Credential contains
○ An Identifier
○
Optional metadata
○ One or more claims
○
A proof section
● Identifiers can be cryptographically controlled
3
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/04-Day-1-Understanding-DID-Auth.html b/collections/_2018-W3C-Authentication-Identity-Workshop/04-Day-1-Understanding-DID-Auth.html index 8f689286..2762dbbf 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/04-Day-1-Understanding-DID-Auth.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/04-Day-1-Understanding-DID-Auth.html @@ -5,7 +5,7 @@ header: --- -
+
Markus Sabadello
Danube Tech, DIF, Sovrin,
W3C CCG, W3C VCWG, OASIS XDI TC
https://danubetech.com/
W3C Workshop on Strong Authentication & Identification
Redmond, WA, USA – 10
th
December 2018
DID Auth
■ Background
● Decentralized Identifiers (DIDs)
● Decentralized Public Key Infrastructure (DPKI)
■ DID Auth
● Prove that the DID subject controls its DID
● A concept, with different architectures and implementations
DID Document
■ DID Document tells us how control of the DID can be proven
■ DID Document contains service endpoints, public keys, authentication
methods
{
"@context": "https://w3id.org/did/v1",
"id": "did:sov:WRfXPg8dantKVubE3HX8pw",
"service": {
"type": "hub",
"serviceEndpoint": "https://azure.microsoft.com/dif/hub/did:sov:WRfXPg8dantKVubE3H"
},
"publicKey": [
{
"id": "did:sov:WRfXPg8dantKVubE3HX8pw#key-1",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDmqPV"
}
],
"authentication": {
"type": "Ed25519SignatureAuthentication2018",
"publicKey": [
"did:sov:WRfXPg8dantKVubE3HX8pw#key-1"
]
}
}
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/05-Day-1-Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html b/collections/_2018-W3C-Authentication-Identity-Workshop/05-Day-1-Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html index 09ee3c4b..f3bc1b65 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/05-Day-1-Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/05-Day-1-Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html @@ -5,7 +5,7 @@ header: --- -
+
WebAuthn / CTAP
Modern Authentication
challenge, “google.com”
Server
How Security Keys work
Who’s calling?
sign:
{challenge, “
google.com”}
{challenge, “google.com”}
signed
Alice’s
Security
Key
Challenge was: 123456
Origin was: google.com
Alice’s Key
https://www.google.com
USB/NFC/BLE
5
challenge
1
6
2
3
4
3
© 2018 Yubico © 2016 Yubico
Registration Recap
1. Relying Party generates challenge
○ Prevents replay
2. Client validates origin
○ Prevents phishing
3. Authenticator checks user presence and consent
○ Prevents silent tracking
4. Authenticator creates key pair
○ No secret is shared with Relying Party
5. Relying Party verifies attestation signature
○ Prevents phishing
○ Proof that private key is safe
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/06-Day-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html b/collections/_2018-W3C-Authentication-Identity-Workshop/06-Day-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html index c31f91d5..c40b381c 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/06-Day-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/06-Day-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html @@ -6,7 +6,7 @@ header: -
+
Understanding JWT/CWT, OpenID
and Related Ecosystem
Michael Jones, John Bradley
Aaron Parecki
JWT, OpenID Connect,
CWT, and Verifiable Claims
Michael B. Jones – Microsoft and John Bradley – Yubico
W3C Workshop on Strong Authentication and Identity
December 10, 2018
JSON Web Token (JWT) – RFC 7519
• Representation of claims in JSON
• Can be signed with JSON Web Signature (JWS) – RFC 7515
• Can be encrypted with JSON Web Encryption (JWE) – RFC 7516
• Algorithms used extensible using IANA JOSE Algorithms Registry
• For instance, ed25519 added and secp256k1 being added
• By design, does not use any form of JSON canonicalization
• Base64url encodes values to maintain content integrity instead
• JWTs used by OpenID Connect, many other applications
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/07-Day-1-Breakout-Sessions.html b/collections/_2018-W3C-Authentication-Identity-Workshop/07-Day-1-Breakout-Sessions.html index 82e7a323..e1b7be5c 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/07-Day-1-Breakout-Sessions.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/07-Day-1-Breakout-Sessions.html @@ -3,7 +3,7 @@ title: "07) Day 1. Breakout Sessions" --- -
+
Questions for breakout discussion
From where you’re coming from, what do you want to see happen in the next 2-5
years?
What is the biggest concern you have with regard to what you heard this morning?
Breakout groups: 6 people/session
● Introduce yourself
● Read your card, respond to clarifying questions
● Identify shared thoughts/concerns
● Each person has 2 unique votes to give to others’ ideas
○ Tally the votes each card receives, on the card
● Write down new ideas on new cards
Report-out from breakouts
● Identification != authentication. Getting the world to understand the difference.
○ Separation of concerns: authentication and attribute-provisioning ceremonies
● Privacy. Needs more discussion of privacy concerns and considerations
○ Privacy by design
● Identity assurance. How do you get to trusting the issuer or assurer? Moving
from technology to service
● Want browser/device to know who I am and be my agent in revealing that
● Bridging WebAuthn and OAuth
● RPs have a rich choice of federation, and user-access to those
○ Also data storage
● Coexistence, not choosing between paradigms. Discovery, registration,
resolution.
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/08-Day-1-Market-Verticals-Understanding-Current-and-Future-Problems.html b/collections/_2018-W3C-Authentication-Identity-Workshop/08-Day-1-Market-Verticals-Understanding-Current-and-Future-Problems.html index 7184ef84..8d608f7b 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/08-Day-1-Market-Verticals-Understanding-Current-and-Future-Problems.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/08-Day-1-Market-Verticals-Understanding-Current-and-Future-Problems.html @@ -3,7 +3,7 @@ title: "08) Day 1. Market Verticals Understanding Current and Future Problems" --- -
+
Market Verticals: Current
and Future Challenges
Government
Peter Watkins
Province of British Columbia
Strong Authentication and
Identity Information
Understanding current and future
problems from a government
perspective
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/09-Day-2-Procedural-Agenda-Gardening.html b/collections/_2018-W3C-Authentication-Identity-Workshop/09-Day-2-Procedural-Agenda-Gardening.html index 004db7c9..41611796 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/09-Day-2-Procedural-Agenda-Gardening.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/09-Day-2-Procedural-Agenda-Gardening.html @@ -3,7 +3,7 @@ title: "09) Day 2. Procedural Agenda Gardening" --- -
+
Agenda Gardening, Day 2
Agenda Gardening, Day 2
https://www.w3.org/Security/strong-authentication-and-identity-
workshop/schedule.html
● 9:00 AM Procedural / Agenda Gardening
● 9:30 AM Dot voting: Concerns and Potential Work Items
● 9:45 AM
Exploring Cultural and Economic Perspectives
● 10:15 AM Avoiding mistakes and minefields
● 10:35 AM T-ID? Use case
● 11:00 AM Breakout #3: Work that needs to be incubated
● 11:30 AM Breakout #4: Work that is ready for a Working Group
● 1:00 PM Dot voting: Work for Incubation / Work for Working Groups
● 1:30 PM Entire Group: Discussion on warnings/objections on incubation / WGs
● 2:15 PM 5 Year Roadmap: DIDs, VCs, Attestation
● 2:45 PM 5 Year Roadmap: Authenticators
● 3:15 PM Browsers, Identity and Authentication
● 3:45 PM W3C Next Steps / Wrap up / close
● 4:00 PM Finish
Breakout Gardening
Dot-voting gave us several clusters:
● Confusion
○ Review quickly to see whether the group wants to spend time improving understanding
● General consensus
● Contentious items
● Chartering
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html b/collections/_2018-W3C-Authentication-Identity-Workshop/10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html index b7f57b71..c8367c63 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html @@ -4,7 +4,7 @@ description: "Current Situation of Japanese Fragmented ID Platforms" "--- -
+
Current Situation of
Japanese fragmented ID Platforms
Dec. 2018
JCB Co., Ltd.
*The opinions expressed in this article are the author's own
and do not reflect the view of JCB Co., Ltd.
2
Agenda
1. Japanese "fragmented" ID Platforms
• “Fragmented" ID Platforms established by Japanese big companies
• Lack of Interoperability between platforms
2. Lack of Central Social ID system in Japan
• Heavily dependent on Driving License for KYC process
• Failed "My number (Japanese social security and tax number system)" expansion
3. My Opinion
• Necessity of “loose” ID federation in Japan Market
• Basic use case
3
① Japanese "fragmented" ID Platforms
Fragmented ID Platforms established by Japanese big companies
• Japanese Big Companies have tendency to establish their own “Platform”.
(E-commerce, SNS, Mobile Carrier, Automotive, Railways, Airlines, Department Store… )
Toyota
”My Toyota”
NTT Docomo
”d Account”
Yahoo Japan
”Yahoo ID”
JR East
(Former National Railway)
”JRE Point”
Rakuten
”My Rakuten”
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/10.3-Day-2-PindarWong_1.html b/collections/_2018-W3C-Authentication-Identity-Workshop/10.3-Day-2-PindarWong_1.html index 676cd362..b75fef54 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/10.3-Day-2-PindarWong_1.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/10.3-Day-2-PindarWong_1.html @@ -2,7 +2,7 @@ title: "10.3 Day 2 Pindar Wong" --- -
+
Law and Borders:
Self-Administered IDentifiers
and
NExTPats: NETizen eXpatriates
黃平達
Pindar.Wong@gmail.com
VeriFi (Hong Kong) Limited
2018年11月27日
CC BY-NC 4.0
Source: http://i.imgur.com/MWnlkbo.jpg
There are more people living inside
this circle than outside of it
The Right to Work Online
Data Model:
Legal Identifiers with Legal Standing
1) Natural Persons (Privacy Constrained)
2) Legal Persons
other types( AI, IoT (50 billion), Smart Contracts)
Data Model:
Non-Lawful Identifiers (does not require the law for
legitimacy)
Netizen Expatriates (NETizen Expatriates)
Displaced People
(Now 70 million: More than post WWII
Future: 700 million -> billion in a generation)
Internally Displaced Persons
Externally Displaced - Forced Migrants
Migrant Workers
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/11-Day-2-Avoiding-Mistakes-and-Minefields.html b/collections/_2018-W3C-Authentication-Identity-Workshop/11-Day-2-Avoiding-Mistakes-and-Minefields.html index 1c7d6af5..50d7705c 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/11-Day-2-Avoiding-Mistakes-and-Minefields.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/11-Day-2-Avoiding-Mistakes-and-Minefields.html @@ -3,7 +3,7 @@ title: "11) Day 2 Avoiding Mistakes and Minefields" --- -
+
Avoiding Mistakes and
Minefields
Jeff Hodges
W3C Strong Authentication and Identity Workshop
10,11-Dec-2018
"common mistakes and minefields while building Strong Auth
and Identity technologies" -- Which context?
i.e. at..
●
protocol/system design time,
●
component implementation time (eg, in libraries/packagers, clients, servers),
● deployment time (i.e., by Relying Parties and Service Providers)
..?
"common mistakes and minefields while building Strong Auth
and Identity technologies" -- Which context?
i.e. at..
●
protocol/system design time,
●
component implementation time (eg, in libraries/packages, clients, servers),
● deployment time (i.e., by Relying Parties, Service Providers, Identity Providers)
..?
NOTE: the above are "motherhood & apple pie" aspects of building anything
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/12-Day-2-Breakouts.html b/collections/_2018-W3C-Authentication-Identity-Workshop/12-Day-2-Breakouts.html index 7b80fd69..be1a5f8f 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/12-Day-2-Breakouts.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/12-Day-2-Breakouts.html @@ -3,7 +3,7 @@ title: "Breakouts" --- -
+
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html b/collections/_2018-W3C-Authentication-Identity-Workshop/13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html index 3f56e64f..737b866c 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html @@ -3,7 +3,7 @@ title: "13) Day 2. 5 Year Roadmap DIDs VCs, and Attestations" --- -
+
DID & VC Architecture
Roadmap 2018+
Christopher Allen
Principal Architect & Founder — Blockchain Commons
W3C Credentials CG Chair
1
Current Efforts at W3C
2
● Verifiable Claims WG, Verifiable Credentials
○ Anyone can verifiably say anything about anyone.
○ Identity emerges from evaluating multiple sources of
information, across multiple interactions
● Decentralized Identifiers (DIDs), draft WG
○ Anyone can publicly manage provable identifiers without
administrative interference
○ Move beyond centrally administered IDs
○ Provide for a plurality of authorities
Decentralized Identity Stack
3
● DIDs – Root Identifiers
○ DID Universal Resolvers — support interoperability between
multiple DID methods.
○ DID Methods – Specific approaches using different blockchains
○ DID Documents – Proof of Control & Service References
+
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/13.5-Day-2-Attestation-Arm.html b/collections/_2018-W3C-Authentication-Identity-Workshop/13.5-Day-2-Attestation-Arm.html index f1f06ec6..74a96628 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/13.5-Day-2-Attestation-Arm.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/13.5-Day-2-Attestation-Arm.html @@ -2,7 +2,7 @@ title: "13) Day 2 Attestation Arm" --- -
+
Attestation Roadmap
Mathias Brossard
mathias.brossard@arm.com
W3C Workshop on Strong
Authentication & Identity
December 10th and 11th, 2018
Platform Security Architecture (PSA)
– IoT security desperately
needed.
– PSA aims to offer guidance +
designs + software
– Open Source project: Arm
Trusted Firmware-M
– Arm v8-M with TrustZone
support
– APIs currently being defined
•
Crypto API published
• Attestation API planned for 1Q
2019
SECURE STATES NON-SECURE STATES
TrustZone for Arm v8-M
Secure
App/Libs
Secure OS
parts
Non-secure
OS parts
Non-secure
App
APIs
Attestation
– Many existing attestation efforts:
• Trusted Computing Group (TCG): Trusted Platform
Module (TPM)
• Android
• FIDO
• Global Platform
• …
– Expressed interest for some convergence towards IETF
EAT
• CWT / JWT based container
• CWT preferred in constrained environments
(token size, RAM/Code requirements)
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/14-Day-2-5-Year-Roadmap-Authenticators.html b/collections/_2018-W3C-Authentication-Identity-Workshop/14-Day-2-5-Year-Roadmap-Authenticators.html index a9e760c9..8d6b13a6 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/14-Day-2-5-Year-Roadmap-Authenticators.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/14-Day-2-5-Year-Roadmap-Authenticators.html @@ -3,7 +3,7 @@ title: "14) Day 2. 5 Year Roadmap Authenticators" --- -
+
©Veridium All Rights Reserved
Authenticators
Convergence
2
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html b/collections/_2018-W3C-Authentication-Identity-Workshop/14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html index df4201ea..67fe2a5f 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html @@ -2,7 +2,7 @@ title: "14.5) Day-2. 5 Year Roadmap Authenticators - Gemalto" --- -
+
The impacts of European regulation PSD2 and
Strong Customer Authentication on e-commerce
Marie Lathière, Digital Strategy Banking & Payments
Mandates
Objectives
PSD2 will come into force in September 2019
Foster innovation
Protect customers
Issuers must open APIs for account
consultation and payment initiation
e-transactions must be protected by
Strong Customer Authentication
Strong Customer Authentication (SCA) and Dynamic
Linking requirements
Dynamic Link
Fingerprint
Face
Voice
What I Am
(inherence)
PIN / Password
What I Know
Device, token, card
What I Have
(possession)
and/or
and/o
r
Strong Customer Authentication (SCA)
and
Transaction
value
Transaction
Payee
Authentication code generation
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/15-Day-2-Browsers-work-with-Authentication-and-Identity.html b/collections/_2018-W3C-Authentication-Identity-Workshop/15-Day-2-Browsers-work-with-Authentication-and-Identity.html index ebd3dd53..98f861a3 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/15-Day-2-Browsers-work-with-Authentication-and-Identity.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/15-Day-2-Browsers-work-with-Authentication-and-Identity.html @@ -3,7 +3,7 @@ title: "15) Day 2. Browsers work with Authentication and Identity" --- -
+
Web Authentication
User Journeys
Simple Secure Authentication
Steven Soneff - sso@google.com
Dec 2018
Original Authors:
UX: tringuye@
PM: cbrand@
WebAuthn enables user journeys that are
WebAuthn / What is WebAuthn?
Simple – intuitive and easy for user
Secure – resistant to phishing, re-use, etc.
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html b/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html index 5a96ad7e..b1eb8e9b 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html @@ -3,7 +3,7 @@ title: "Health Care IDology" --- -
+
Health Care IDology
Allen L. Brown, Jr., Ph.D.
Deixis, PBC
Seattle, WA
abrown@deixis.digital
W3C Workshop Redmond
December 10-11, 2018
1/3
What needs an identity?
§
payers
§
providers
§
data
§
patients
2/3
What needs an identity?
§
payers
§
providers
§
data
§
patients
2/3
diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/Use-Case-21-with-FIDO-Proof-of-Presence-Key.html b/collections/_2018-W3C-Authentication-Identity-Workshop/Use-Case-21-with-FIDO-Proof-of-Presence-Key.html index 3fb2101b..924ea7c6 100644 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/Use-Case-21-with-FIDO-Proof-of-Presence-Key.html +++ b/collections/_2018-W3C-Authentication-Identity-Workshop/Use-Case-21-with-FIDO-Proof-of-Presence-Key.html @@ -3,7 +3,7 @@ title: "Use Case 20 with FIDO Proof of Presence Key" --- -
+
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