diff --git a/_config.yml b/_config.yml index 3e6cc308..418f00d3 100644 --- a/_config.yml +++ b/_config.yml @@ -345,20 +345,4 @@ defaults: toc_sticky : true twitter: card: summary_large_image - # _2018-W3C-Authentication-Identity-Workshop - - scope: - path: "" - type: 2018-W3C-Authentication-Identity-Workshop - values: - layout: single - author_profile: false - read_time: false - comments: # true - share: true - related: true - idwkshp: true - sidebar: - title: DIDecentralized - nav: "didnav" - twitter: - card: summary_large_image + \ No newline at end of file diff --git a/_pages/2018-W3C-Authentication-Identity-Workshop.md b/_pages/2018-W3C-Authentication-Identity-Workshop.md deleted file mode 100644 index 24e9633e..00000000 --- a/_pages/2018-W3C-Authentication-Identity-Workshop.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "2018 W3C Strong Authentication and Identity Workshop" -layout: collection -permalink: /2018-W3C-Authentication-Identity-Workshop/ -collection: 2018-W3C-Authentication-Identity-Workshop -entries_layout: grid -classes: wide -sidebar: - nav: didnav -author_profile: false -#: 7 -share: true ---- - -## 2018 W3C Strong Authentication and Identity Workshop \ No newline at end of file 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 deleted file mode 100644 index 2301bec2..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/01-Day-1-Welcome-and-Procedural_1.html +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "01) Day 1. Welcome and Procedural" -header: - teaser: /images/strong-authentication-identity-workshop-w3c.png ---- - - - -
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
-
Standards work well for
● Shared technical problem
● Good enough technical solution
● Ecosystem interest in common resolution
W3C provides the forum and process: community and
membership develop the specifications.
-
Workshop Agenda
2 days of mixed presentation and discussion.
Experimenting with multiple modes of hearing
from everyone in the room: cards, dots, and
breakouts.
Cards: Write down your questions and concerns
during sessions, and we’ll gather them as
sessions conclude.
Dinner tonight:
Who’s in for an on-campus dinner?
Who needs a shuttle (about ½ mile)?
-
Minutes and reporting
This workshop is invite-only. We’ll follow with a
public report.
We take minutes in irc:
http://irc.w3.org (yes, it’s http)
channel #auth-id
● Please state your name when speaking
● q+ to say something new adds you
to the speaker queue
● scribing conventions
○ speaker: what they said
○ use @@1..n if you miss a name or phrase
while scribing
○ s/@@1/Name/ replaces @@1 in the
meeting record
-
Thanks!
Program Committee:
● Manu Sporny, Digital Bazaar
● Paul Grassi, Easy Dynamics
● Drummond Reed, Evernym
● Christiaan Brand, Google
● Kaliya Young, Internet Identity Workshop
● Tony Nadalin, Microsoft
● JC Jones, Mozilla
● Pindar Wong, VeriFi
W3C Team: Sam Weiler, Karen Myers, Wendy Seltzer
Host:
- -
- -
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 deleted file mode 100644 index 5ce37e53..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/02-Day-1-Understanding-Verifiable-Credentials.html +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "02) Day 1. Understanding Verifiable Credentials" -header: - teaser: /images/understanding-verifiable-credentials.png - ---- - - - -
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
-
Claims & Proofs
● A Claim is
○ One statement about a Subject
●
A Claim contains
○
A Subject
○
A Property
○ A Value for the property
●
The Proof section contains
○ Signatures over the claims
○ ZKP info (work in progress)
4
-
VC Example in JSON-LD syntax
{
"@context": [
"https://w3.org/2018/credentials/v1",
"https://example.com/examples/v1"
],
"id": "http://dmv.example.gov/credentials/3732",
"type": ["VerifiableCredential", "ProofOfAgeCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 21
},
"proof": { ... }
}
5
-
VC - signature-based proof example
{ "@context": [...],
"id": "http://dmv.example.gov/credentials/3732",
"type": ["VerifiableCredential", "ProofOfAgeCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {...},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"creator": "https://example.com/jdoe/keys/1",
"nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
"signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
+W3JT24="
}}
6
-
Verifiable Presentations
● A Verifiable Presentation is
○ Presented by a Holder to a Verifier
○
Composed from multiple VCs
○
Often from different Issuers
○
Often about the same subject
● A Verifiable Presentation contains
○
An identifier
○
Optional metadata
○ One or more claims or whole VCs
○
A proof section
7
-
Verifiable Credentials are (not)?
Verifiable Credentials allow
● An issuing party to express a statement as a fact, ie “make a claim”
● A holding party to present the statement (in whole or in part) to a third party
● A verifying party to validate the statement hasn’t been tampered with
Verifiable Credentials DON’T
● Represent a “verified truth”
It is the issuance of a claim that is verifiable, not the semantics of the claim
8
-
Standardization: W3C Verifiable Claims Working Group
● In Scope
○
Recommend a data model and syntax(es) for the expression of verifiable claims, including one
or more core vocabularies
○
Create a note specifying one or more of these:
■
How these data models should be used with existing attribute exchange protocols
■
A suggestion that existing protocols be modified
■ A suggestion that a new protocol is required
●
Out of Scope
○
Define browser-based APIs for interacting with verifiable claims. This work may be performed
by a future Working Group if there is interest, but is not required for the Working Group to be
successful
○
Define a new protocol for attribute exchange. This work may be performed by a future Working
Group if there is interest, but is not required for the Working Group to be successful
○ Attempt to address the larger problem of "Identity on the Web/Internet"
○ Attempt to lead the creation of a specific style of supporting infrastructure, other than a data
model and syntax(es), for a verifiable claims ecosystem
9
-
VCWG Work Status
● “Verifiable Claims Data Model and Representations” specification
○ FPWD long past, wrapping up ZKP and JWT support
○ Informal reviews already from PING, WAI, others
○ CR expected early 2019
○ Editors’ Draft: https://w3c.github.io/vc-data-model/
○ GitHub: https://github.com/w3c/vc-data-model
● Test Suite
○ Almost all tests written
○ GitHub:
https://github.com/w3c/vc-test-suite
● Use cases
○ Editors’ Draft:
https://w3c.github.io/vc-use-cases/
○ GitHub: https://github.com/w3c/vc-use-cases
10
-
2018 VC Adoption in Commerce
(Financial Services)
11
Deployed Today by:
● Governments
● Banks
● Websites
● DID issuers
Details are W3C M ember Confidential
-
2018 VC Adoption in Commerce
(Trade)
12
Deployed Today for:
● Authorized Importer
● Authorized Exporter
● Certificate of Origin
Details are W3C M ember Confidential
-
Questions?
13
-
VCWG Mission and Goals
● It is currently difficult to express claims regarding education qualifications,
healthcare data, banking account information, and other sorts of machine-
readable personal information that has been verified by a 3rd party on the
Web
● VCWG mission is to make expressing and exchanging claims that have been
verified by a third party easier and more secure on the Web
●
Our charter specifies that education related uses is our first focus but allows
that other uses can be addressed such as digital offers, receipts, and loyalty
programs and other areas if there is significant industry participation
14
- -
- diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/03-Day-1-Understanding-DIDs.html b/collections/_2018-W3C-Authentication-Identity-Workshop/03-Day-1-Understanding-DIDs.html deleted file mode 100644 index ae740cef..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/03-Day-1-Understanding-DIDs.html +++ /dev/null @@ -1,672 +0,0 @@ ---- -title: "03) Day 1. Understanding DIDs" -header: - teaser: /images/understanding-dids.png - ---- - - - - - - - - - -
Understanding
Decentralized Identifiers
Kim Hamilton Duffy
CTO Learning Machine
Co-chair W3C Credentials Community Group
Decentralized Identity Foundation Steering Committee
1
-
What is a Decentralized Identifier?
A new type of URL that is:
●
globally unique,
●
highly available,
●
persistent
●
cryptographically verifiable, and
●
does not require a central admin
2
did:btcr:txtest1:8kyt-fzzq-qqqq-ase0-d8
-
We use DIDs in Verifiable Credentials
3
-
DID Implementations (Methods)
4
did:example:123456789abcdefghijk
Scheme
DID
Method
DID Method Specific String
did:v1:nym:BcNkgGmGEpCGSJSMPB4BvWvwVM6YeTR52BSWcZTbzU23
did:btcr:txtest1:8kyt-fzzq-qqqq-ase0-d8
Examples:
-
DIDs Resolve to DID Documents
5
{
"@context": "https://w3id.org/veres-one/v1",
"id": "did:v1:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD",
"authentication": [{
"type": "Ed25519SignatureAuthentication2018",
"publicKey": [{
"id": "did:v1:test:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD#authn -key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:v1:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD",
"publicKeyBase58": "DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD"
}]
}],
"service": [{
"type": "ExampleMessagingService2018",
"serviceEndpoint": ”https://example.com/services/messages”
}],
… more DID-specific information here …
}
1. Authentication Mechanisms
3. Service Discovery
2. Public Key Material
-
did:btcr:xkyt-fzgq-qq87-xnhn
Universal Resolver
DID RESOLUTION
DID Method Spec
DID Document
DID
-
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"publicKey": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaSigningKey2018",
"owner": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"authentication": [{
"type": "RsaSignatureAuthentication2018",
"publicKey": "did:example:123456789abcdefghi#keys-1"
}],
"service": [{
"type": "ExampleService",
"serviceEndpoint": "https://example.com/endpoint/8377464"
}],
"created": "2002-10-10T17:00:00Z",
"updated": "2016-10-17T02:41:00Z",
"signature": {
"type": "RsaSignature2016",
"created": "2016-02-08T16:02:20Z",
"creator": "did:sov:8uQhQMGzWxR8vw5P3UWH1j#key/1",
"signatureValue": "IOmA4R7TfhkYTYW87z640O3GYFldw0
yqie9Wl1kZ5OBYNAKOwG5uOsPRK8/2
C4STOWF+83cMcbZ3CBMq2/gi25s=“
}
}
}
DID DOCUMENT
1. DID (for self-description)
2. Public keys (for verification)
3. Auth methods (for authentication)
4. Service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
-
Status
8
● Incubated at RWOT, IIW
● Currently:
○ Draft report in W3C Credentials Community
Group
○ Protocols and prototypes at DIF
○ DID Method Registry
○ DID Auth, DID Resolver
● To Discuss: DID Working Group
-
DID & VC Architecture
Roadmap 2018+
Christopher Allen
Principal Architect & Founder — Blockchain Commons
W3C Credentials CG Chair
9
-
Current W3C Standards Track Efforts
10
● 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
11
● 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
+
-
Decentralized Identity Stack
12
● DIDs – Root Identifiers …
● Raw Data – Observed facts & transactions
● Verifiable Credentials – Assertions by knowable authorities
● Profiles / Presentations / Persona – Representations of individuals
● Consent – Records of authorization
● Reasoning – Interpretation & Analysis
● Evaluation – Risk Analysis & Reputation
● Understanding – Internal knowledge representation
● Services – Interactions of value
-
Potential Standards for Future Work
13
● DID-Auth (Authn/Authz)
● OCAP (Authz through Object Capabilities)
● Credential Requests & Exchange
● Data Minimization & Selective Disclosure
● Consent & Consent Receipts
● Storage (Identity Hubs) & Internal Representations
● Analytics & Algorithms for Evaluation
● Cryptographic Proofs
○ Signature, Encryption, Signcryption Suites
○ Time-stamping
○ Zero-knowledge proofs
-
https://w3c-ccg.github.io/roadmap/diagram.html
-
-
- 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 deleted file mode 100644 index 2762dbbf..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/04-Day-1-Understanding-DID-Auth.html +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "04) Day 1. Understanding DID Auth" -header: - teaser: /images/understanding-did-auth.png ---- - - - -
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"
]
}
}
-
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"
]
}
}
-
DID Auth Example Architecture
-
Challenges, Responses, Transports
■ Challenge-response flow to prove that the DID subject controls its DID.
■ Transports: HTTP POST, QR code, Mobile deep link, JavaScript browser
API, Bluetooth, NFC, etc.
■ Transports may require additional information such as endpoint URIs that
may be included in the challenge, or discoverable from a DID.
■ Challenge:
● Identity owner’s DID may or not be
known.
● May or may not contain proof of control
of a DID of the relying party.
■ Response:
● Linked to a challenge (e.g. using a
nonce).
● Contains proof of control of a DID of the
identity owner.
-
DID Auth Example Architectures
-
DID Auth Data Formats
■
Example JWT:
■ Example JSON-LD VC:
{
"header": {
"typ": "JWT",
"alg": "ES256"
},
"payload": {
"iss":
"did:example:123456789abcdefg",
"sub":
"did:example:123456789abcdefg",
"iat": 1479850830,
"exp": 1511305200,
},
"signature": "..."
}
{
"type": ["Credential"],
"issuer": "did:example:123456789abcdefg",
"issued": "2018-03-07",
"credentialSubject": {
"id": "did:example:123456789abcdefg",
"publicKey": "did:example:123456789abcdefg#ke
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2018-01-01T21:19:10Z",
"creator": "did:example:123456789abcdefg#keys
"nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0
"signatureValue": "..."
}
}
-
DID Auth Data Formats
■
Example JWT:
■ Example JSON-LD VC:
{
"header": {
"typ": "JWT",
"alg": "ES256"
},
"payload": {
"iss":
"did:example:123456789abcdefg",
"sub":
"did:example:123456789abcdefg",
"iat": 1479850830,
"exp": 1511305200,
},
"signature": "..."
}
{
"type": ["Credential"],
"issuer": "did:example:123456789abcdefg",
"issued": "2018-03-07",
"credentialSubject": {
"id": "did:example:123456789abcdefg",
"publicKey": "did:example:123456789abcdefg#ke
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2018-01-01T21:19:10Z",
"creator": "did:example:123456789abcdefg#keys
"nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0
"signatureValue": "..."
}
}
-
Relation to OIDC, WebAuthn
■
OIDC + DID
● Self-Issued OpenID Provider
● Discover OIDC endpoint from DID
■ WebAuthn + DID
● Registration
Register(Account, Origin)
● Registration Response (without DID)
RegisterResponse(PublicKeyCredential,
Attestation, Origin)
● Registration Response (with DID)
RegisterResponse(DIDCredential,
Attestation, Origin)
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefg",
"service": [{
"id": "did:example:123456789abcdefg;openid",
"type": "OpenIdConnectVersion1.0Service",
"serviceEndpoint": "https://openid.example.com/"
}]
}
■ And more! DID-TLS, DID-HTTP-Signatures, DID-PGP, DID-
SSH
-
For the Workshop
■ Come up with a list of core DID Auth principles
1) The identifier that is being authenticated is a DID.
2) All elements of the DID Document can change, the DID stays the same.
3) DID Resolution is performed to discover how to authenticate the DID.
4) … more?
■ Workshop Question #1: Relation to OIDC, FIDO, WebAuthn?
■ Workshop Question #2: Relation to VC exchange protocols?
-
Community Resources
■ W3C Credentials Community Group
https://www.w3.org/community/credentials/
■ Decentralized Identity Foundation
http://identity.foundation/
■ Rebooting-the-Web-of-Trust
http://www.weboftrust.info/
■ Internet Identity Workshop
http://internetidentityworkshop.com/
Thank You
■ Markus Sabadello
■ Danube Tech
https://danubetech.com/
■ markus@danubetech.com
z
-
Backup Slides
-
Rebooting-the-Web-of-Trust
Internet Identity Workshop
DIDs: W3C Credentials CG
v0.11 Draft Community Report
DIDs: W3C DID WG
Charter now being written
Yadis, XRI, XRD, XRDS,
JRD, Webfinger
DID registered
prov. URI scheme
DID method specs
W3C Web Payments CG
OASIS XDI TC
W3C JSON-LD 1.1
W3C Cryptographic Suites
RFC 7517: JWK
Verifiable Credentials
DKMS, DID Auth
Hubs, Agents, XDI
-
DID Universal Resolver
■ Looks up (“resolves”) DID to its
DID Document.
■ Provides a universal API that works
with all DID methods.
■ Uses a set of configurable “drivers”
that know how to connect to the
target system.
■ https://uniresolver.io/
-
-
- 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 deleted file mode 100644 index f3bc1b65..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/05-Day-1-Understanding-WebAuthn-CTAP-EAT-FIDO-and-Authenticators.html +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "05) Day 1. Understanding WebAuthn CTAP EAT FIDO and Authenticators" -header: - teaser: /images/webauthn-ctap.png ---- - - - -
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
-
4
© 2018 Yubico © 2016 Yubico
What is CTAP?
Authenticator
Browser
Client/Platform
Platform
Application
CTAP1 and/or CTAP2
● Authenticator generates and securely stores credentials
● Communicates over USB, NFC, or Bluetooth
● Private keys, PINs, and biometric information never leave the
authenticator
● CTAP2 Data format: Concise Binary Object Representation (CBOR)
-
5
© 2018 Yubico © 2016 Yubico
What is WebAuthn?
FIDO2 Server
Browser
Client/Platform
Platform
Application
We bAuthn
● WebAuthn (JavaScript) API lets Browser, Client talk about external
or platform (embedded) authenticators. It is 2-party interaction.
● Enables the creation and use of strong, attested, scoped, public
key-based credentials for use by web applications.
● Strongly authenticates users.
● All major browsers are on track to implement full Web
Authentication APIs. Chrome, Edge, Mozilla all support now.
-
6
© 2018 Yubico
Evolution of FIDO Authentication to FIDO2
U2F
User Agent
U2F.js
CTAP1
FIDO2
Platform
WebAuthn
CTAP1
FIDO U2F
Authenticator
FIDO2
Authenticator
CTAP2
U2F
● Phishing resistant authentication with
user intent
● Multi-Factor Authentication (MFA)
Subset
○ Authenticator - something you
have
○ Password - something you know
FIDO2
● True MFA
○ Authenticator - something you
have
○ User verification - something you
know (PIN) or are (Biometrics)
-
7
© 2018 Yubico
WebAuthn and CTAP2
-
8
© 2018 Yubico © 2016 Yubico
State of state
● CTAP2 in final review at FIDO; standardization soon
● WebAuthn clearing up some issues for move to PR (resolution
soon, PR early 2019?).
● New FIDO2 (CTAP2/WebAuthn) features:
○ Resident Keys provide first-factor, high assurance MFA, and
enable passwordless authentication
○ HMAC support to enable offline authentication
● Migration path to WebAuthn exists for U2F devices, credentials
● FIDO UAF features, such as transactions, part of Level 2 W3C
work
-
EAT
Entity Attestation Token
IETF Internet Draft
-
EAT (more)
● Web Authn WG looking at this in IETF
●
Key use is with payment handlers that open a new window
●
We don’t anticipate any extra work in CredMan
●
Been seeking guidance via Mike West
-
All Rights Reserved | FIDO Alliance | Copyright 2018
FIDO and
Authenticators
Dr. Rae Hayward
Certification Director
FIDO Alliance
-
All Rights Reserved | FIDO Alliance | Copyright 2018 12
BENEFITS TO CERTIFICATION
Validation Interoperable
Rigorous
testing
Trust
Competitive
edge
Market
expansion
-
All Rights Reserved | FIDO Alliance | Copyright 2018 13
-
All Rights Reserved | FIDO Alliance |
Copyright 2018
14
FIDO AUTHENTICATOR CERTIFICATION
• Validates the security characteristics
of authenticator implementations
• Functional is a prerequisite
All Rights Reserved | FIDO Alliance | Copyright 2018
-
All Rights Reserved | FIDO Alliance | Copyright 2018
15
A COMPREHENSIVE SET OF LEVELS FOR ALL USES CASES
SAMPLE DEVICE HARDWARE &
SOFTWARE REQUIREMENTS
DEFENDS AGAINST
Protection against chip fault injection,
invasive attacks…
L3+
Captured devices
(chip-level attacks)
Circuit board potting, package on
package memory, encrypted RAM…
L3
Captured devices
(circuit board level attacks)
Restricted Operating Environment (ROE)
(e.g., TEE or Secure Element in a
phone, USB token or Smart Card which
are intrinsically ROEs, other…)
L2+
Device OS compromise
(defended by ROE)
L2
Any device HW or SW
L1+
Device OS compromise
(defended by white-box cryptography)
L1
Phishing, server credential
breaches & MiTM attacks
(better than passwords)
-
All Rights Reserved | FIDO Alliance | Copyright 2018 16
LEVEL 1
Examples
• Android or IoS applications
• Platform built-in authenticators
• Level 2- or Level 3-capable
authenticators not yet certified at
Level 2 or Level 3
Certification Process
Vendor documents their design in detail
L1+ only: Evaluation by FIDO
-accredited lab,
penetration testing (L1+ program still in
development)
Evaluation by FIDO Alliance Security Secretariat
• Better than passwords
• FIDO is unfishable and biometrics are
more convenient
• Keys and biometric templates are
protected similar to passwords
stored by a browser or password
manager app
• Requires best facilities offered by
hosting OS
• L1+ adds white-box cryptography
(obfuscation and other techniques)
to defend against compromise of
hosting OS
-
All Rights Reserved | FIDO Alliance | Copyright 2018 17
LEVEL 2
In addition to L1
• A restricted operating
environment like a TEE gives
security even if OS is
compromised.
• Separate USB, BLE and NFC
authenticators are considered
to use a restricted operating
environment
• Gives defense against larger
scale attacks
• Additional assurance at L2+
Certification Process
Vendor documents their design in detail
L2+ only: Vendor submits source code (L2+ program
still in development)
Evaluation by a FIDO
-accredited lab
L2+ only: Attack potential calculation, pen testing
Examples
• Android apps using FIDO Level 2 certified
phone (there aren’t any yet)
• USB, BLE and NFC Security Keys
• Level 3-capable authenticators that
haven’t yet been certified at Level 3
-
All Rights Reserved | FIDO Alliance | Copyright 2018 18
LEVEL 3
In addition to L2
• Defends against physically captured
authenticators
• Defenses against disassembling,
probing, glitch and other such
physical attacks
• L3+ adds defense against chip-level
physical attacks, such as decapping
and probing the chip
Certification Process
Vendor documents their design in detail
Vendor submits source code
Evaluation by a FIDO
-accredited lab (l3, L3+)
Attack potential calculation and penetration testing
L3+ only: Higher attack potential requirements
Examples
• USB, BLE and NFC Security Keys using
Secure Elements or other means of
defending HW attacks
• In some case phone or platform
authenticators may achieve L3, but is
difficult
-
All Rights Reserved | FIDO Alliance | Copyright 2018 19
COMPANION PROGRAMS
Re use as much as possible from other programs like Common Criteria
• Reduces time, effort and cost of certification for authenticator
vendors, sometimes by quite a lot
Companion programs never cover all FIDO requirements; they were not
developed specifically for authenticators
• Even with advanced companion programs, vendors will have to go
through additional certification with the FIDO Alliance
Companion Program
FIDO Security
Level
Program Status
Common Criteria AVA_VAN 3
L3
Operating
Common Criteria AVA_VAN 4
L3+
Operating
FIPS
L2+, L3
In development
Global Platform TEE Protection
Profile
L2+
In development
Authentication-
specific
Companion program
All FIDO Security Requirements
End-device
configuration
Cryptographic
algorithms
FIDO Specific
-
20
FIDO ACCREDITED LABS
L2
L3, L3+
All Rights Reserved | FIDO Alliance | Copyright 2018
-
All Rights Reserved | FIDO Alliance | Copyright 2018 21
EXPIRATION, DERIVATIVE & DELTA CERTIFICATION
xPhone Asteroid1 32GB
Authenticator v1
xPhone Asteroid1 64GB
Authenticator v1
xPhone Asteroid2 32GB
Authenticator v1
xPhone Asteroid3 32GB
Authenticator v2
Security Requirements 1.2
Security Requirements 1.3
xPhone Asteroid1 64GB
Authenticator v1
Delta Certification
• When the FIDO functionality changes
• Recertification against new
requirements
• After fix to close a vulnerability
• Reevaluation of security is required
Derivative certification
• No change to FIDO functionality allowed
• Surrounding functionality may change
• Packaging & product name may change
• No re evaluation of security
No Expiration
• Certification of a given product never
expires
• Recertification against new versions
of the requirements is optional
Derivative
Delta
Derivative
Delta
xPhone Asteroid1 64GB
Authenticator v1.1
(fixed)
Delta
-
-
- 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 deleted file mode 100644 index c40b381c..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/06-Day-1-Understanding-JWT_CWT-OpenID-and-Related-Ecosystem.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "06) Day 1. Understanding JWT CWT" -header: - teaser: /images/Understanding-JWT-CWT-OpenID-and-Related-Ecosystem.png ---- - - - - -
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
-
ID Token Claims Example
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "0acf77d4-b486-4c99-bd76-074ed6a64ddf",
"iat": 1311280970,
"exp": 1311281970,
"nonce": "n-0S6_WzA2Mj"
}
-
Working Together
OpenID Connect
-
What is OpenID Connect?
• Simple identity layer on top of OAuth 2.0
• Enables RPs to verify identity of end-user
• Enables RPs to obtain basic profile info
• REST/JSON interfaces → low barrier to entry
• Described at
http://openid.net/connect/
-
You’re Probably Already Using OpenID Connect!
• If you have an Android phone or log in at AOL, Deutsche Telekom, Google,
Microsoft, NEC, NTT, Salesforce, Softbank, Symantec, Verizon, or Yahoo! Japan,
you’re already using OpenID Connect
• Many other sites and apps large and small also use OpenID Connect
-
OpenID Connect and Verifiable Claims
• Aggregated and Distributed Claims
• Self-Issued Identities
• Representation of Claim Verification Information
-
OpenID Connect: Aggregated and Distributed Claims
• OpenID Connect Core §5.6.2
• Defines how JWTs can contain claims signed by others
• Issuers of aggregated and distributed claims can be different than JWT issuer
• For example, credit score signed by credit agency and payment information
signed by bank
• Aggregated claims pass 3
rd
party claims by value
• Distributed claims pass 3
rd
party claims by reference
-
OpenID Connect: Self-Issued Identities
• OpenID Connect Core §7
• Digital identity controlled directly by you
• Backed by public/private key pair
• Sometimes called “user-centric identity” or “self-sovereign identity”
• Claims in self-issued identities
• Self-issued claims signed by you
• Aggregated and distributed claims signed by 3
rd
parties
• Implementations in Japan and at Microsoft
-
OpenID Connect: Representation of Claim Verification Information
• Syntax for providing metadata about claims along with claims
• For instance, saying that name, address, and payment info validated by a
particular bank
• At a particular time
• In a particular jurisdiction
• Under a particular legal framework
• Also ways of requesting claims with particular validation information
• New work proposed by Torsten Lodderstedt at most recent IIW
• Ideas contributed to OpenID Connect working group
-
CBOR Web Token (CWT) – RFC 8392
• Binary equivalent of JWT
• Uses CBOR – RFC 7049 – instead of JSON
• Secured with CBOR Object Signing and Encryption (COSE) – RFC 8152
• Can be more compact than JWTs because no base64url encoding
• Good fit for IoT applications and bandwidth-constrained channels
-
IndieAuth
OAuth for the Open Web
Aaron Parecki
aaronpk.com
-
W3C Social Web Working Group
• Chartered to create open APIs for social networking,
to enable social communication on the web
• Active from July 2014 to February 2018
• Identity and authentication was out of scope for REC-track documents
https://www.w3.org/wiki/Socialwg
-
W3C Social Web Working Group
W3C Recommendations Published:
• Webmention
• Linked Data Notifications
• Micropub
• Activity Streams
• WebSub
• ActivityPub
https://www.w3.org/wiki/Socialwg#Specifications
W3C Notes Published:
• Social Web Protocols
• JF2
• Post Type Discovery
• IndieAuth
-
aaron.pk/reader
-
monocle.p3k.io
aaronparecki.com
micro.blog
-
Follow me from Mastodon: aaronpk@aaronparecki.com
-
How can I comment on this
without having an account there?
[blog post, photo, issue, etc]
-
How can I sign in to an app
that lets me post to my account?
-
-
Traditional OAuth
-
IndieAuth: Bring your own identity
-
URLs for Identity
• aaronparecki.com
• mastodon.social/@aaronpk
• gitlab.com/aaronpk
• twitter.com/aaronpk
-
IndieAuth Summary
• User IDs are URLs – bring your own identity
• Applications are identified by URLs – no pre-registration
necessary
• Authorization server is discovered from the user’s URL
• User ID is returned at the end of the OAuth exchange
-
aperture.p3k.io
-
aaronparecki.com
-
aperture.p3k.io
-
IndieAuth Providers
WordPress Plugin Drupal Plugin
micro.blog withknown.com
• Selfauth – PHP
• Dobrado – PHP
• Acquiescence – Ruby
• Cellar Door – Node.js
• Microblog.pub – Python
indieweb.org/IndieAuth
-
IndieAuth Summary
An extension to the OAuth authorization code flow
• Prompt user for their identity (URL input, browser extension
auto-fill, etc)
• Discover user’s authorization endpoint
• Send the user there to ask their permission
• On the redirect back, exchange the authorization code for an
access token and the user’s canonical URL
-
indieweb.org aaronpk.com
Learn More
https://indieauth.net
https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
-
-
- 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 deleted file mode 100644 index e1b7be5c..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/07-Day-1-Breakout-Sessions.html +++ /dev/null @@ -1,13 +0,0 @@ ---- -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.
-
● Align WebAuthn and DIDs for unified experience
○ Reuse mature standards
● Industry adoption of DID-based identities
● What does interop mean for DIDs?
● DID WG formed at W3C
● Usability
● Selective permissionless delegation
● OpenID Connect community working with Ethereum community re
gamification and incentives.
● Value propositions; sub-data flows for business modeling around them
● [missed some, they’re captured on the boards up-front]
○ we have cameras and will photograph the boards
-
-
- 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 deleted file mode 100644 index 8d608f7b..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/08-Day-1-Market-Verticals-Understanding-Current-and-Future-Problems.html +++ /dev/null @@ -1,55 +0,0 @@ ---- -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
-
Province of British Columbia: 4.8 million residents
(small)
Federal
Government of Canada
Provincial
Government of British Columbia (BCGov)
Municipal
Vancouver, Victoria, ...
Indigenous
Nisga’a Lisims Government, Esquimalt First Nations, …
Broader Public
Sector
Regional Health Authorities, WorkSafeBC, Technical Safety BC
ICBC (DMV and Insurance), BC Ferries, ...
Context: Many Levels of Government
Me!
4
-
Context: Government of British Columbia (BCGov) *.gov.bc.ca
● Health, Education, Transportation*, Natural Resources, Justice, Social, Economic
Development, Employment…
● Vital events for people -- birth and death registrations, name changes
● Legal events for organizations -- registration and de-registration etc.
● Professional designations -- regulating bodies, Doctors, Lawyers, Engineers,
Forresters, Architects, Accountants, …
● Licenses and permits -- driving (personal, commercial), harvesting, building,
gasfitting, welding…
● Important Assets - Land Title, Liens, etc
We provide the foundational identity information for our
society and economy.
5
-
Context: BCGov on Digital Authentication and Digital Identity Information
Current (legacy?):
● 30,000 Employees: userid/password
● 1 million accounts for Individual or Business users: BCeID userid/password
● Active directory, enterprise web single sign on paradigm
New:
● BC Services Card as Provincial Identity Information Program
● Fully subscribed* 4.3 million registered people
● Gov mobile app and gov issued EMV chip card - DL or Services Card
● Registered name, date of birth, address as verified identity information
● Careful privacy design, pairwise identifier scheme, conservative roll-out
Newest:
● Verifiable Organizations Network: Hyperledger Indy and friends: vonx.io
● orgbook.gov.bc.ca : Corporate registrations ---> licences, permits, and more
6
-
Perspectives on Strong Authentication
Damned if we (gov) don’t do it
● Corporate controlled or other government
controlled
● No effective recourse or accountability
● Challenges with recovery when lost - if they never
really knew you - how can they fix it?
● Authn services can be a party to every transaction
● UX and public perception
Damned if you do it - self provisioned
● One does not simply “self-provision” (U2F,
SmartPhone Apps for TOTP) - UX
● Challenges with recovery when lost -- who knows
you that can help you?
● We still need to bind your authentication to our
records related to you
7
Damned if we (gov) do it
● Protection / defense obligations are off-the-scale
● Low usage rates -- gov specific secrets forgotten
● Authn services can be party to every transaction
● If we verified your identity at our counter then we
do know you and can help recover lost / stolen --
but is that a bug or a feature?
● There are always users outside our borders -- we
can’t bring everyone to a registration counter
And lastly - lending problem when tied to benefits.
-
Perspectives on Digital Identity Information
8
guid1, Bob, May 15, 1972
guid2, Lou, Dec 9, 1989
guid3, Sam, Jun 21, 1955
Digital-Service.com
api.somegov/idim/namedob
or a callback (same effect)
Lou
Request +
Authorization
Response +
Data
● This is a problem even when it’s Digital-Service.gov
● The api’s know who’s calling/called. Event data is not fun to
manage when personal information is involved
● Calling AnyCompany.com everytime is not much better
● Scaling this into digital economy will be a problem
● Need to issue to Lou and enable Lou to share government
issued identity information without calling back to the gov
every time
Approve Cancel
Hi there! It’s us here at the gov.
Thanks for authenticating now we
remember you. Hi Lou!
Do you want to authorize Digital-
Service.com to call us right now
and get your name and date of
birth?
-
Perspectives on Digital Services, Digital Government, Digital Economy
9
Things you can do that
are not very important
or valuable
Things you need
to do that are
very important
or valuable
Face-to-face
Papers
Fax
Awesome
Digital Services
That Work Great
meh
grrrr
Sweet!
Not possible without
strong authentication and
digital identity information
-- standards and interop --
-
Healthcare
(see PDF)
-
Supply Chain
Jim Masloski
-
W3C WORKSHOP ON STRONG AUTHENTICATION & IDENTITY
SUPPLY CHAIN
(IDENTITY/VERIFIABLE CLAIMS )
INVOLVEMENT OF
ACTORS
PARTIES IN TRANSACTIONS
PARTICIPATION AT
THE PARTY LEVEL
CODIFYING
THE IDENTITIES OF PARTIES AND
THE ABILITY TO MAINTAIN
CONFIDENTIALITY
-
CONSIDERATIONS ON VERIFIABLE
CREDENTIALS
•Availability to the information
•Cross platform application
•Number of parties needing access to different pieces of the
data
•Ability to authenticate the information by responsible parties
•Out of the box thinking on how to build this out in the supply
chain industry
•Take into consideration the legal requirements as they
currently stand in the supply chain arena
-
Legal
Scott David @ScottLDavid
Director of Policy
Center for Information Assurance and Cybersecurity
University of Washington - Applied Physics
Laboratory
-
Law and DIDs
S.O.D.D.I.* in Seattle
Presentation to W3C – Strong Authentication and Identity Workshop
By Scott L. David
University of Washington – Applied Physics Laboratory
Information Risk Research Initiative
December 10, 2018
*SODDI – Is a criminal defense of Mistaken identity: “Some other dude did it”
-
DID Law Fork - Mild vs. Wild Paths
• Two faces of DID legal setting
– Mild or
Wild
-
Mild DID Law Path
-
Mild DID Law Challenge/Opportunity
• Practice = Compliance
– Navigate existing (anachronistic) laws, rules and contracts in DID
• Authority = Past as Precedent (Kojeve)
• Existing law and legal paradigms/institutions
– Varies among national jurisdictions
– Many artifacts of appropriations of capitalism and centralizations of nation state
• Focus on traditional embodiments of value
– “Property” concepts (IP, data “ownership,” etc.)
– Hierarchical governance/liability in organizations based on “causation”
• Value = cost savings of de-risking
– Identity is emerging “cost center” for organization
– Jurisdictional arbitrage-venue shopping
– “Zero-sum game” gestalt
• Identity = locus of (duty and liability) and (rights and value)
• Today’s duties are derived from yesterday’s problems
– Analogies in property law
– GDPR from 1970s era FIPPs
-
Wild DID Law
-
Wild DID Law Challenge
• Secondary effects of Moore’s law (etc.) yielded
downstream
exponential increase in interaction volumes
and densities
• Interactions breed risk
• Risk is increasing exponentially
• Existing laws/institutions are not built to de-risk these new
interaction phase spaces
– Distributed flows blind hierarchical organizations
• Yesterday’s Institutional (and individual) existential
narratives dissipate
• Challenge/Opportunity is to “re-intermediate” interactions
with new DID-based structures and narratives
-
Wild DID Law Opportunity
• Practice = Innovation
– Create new containers and pathways for intangible value flows
• Authority = Future Opportunities (Kojeve)
• New “unmapped’ complex shared risk space
• Bridge from old solutions to new solutions
– Old laws to new contracts
– Old institutions to distributed organizations
– Bridge as capitalism and nation state cede power/meaning to distributed structures
• Focus on newly available measurements to establish value
– Focus on measuring relationship (metrics for edges, not nodes)
– Focus on value extraction when data is converted into information – Meaning integrity
• Value = profit center of leveraging relationships (and de-risking)
– Efficiencies of avoiding avoidable harms
– Identity as profit center for organization
– Contracts to release legal jurisdictional arbitrage
– “Non-Zero-sum game” gestalt in new complex interaction spaces
• Identity = embodiment of relationship
– Information creates us, not vice versa
• Duties are derived from projections of tomorrow’s opportunities
– Analogies in early IP, derivatives markets, arbitrage instruments
–
-
Wild DID Law – Identities are Key
• Identities (of people, entities and things) are the key in distributed
systems.
• Each has multiple simultaneous identities (all relationship based)
• Why did “identity” get distributed?
– Paul Baran diagram (shown later) shows dissipated institutional power
– Much “identity” is based on relationships with institutions.
• With DIDs, distributed power/institutional structures
– Not a lot of precedent
• Not like co-ops – not hierarchical
• Need new institutional information and risk sharing structures
• Biological systems yield helpful models
• Resilient distributed structures grow organically
– Self-assembly among multiple similarly situated stakeholders. (COIs)
– Recognize that not starting from entirely clean slate
– Appropriations of late capitalism will continue to operate (In our souls)
– If aware of this, can design to harness that “energy of mutual appropriation”
–
•
-
Risks Create Organisms and Organizations
• What are current and emerging DID practices?
• What are processes to create feedback loops
to refine and develop those practices?
• “Rule of law is as much about process as
substance
– Due process (5
th
and 14
th
amend).
• Substantive
• Procedural
-
4 Step Ladder of Institutional Construction
• Processes of institutional construction/law are
built from practices
– Practices
• Adopt as rule (legislative/contract process)
– To get
– Best Practices
• Apply enforcement (judicial/enforcement process)
– To get
– Standards
• Include operations (executive/operating process)
– To get
– Institutions
-
How harvest/create practices for
socio-technical DID systems?
• Tools and Rules
– Technology Tools
– Legal Rules
• For “Tools” measure performance of tech against
specifications
– Process is Technical Standard setting
• Output is specifications (and IP DMZ)
• For “Rules” measure performance of people and
institutions against rules, laws, norms, etc.
– Process is creating public and private enforceable duties
• Legislative processes (and APA for regulations)
• Contract negotiation processes
-
What Measurements Needed for DID Tools and
Rules Development?
• What risks and what performance metrics are relevant for reliable DID systems?
– Data?
– Information?
– Identity?
– Other?
• You can’t protect it if you don’t know (or agree) what “IT” is
• We measure risk into existence
– The threat is present in the system
– Our measurement/observation allows us to perceive and mitigate risk
• Carcinogens – capacity to mutate is already present in system
• All financial collapses in US and UK since 1800 – Seeds of all financial collapse
are sown in response to prior crisis
• All IP – Create property narrative to enable accumulation (retard dissipation)
-
So, what specifically should we measure
to reduce emerging DID interaction risks?
(recalling that “what gets measured gets done”)
-
DID Stakeholders need reliable and shared
qualitative metrics to reduce risk
-
Sic Hunt Dracones
-
Taming the DID Wild Law Path
• Risks compel de-risking
practices
– What do different sorts of
emerging threats and
vulnerabilities suggest
about future DID
practices?
• Invite DID solutions for
13 information risk trends
-
Global Identity/Information Risk Trends
• 13 global risk trends include:
– Secrecy is Dead (but privacy and security are not)
– Distributed Information Architecture (blinds hierarchical organizations)
– Complexity (is its own “sovereignty”)
– Socio-Technical Systems (force non-technical variables into system design)
– Information Democratization (collapses scale & alters security paradigms)
– Data Technology is Dual-Use (it can be used for bad or good)
– People are “Data Producers” (without institutional support)
– Big Data Insights Invert (and Re-Invent?) Critical Analysis
– “Synthetic Intelligence” (is a Counterforce to AI)
– The Internet Is Not a Public Park (it is privately operated commercial space)
– Data is Not Information
– Power Laws In Bureaucracies Make Security-By-Secrecy Un-Economic
– AAA Risks Threaten Information Systems
-
Death of Secrecy
(the insight/intrusion “slider”)
• Secrecy died from vast system technical
interoperability and collective quest for
insight
– Insight of observer is intrusion to observed
-
Distributed Information Architectures
Render hierarchies blind
-
The Sovereignty of Complexity
Statistical outliers can be artifacts of misapplied Gaussian
distribution models
-
Socio-Technical Systems -
force non-technical variables into security design
-
Information Democratization Collapses Scale
Invites consideration of scale-independent policies
for fractal structures
-
Data Technology is “dual use”
It can do harm or good
(Like Nitrogen-Based Fertilizer)
-
People are Data “Producers”
Without Institutional Support
-
Big Data Insights Invert
(and Re-Invent?) Critical Analysis
-
Synthetic Intelligence
Is a counterforce to the existential anxiety caused by AI
-
The Internet is Not a Public Park
It is a privately-operated commercial space
-
“Data” is Not “Information”
Many system architecture problems dissipate when the
distinction is applied
-
Power Laws In Bureaucracies Raise
Secrecy/Reliability Costs
-
“AAAA” Threats to Identity/Information
Systems
Attacks, Accidents and Acts of Nature
-
Good Luck
• Let’s continue the conversation
•
sldavid@uw.edu
• @ScottLDavid
-
John Fontana
-
-
- 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 deleted file mode 100644 index 41611796..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/09-Day-2-Procedural-Agenda-Gardening.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -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
-
Manu re Credentials CG and DID chartering proposal
CCG proposed DID WG charter, focused on data model
https://w3c-ccg.github.io/did-wg-charter/
CG is also doing experiments around protocol, resolution
About 15 different DID methods, think we’re ready to standardize data model
Slide deck on DID progress,
https://docs.google.com/presentation/d/18cDpqkPhlGKcOlgnbt2_2PbFoNv0vryXo
pp5rIG8A0o/edit#slide=id.gc6f80d1ff_0_0
-
-
-
- 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 deleted file mode 100644 index c8367c63..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/10-Day-2-Exploring-Cultural-and-Economic-Perspectives.html +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "10-Day-2-Exploring-Cultural-and-Economic-Perspectives" -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”
-
4
① Japanese "fragmented" ID Platforms
Fragmented ID Platforms established by Japanese big companies (Cont.)
• Japanese Big Companies often become to diversified “Conglomerate”.
(…and often issue their own credit card as “issuer” and provide “mileage” to their users.)
• This situation is mainly due to “loose” regulation to prohibit other business for Big Companies
in Japan.
Department Store
Supermarket
Real Estate
Developer
Construction
company
Bus Operator
International
AirPort
Ex.1: Railways Company
Ex.2: Mobile Carrier
Hotels
Education
(Univ. etc)
Electricity
Railways
Mobile Carrier
Retail Financial
service
Online Banking
Cable TV
Life Insurance
E-Commerce
Electricity
Non-life
Insurance
Education
E-Money
-
5
① Japanese "fragmented" ID Platforms
Fragmented ID Platforms established by Japanese big companies (Cont.)
• In some area, Japanese local services can compete against Facebook and Amazon today.
• Based on this situation, Japanese “old type” big companies think;
“GAFA is very strong, but Japanese market have not occupied by them.”
E-Commerce (Share of B2C Trading volume )
≒
SNS (Monthly Active Users)
<
30,000,000 76,000,000
20% 20%
[Sources]Gaiax (2018), Jetro (2017)
-
6
① Japanese "fragmented" ID Platforms
Fragmented ID Platforms established by Japanese big companies (Cont.)
• ..as the result, everything become “fragmented” in Japan.
(when they want to tie their customer to their ecosystem, the easiest way is tying their customer to their payment method with
their own mileage program.)
..and today, third party QR Payments are additionally joined.
Rakuten
Ex.: Payment Method Acceptance (at Seven-Eleven)
(Prepaid)
(Credit Card including Contactless)
Railways
Seven-Eleven
-
7
① Japanese "fragmented" ID Platforms
Lack of Interoperability between Platforms
• Japanese Big Companies like to establish their “Original Format” Platform.
• And they want to keep(enclose) their data on their Platform.
Ex: Large Railways said
“we connected our mobile
APP to share time table of
every companies!”
…but just jumped to each
companies’ website...
[Source]app-renkei.jp
-
8
② Lack of Central Social ID system in Japan
Heavily dependent on Driving License for KYC process
• Almost of KYC process in Japan, Driving license has taken up dominant position.
Ex: Issuing Credit Card
First Priority:
Driving license
If don’t have Driving license,
can choose from; passport,
“My Number” card,
residence certificate etc.
[Source]JCB
-
9
② Lack of Central Social ID system in Japan
Failed "My number (Japanese social security and tax number system)" expansion
• Japanese government want to expanding usage of “My Number” card for Japanese Social ID
system.
• …but today, almost of Japanese people don’t use “My Number” as Social ID card.
(Only 10% of Japanese people have “My number” card.)
Storing Digital
Signature that can
use Public KYC
…and it can be
readable from some
of Android devices by
using NFC reader.
It is able to request
issuing “My number”
card from vending photo
machine.
(It sounds convenient! )
…but it takes about 1.5
months to get “My
number” card from local
government.
[Sources] Ministry of Internal Affairs and Communications, DNP
-
10
③ My Opinion
Necessity of “loose” ID federation in Japan Market
<From Companies Strategy>
• Some companies (I assume NTT docomo, Yahoo Japan and Line) want to take up a dominant position of
“Social ID login”. (of course, including Facebook and Google)
• But, I assume Japanese “old type” big companies don’t want to establish “external strongly centralized ID
Hub” because they want to stand directly in front of their customer.
<From current situation of KYC process in Japan>
• Japanese KYC Process is heavily depend on drivers license and “verified” (and met AML law regulation)
KYC data is stored only at Banks or Credit card Companies in general.
• When the sharing economy is expanding, I assume AML regulation is critical problem, but most of
companies (expecting Financial Institutions) don’t have such data.
• In Japan, I assume “Loose” ID federation between companies, financial intuitions and
governmental bodies is needed.
• To realize this concept, the scheme for DIDs and Self sovereign (especially on consent
management) will become Key Module.
-
11
③ My Opinion
Basic use case
Car Share Platform
Car Owner
Register to Car Share Platform
User
Use the car through the Platform
Pay Fees
• Today, Boryokudan (Japanese Mafias) isn’t prohibited strictly buying cars from car dealers.
(Actually in Japan, Boryokudan member ride cars normally)
• When the scheme described above is worked, Boryokudan can get money by lending their car.
(From AML view, this is not permitted)
• I assume Car Share Platform Provider want to get KYC information of Car Owner and User
easily.
Get Money
-
Thank you for your attention!
-
Automatic Identification Standards
Shigeya Suzuki, Ph.D
Associate Director, Technology Officer, Blockchain Laboratory, Keio Research Institute at SFC
Associate Director, Auto-ID Lab Japan, Keio Research Institute at SFC
Project Associate Professor, Graduate School of Media and Governance, Keio University
shigeya@wide.ad.jp
11 November, 2018 @ W3C Workshop on Strong Authentication and Identity
-
UPC
-
2016
UPC to Product Information
• “323900039629”
15
https://www.target.com/p/vicks-vapocool-medicated-throat-drops-menthol-50ct/-/A-75557582
-
2016
GS1 Standards
• Identify, Capture, and Share
• Identify: Standards for the identification of items, locations,
shipments, assets, etc. and its associated data
• Capture: Standards for encoding and capturing data in physical
data carriers
•
Share: Standards for sharing data between parties
16
https://www.gs1.org/docs/architecture/GS1_System_Landscape.pdf
-
2016
GS1 Identification Key
• Identify either class or instance
• Unique and unambiguous within their domains
• Domains includes, not limited to:
– Trade items (i.e., Global Trade Item Number — GTIN)
– Logistic units (i.e., Serial Shipping Container Code — SSCC)
– Assets (i.e., Global Individual Asset Identifier — GIAI)
– Locations (i.e., Global Location Number — GLN)
17
-
2016
GS1 Identification Key
• Trade items (i.e., Global Trade Item Number — GTIN)
• Logistic units (i.e., Serial Shipping Container Code — SSCC)
• Assets (i.e., Global Individual Asset Identifier — GIAI)
• Locations (i.e., Global Location Number — GLN)
18
urn:epc:id:sgtin:CompanyPrefix.IndicatorPlusItemReference.SerialReference
urn:epc:id:sscc:CompanyPrefix.ExtensionPlusSerialReference
urn:epc:id:giai:CompanyPrefix.Individual AssetReference
urn:epc:id:sgln:CompanyPrefix.LocationReference.Extension
-
2016
Physical Representation
• Barcode
• RFID
19
-
2016
Application: Authenticity Verification
• New, soon-to-be-standard:
“GS1 Lightweight Messaging Standard for Verification”
• REST-like query interface,
results in JSON (new in GS1 Standards),
GS1 Keys embedded in URL
• Resolver resolve the results
• Use case: US Drug Supply Chain Security Act (DSCSA)
compliance
20
-
2016
Difficulty on Resolving Services
• Object Naming System (ONS)
– DNS Based (part of) GS1 Key to server mapping service
– Not used other than research purpose
• Discovery Services
– Centralized service to provide GS1 Key to servers mapping service
– Design work suspended until there is a well-defined demands from
industry
• But.. Lately, there is renewed interest in mapping between
identifiers and associated data, together with verification of
identifiers
21
-
2016
Difficulty and Possibility
• GS1 is the standard on product and business entity identification
• DID focuses on digital identity
• We need cyber-physical link other than human
• Allow to use broader range of IDs (including GS1 Keys) in “id”
fields makes DID related standards more interesting
• There is a good intersection between both of the works
– i.e., Product authenticity proof without accessing servers
22
-
-
- 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 deleted file mode 100644 index b75fef54..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/10.3-Day-2-PindarWong_1.html +++ /dev/null @@ -1,31 +0,0 @@ ---- -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
-
Scaling The Next Billion+:
Sovereign Identifier Systems - India
● Aadhaar, 10 year old, 12 Digit Identifier
● Stats:
https://uidai.gov.in/aadhaar_dashboard/auth_trend.php
○ https://uidai.gov.in/
○ http://indiastack.org/
● Supreme Court Constitutional Ruling:
“It is better to be unique than the best. Because, being the best makes
you the number one, but being unique makes you the only one.” --
26 Sept Supreme Court of India Judgement - Constitutionality
-
Scaling The Next Billion++
Sovereign Identifier Systems - China
●
社會信用體系 - Social Credit System (Public Private Partnership)
●
Real Name Electronic ID ( http://eid.cn/ ) and CTID (CyberTrusted ID)
● Deployment Pathways: TechFin
○ Alibaba (AntFinancial - Technology Provider (Alipay)):
○ Tencent (WeChat Pay - WeiXin 800 million active users)
● Deployment Pathways: FinTech ( Traditional Banks - Union Pay)
● Common CLOUD and Carrier Services (Mobile)->
○ De-risking and Externalizing Costs associated with Identity Responsibility and Risk for Digital
Generation (DiDs)
●
Identities issued by the government to citizens for identifying identity
online and offline
○ Bank Smart Card (Distributors)
○ SIMeID (Mobile)
● Hong Kong new e-ID Card: Deployment Starting this month (8 million)
-
Source: http://beltandroad.hktdc.com/en/belt-and-road-basics
Belt and Road Blockchain
Soft Infrastructure for China’s Belt and Road Initiative (BRI)
EG. 90% By Sea
Tradelens by Modern Terminal +
Maersk + IBM
-
CHANGING ARCHITECTURE: Game Changer?
‘Hong Kong’ Barnyz CC-BY-NC-ND 2016
Change in
1) Market Structure,
2) Business Models and
3) Competitive Landscape
-
WHAT ARE FUNDAMENTAL TENSIONS?
‘Tension’ Domiriel CC-BY-NC 2012
-
Liberté, égalité, fraternité
WestPhalia
1648
Ice
Fire
EastPhalia
2047
?
Bordered and Sovereign:
Territoriality Principle
No One Above The Law
Borderless and Self-
Administered: ‘Functionality
Principle’
No Nation Below Mathematics
-
The Belt and Road Blockchain :
Public Governance Private Business
BLEI
BLEI BLEI BLEI
BLEI
BLEI
Public Governance - BRBC Immutable Change of State for Liability
Private Business - Detailed Transaction Data ( Halal Blockchain A)
Private Business - Detailed Transaction Data ( Blockchain B)
Private Business - Detailed Transaction Data ( Blockchain C) etc.
Private Business: Your Transaction Blockchain/Settlement Network
SA-IDs
-
Hong Kong: Emerging Separation of Concerns
1) Public and Border Security: Public Governance (‘Golden Source’)
Legal Identifier, Accountability and Confidence (tangible physical border)
2) Commercial and Day-to-Day: Private Business (‘Golden Copies’)
Functional Identifier(may or may not necessary have PII),
Self-Administered Identifier (Cloud+Mobile)
Cryptographic Consistency and ‘Confidistance’ - (Intangible data border)
-
Borderless
Communities:
‘Ice’
Cryptographically
Strong
Static ‘Violence’
Sovereign
States:
‘Fire’
Dynamic
‘Violence’
-
Legal Certainty
“Rule of Law’
Eastphalia 2047: The Internet’s New Legal Layer
Cryptographic
Consistency
“Rule of Code”
-
Law and Borders: Lawful Legal Standing
Legal Person
Natural Person
Algorithmic Liability ( Estonia ‘Kratt’ Law)
A different ordering principle?
Decentralized != Disorganised
Coordinate without Communicating
-
The Post-Internet, Post-Bitcoin Era
-
Distance != Cost
Centralized != Trusted
Time !=
Money
The Fundamental Assumptions ...
-
Changing Architecture: PULL → PUSH
‘PUSH’ Daremoshiranai CC-BY-NC 2014
Analog Supply Chains -> Digital Demand Chains
-
3D Printing Technology @ Siggraph , 8 August 2011 by Kyle Pierce https://creativecommons.org/licenses/by-
sa/2.0/
Digitizing Global Trade
ICE: 23/11
Black Friday ->
Cyber Monday
USD 7.8 Billion?
FIRE: 11/11
Singles Day
USD 30 Billion?
-
Kaizen: Japanese (Change for Better)
Predictable Incremental Improvements over
Time -> Incremental Efficiency
Low Risk
FIRE
-
Unpredictable Breakthrough Improvement
Proposals -> Massive Efficiency and Massive Risk
http://tw.tartoo.com/self-breakthrough.html
ICE
-
Fire and Ice
Poem by Robert Frost ( 1874-1963)
Some say the world will end in fire,
Some say in ice.
From what I’ve tasted of desire
I hold with those who favor fire.
But if it had to perish twice,
I think I know enough of hate
To know that for destruction ice
Is also great
And would suffice
-
ConfiDistance
Selective Transparency
Don’t Trust Verify
22
Emerging Principles?
-
End References
https://www.coindesk.com/blockchains-
killer-app-making-trade-wars-obsolete/
https://www.youtube.com/watch?time_c
ontinue=9&v=L7CuuLYi0Ik
https://youtu.be/e7Pq6WQuVTQ?t=276
37
a) Making Trade Wars Obsolete
a) CES 2018 - HK Belt and Road
Blockchain Consortium
a) Berlin T20/G20 Process 2017
-
-
- 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 deleted file mode 100644 index 50d7705c..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/11-Day-2-Avoiding-Mistakes-and-Minefields.html +++ /dev/null @@ -1,28 +0,0 @@ ---- -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
-
Protocol / System Design Time
● Carefully define terminology and use it consistently
○ e.g., do you use the terms names and identifiers ?
○ Are they explicitly the same?
○ If not, what are the precise differences?
-
Protocol / System Design Time
● Carefully define terminology and use it consistently
○ e.g., do you use the terms names and identifiers ?
○ Are they explicitly the same?
○ If not, what are the precise differences?
● E.g.: names are fungible and non-unique, while identifiers are unique and
persistent
-
Protocol / System Design Time
● Carefully define terminology and use it consistently
○ e.g., do you use the terms names and identifiers ?
○ Are they explicitly the same?
○ If not, what are the precise differences?
● E.g.: names are fungible and non-unique, while identifiers are unique and
persistent
e.g.:
https://www.w3.org/TR/webauthn/#terminology
https://w3c-ccg.github.io/did-spec/#terminology
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
-
Component Implementation Time
(eg, in libraries/packages, clients, servers)
c.f. The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software
● We demonstrate that SSL certificate validation is completely broken
in many security-critical applications and libraries. [...]
[...] The root causes of these vulnerabilities are badly designed APIs
of SSL implementations (such as JSSE, OpenSSL, and GnuTLS)
and data-transport libraries (such as cURL) which present developers
with a confusing array of settings and options.
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
● are the employed underlying technologies secure? (see prior slide)
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
● are the employed underlying technologies secure and securely employed?
(see prior slide)
● Having a carefully designed deployment architecture...
○ even though given high-level authentication and identity technologies, integrating them into
delivered systems is typically non-trivial
○ e.g.:
Stanford Registry & Directory Infrastructure: A Case History
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
● are the employed underlying technologies secure and securely employed?
(see prior slide)
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
● are the employed underlying technologies secure? (see prior slide)
● Having a carefully designed deployment architecture...
○ even though given high-level authentication and identity technologies, integrating them into
delivered systems is typically non-trivial
○ c.f.: Stanford Registry & Directory Infrastructure: A Case History
● Specific actual examples on following slides from deployer of federated
identity
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
1) SP's requesting ForceAuthN but then not checking the concurrency of the values sent
back by the IdP (ie its not a fresh re-auth) but assuming it is (oops!) [see prior slide 7]
2) SPs assuming "principal name" is an email address - or using such fields as the prime
account ID where recycling of those values can occur at the IdP end over time...
3) the particular values of eduPersonAffiliation (student,staff,faculty,employee etc) are
arbitrarily decided by each site in a federated world and dont mean the same thing across
regions.
4) assuming all federations operate in the same way across the world (particularly when
interfederated with eduGAIN - other rules of play are involved
-
Deployment Time
(i.e., by Relying Parties, Service Providers, Identity Providers)
5) wanting to use the best and up to date security algorithms
loads of partners in federation space are not following BCP and there's a lowering of
average level (for those with REALLY out of date stuff, you just have to remove them
from your relationship)
6) users are easily confused with all the stuff
the interface MUST be simple for selection of Identity Provider and logging in page.
Decent education is needed to ensure users dont just think they can type institutional
id/password into any random user/pass field on the internet!
-
Overall: Trust Does Not Scale
i.e.:
"trust does not automagically scale across arbitrary policy domains"
-
Overall: Trust Does Not Scale
i.e.:
"trust does not automagically scale across arbitrary policy domains"
corollary:
"scaling trust across distinct policy domains requires specific agreements
between the policy domains regarding (at least) the definition of trust,
requirements for attaining degrees of trust, and what it is that is trusted."
-
Overall: Trust Does Not Scale
i.e.:
"trust does not automagically scale across arbitrary policy domains"
corollary:
"scaling trust across distinct policy domains requires specific agreements
between the policy domains regarding (at least) the definition of trust,
requirements for attaining degrees of trust, and what it is that is trusted."
e.g.:
NIST.SP.800-63-3 is an attempt at defining such policy agreements
across USGov agencies.
-
Further thoughts...
Consider implementing a simple design satisfying simple use case(s), and trying it
out in practice, before attempting to "finalize" the specification. Iterate WRT
satisfying more complex use cases and updating the specification.
-
● flexitility -- build something that is nominally useful yet malleable such that
can evolve to satisfy further use cases
-
TODO: Diagram: (hourglass shape)
1995: 10s of home-grown web SSO and identity approaches
2001: SAML v1
Now: fewer than some number, say ~ 10 or 15?
● SAMLv2
● OIDC
● WS-Federation et al
● OpenID v2 and v1
● ?
-
-
- 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 deleted file mode 100644 index be1a5f8f..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/12-Day-2-Breakouts.html +++ /dev/null @@ -1,10 +0,0 @@ ---- -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 deleted file mode 100644 index 737b866c..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/13-Day-2-5-Year-Roadmap-DIDs_-VCs_-and-Attestations.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -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
+
-
Decentralized Identity Stack
4
● DIDs – Root Identifiers …
● Raw Data – Observed facts & transactions
● Verifiable Credentials – Assertions by knowable authorities
● Profiles / Presentations / Persona – Representations of individuals
● Consent – Records of authorization
● Reasoning – Interpretation & Analysis
● Evaluation – Risk Analysis & Reputation
● Understanding – Internal knowledge representation
● Services – Interactions of value
-
Potential Technologies for Future Work
5
● DID-Auth (Authn/Authz)
● OCAP (Authz through Object Capabilities)
● Credential Requests & Exchange
● Data Minimization & Selective Disclosure
● Consent & Consent Receipts
● Storage (Identity Hubs) & Internal Representations
● Analytics & Algorithms for Evaluation
● Cryptographic Proofs
○ Signature, Encryption, Signcryption Suites
○ Time-stamping
○ Zero-knowledge proofs
-
https://w3c-ccg.github.io/roadmap/diagram.html
-
-
- 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 deleted file mode 100644 index 74a96628..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/13.5-Day-2-Attestation-Arm.html +++ /dev/null @@ -1,13 +0,0 @@ ---- -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)
-
Roadmap
– EAT is the starting point
– Interoperability Model
– Trust Model(s)
– Protocols
• Remote Attestation
• Integration with Enrollment / Credentialing /
On-boarding
• Integration with Authentication
• Integration with Authorization
-
Parting thoughts
– Increasingly disaggregated systems (Cloud, IoT,
Web) with many components.
– Attestation is a building block for trust in
connected systems.
-
-
- 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 deleted file mode 100644 index 8d6b13a6..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/14-Day-2-5-Year-Roadmap-Authenticators.html +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "14) Day 2. 5 Year Roadmap Authenticators" ---- - - - -
©Veridium All Rights Reserved
Authenticators
-
Convergence
2
-
-
Source:
StorageCraft
-
2410-2017 platform configuration options (ISO 24745)
5
Storage
Matching
Mobile
Server
Mobile
฀
(FIDO UAF, WebAuthN)
฀
Server
฀
฀
Shares
(both mobile and server)
฀
฀
©Veridium All Ri ghts Reserved
-
6
©Veridium All Ri ghts Reserved
Storage
Matching
Mobile
Server
Mobile
฀
(FIDO UAF, WebAuthN)
฀
Server
฀
฀
Shares
(both mobile and server)
฀
฀
2410-2017 platform configuration options (ISO 24745)
-
Storage
Matching
Mobile
Server
Mobile
฀
(FIDO UAF, WebAuthN)
฀
Server
฀
฀
Shares
(both mobile and server)
฀
฀
7
©Veridium All Ri ghts Reserved
2410-2017 platform configuration options (ISO 24745)
-
-
1. Biometrics Should Be Stored at the Edge
2. Biometrics Should Never Be Stored on a Blockchain
3. Biometrics Can Be Accessed Via a Blockchain
4. Biometrics Should Be Under A User’s Control
5. Biometrics Traits Should Be Reliable
6. Biometrics Are Part of an Ecosystem
-
Biometric DID Authentication with IEEE 2410-2017
© 2018 Veridium IP Ltd. All Rights Reserved. 10
RP
DID
(with VID address,
uid & JWT
encrypted with
privkey & RP’s
pubkey)
uses
did-auth-relyingparty
Universal
Resolver
DID
DID doc
(with pubkey)
VeridiumID
uid
(decrypted with
pubkey in DID doc
and server privkey)
session
push notification
blockchain
1
2
3
4
5
7
6
auth result
-
11
©Veridium Al l Ri ghts Reserved
-
-
- 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 deleted file mode 100644 index 67fe2a5f..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/14.5-Day-2-5-Year-Roadmap-Authenticators_-Gemalto.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -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
-
3D Secure, the natural solution to comply with PSD2
E-SHOP
ISSUER
CUSTOMER
1. Checkout
DIRECTORY
SERVER
2. Authentication request
3. Authentication
4. Authorization Request
…
NETWORK
4. Authorization
Request
-
« Due to 3DSecure for PSD2, we expect our
conversion rate to decrease by up to 10-15% »
Bilal El Kouche, Head of Payments at vente-privee
(#3 online retailer in France)
-
The real solution: let Merchants keep control of the
UX:
Delegated authentication
-
-
-
- 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 deleted file mode 100644 index 98f861a3..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/15-Day-2-Browsers-work-with-Authentication-and-Identity.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -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.
-
Authentication has two core user journeys
WebAuthn / FIDO2 enables multiple use cases
02
Re-Authentication
User does a repeat authentication to a service
...The next slides will walk through these user journeys as a user might
encounter them on the web
01
Bootstrap
User authenticates to a service for the first time
-
Elisa opens launches her
mobile browser, Chrome,
and goes to
Tri-Bank
1. Registering built-in authenticator for reAuth
(mobile web)
Request
UV=true
X-Plat=false
Result
credential
(internal,caBLE)
-
Request
UV=true
X-Plat=false
Result
credential
(internal,caBLE)
1. Registering built-in authenticator for reAuth
(mobile web)
She signs in with her
username and password
(+potentially other factors)
-
1. Registering built-in authenticator for reAuth
(mobile web)
Tri-Bank shows a promo
asking Elisa if she wants to
opt-in to use Fingerprint
to sign-in.
-
Elisa comes back to Tri-Bank in another session
-
2a. Using built-in authenticator for reAuth
(mobile web)
The next time Elisa
opens Tri-Bank on
mobile browser, she
gets a fingerprint dialog
Request
credentialId
(internal)
-
2a. Using built-in authenticator for reAuth
(mobile web)
Using only her fingerprint,
she’s able to sign-in
without using her
username + password on
mobile web
Request
credentialId
(internal)
-
11
Using built-in authenticator for reAuth (native mobile app)
Elisa downloads Tri bank from
the Play Store, she
launches
the app for the first time
to
sign in
to check her funds
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
Request
UV=true
X-Plat=false
Result
credential
(internal,caBLE)
2b. Using built-in authenticator for reAuth
(native mobile app)
She installs Tri Bank from
Google Play Store and
opens the app
-
2b. Using built-in authenticator for reAuth
(native mobile app)
Elisa chooses sign in
and also
chooses an
account.
Request
credentialId
(internal)
-
2b. Using built-in authenticator for reAuth
(native mobile app)
Elisa now is asked to
authenticate
with the
fingerprint dialog
-
15
Cross-Platform Bootstrap
Elisa wants to sign in
to her bank on her
desktop computer
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3i. Cross-Platform bootstrap
Elisa chooses to sign-in
on her
desktop browser
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3i. Cross-Platform bootstrap
Elisa enters her account
username and chooses
to proceed ‘next’
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3i. Cross-Platform bootstrap
She’s asked to verify
the new device using
her phone fingerprint
that she’s been using
to sign-in to Tri-Bank
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3ii. Cross-Platform bootstrap
Because Elisa has a
Macbook with Touch ID,
Tri-bank can asks her if
she wants to use local
fingerprint on the
device.
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3ii. Cross-Platform bootstrap
Elisa gets prompted to
try using the local
fingerprint on the
device.
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
3ii. Cross-Platform bootstrap
She opts-in and
continues to her
account
-
...when Elisa comes back to Tri-Bank on the Macbook Pro
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
4. Using built-in authenticator for reAuth
Elisa comes back to
sign-in
on her desktop
browser
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
4. Using built-in authenticator for reAuth
A fingerprint dialog
appears
above the sign-
in page and
Elisa
touches the sensor
-
Request
credentialId
(internal)
Request (Alternative)
{empty credentialId}
Will result in prompt to insert removable
SK
4. Using built-in authenticator for reAuth
Elisa’s identity is
accepted
and she’s
signed in!
-
Note that we’re inheriting the
strength of the credentials from
the initial bootstrap.
-
Summary
Web Authentication
Simple - avoid typing, avoid passwords, minimal decisions
Secure - passwordless, multi-factor, phishing-resistant
Steven Soneff -
sso@google.com
Web Platform Product Manager
-
-
- diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html b/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html deleted file mode 100644 index b1eb8e9b..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/Health-Care-IDology.html +++ /dev/null @@ -1,16 +0,0 @@ ---- -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
-
What needs an identity?
§
payers
§
providers
§
data
§
patients
2/3
-
What needs an identity?
§
payers
§
providers
§
data
§
patients
2/3
-
What needs an identity?
§
payers
§
providers
§
data
§
patients
2/3
-
δεῖξις (1) mode of proof; (2) proof, specimen; (3) display,
exhibition
deixis (1) designating words relating to the time and place
of utterance; (2) proving directly
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 deleted file mode 100644 index 924ea7c6..00000000 --- a/collections/_2018-W3C-Authentication-Identity-Workshop/Use-Case-21-with-FIDO-Proof-of-Presence-Key.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -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
-
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
-
-
- diff --git a/collections/_2018-W3C-Authentication-Identity-Workshop/W3C Strong Authentication and Identity Workshop Report.docx b/collections/_2018-W3C-Authentication-Identity-Workshop/W3C Strong Authentication and Identity Workshop Report.docx deleted file mode 100644 index 339ccc28..00000000 Binary files a/collections/_2018-W3C-Authentication-Identity-Workshop/W3C Strong Authentication and Identity Workshop Report.docx and /dev/null differ