├── README.md ├── hasec-charter.html ├── hb-secure-services ├── 160426-27_W3C_HWSec_Telekom.pdf ├── 2016-04-26_Morpho_W3C_UseCases_v1.pdf ├── SafranIdentitySecurity_Authorization-model-for-Javascript-usage-of-hardware-based-keys.pdf ├── W3C_hb_secure_services_gemalto.pptx ├── etherpad-04-26-27.md └── transaction_confirmation.jpg ├── hbss.html ├── hwsec-charter.html ├── security-roadmap.md ├── w3c.json └── web-authentication-charter.html /README.md: -------------------------------------------------------------------------------- 1 | This git repository contains W3C Web Security documents and draft charters. 2 | 3 | * [security-roadmap](https://github.com/w3c/websec/blob/gh-pages/security-roadmap.md), an Oct 2015 overview of activities at W3C 4 | * The Web Authentication WG launched February 8, see https://github.com/w3c/webauthn 5 | * [hasec-charter](https://w3c.github.io/websec/hasec-charter), a draft charter for a Hardware Security WG; obsoleted by ongoing work in [Hardware-Based Secure Services CG](https://www.w3.org/community/hb-secure-services/) 6 | * [hb-secure-services](https://github.com/w3c/websec/tree/gh-pages/hb-secure-services) Hardware-Based Secure Services docs 7 | -------------------------------------------------------------------------------- /hasec-charter.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | Draft Hardware Security (HaSec) Working Group Charter 7 | 8 | 10 | 12 | 13 | 14 |
15 | 25 |

W3C

29 |

DRAFT
30 | Hardware Security (HaSec) Working Group Charter

31 |

STATUS: Obsolete. This draft charter was reviewed in March-April 2016 and not approved at that time. Related work 32 | continues in the Hardware-Based Secure Services Community Group.

33 |

The mission of the Hardware Security Working Group, 34 | part of the Security Activity, is to define a set of Hardware-Based Web Security standard APIs providing Web Applications access to secure services enabled by hardware modules

35 |
36 |

Join 37 | the Hardware Security Working Group.

38 |
39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 49 | 50 | 51 | 52 | 58 | 59 | 60 | 62 | 63 | 64 | 65 | 66 | 71 | 72 | 73 |
End date31 December 2016
ConfidentialityProceedings are Public. 48 |
Initial Chairs 53 |
    54 |
  • Virginie Galindo, Gemalto
    • 55 |
  • David Rogers, Copper Horse
    • 56 |
57 |
Initial Team Contacts
61 | (FTE %: 20)		Rigo Wenning
Usual Meeting ScheduleTeleconferences: Teleconferences to be held approximately 67 | weekly or biweekly as required. 68 | Task Forces may have separate calls that will not overlap with 69 | others.
70 | Face-to-face: Up to 3 per year as required
74 |
75 |

Goals

76 |

The Hardware-Based Web Security Working Group will develop 77 | recommendation-track documents that define a standard to provide 78 | secure services for high security Web applications.

79 |

There are a number of use cases that this standard will enable, 80 | including but not limited to the ability to encrypt and to decrypt 81 | data using hardware based encryption modules, the ability to 82 | manage credential information for hardware based security modules, 83 | and the ability to access specific security sensitive services 84 | offered by hardware tokens. Such security sensitive services may 85 | include:

86 |
    87 |
  1. Payments – transaction authorization
    2. 88 |
  2. Identity verification
    3. 89 |
90 |
91 |
92 |

Scope

93 |

94 | This Working Group’s scope is Hardware-Based Web Security 95 | standard services, enabling Web pages the use of secure 96 | services enabled by security modules (TEE, secure elements, 97 | and other secure enablers with a demonstrated robustness to 98 | physical or software attacks). The group may produce 99 | non-Recommendation track documents within this scope. 100 | Recommendations are limited to the Restricted Scope Items 101 | described below. 102 |

103 |

104 | Specifications like those to be produced by this group could 105 | impact user privacy and potential anonymity. Special care will 106 | be taken to avoid introducing fingerprinting and tracking 107 | threats in deliverables from this group. One mechanism to 108 | alleviate these potential problems is to place permission to 109 | use some functions under the user's control in a way in which 110 | the user understands the privacy implications. The group will 111 | seek review from the Privacy Interest Group. 112 |

113 | 114 |

Restricted Scope for Recommendation Track Deliverables

115 | 116 |

117 | The Working Group Scope for Recommendation Track Deliverables 118 | will be restricted during this Charter period to the following 119 | Restricted Scope Items. Recommendation deliverables may only 120 | be added if they clearly fall within a Restricted Scope Item 121 | here. Restricted Scope Items must be carefully described so 122 | the types of technologies needed for implementation are clear. 123 | The group must recharter to add new Restricted Scope Items. 124 |

125 | 126 | 227 | 228 |

Web Services Interfaces

229 | 230 |

231 | Services defined in this Working Group (under the Restricted Scope Items) 232 | could also be exposed, in Recommendation Track Deliverables, through Web 233 | Services to a nearby device or to the cloud. The APIs would additionally 234 | be described in terms of message content (e.g using JSON) that could be 235 | delivered by means like RESTful Web Services, Web Sockets, or some other 236 | message delivery mechanism. That would allow the same security services 237 | to be used outside the Web Browser context, in the Internet of Things 238 | for example, or as services from the cloud. 239 |

240 | 241 |

Out of Scope

242 | 243 |

244 | The Working Group does not define how hardware security is 245 | accomplished. It defines how to ask hardware security for 246 | basic services where a secure hardware environment is 247 | available. The group will also not define crypto algorithms. 248 |

249 | 250 |

Success Criteria

251 |

The Group is successful if the following criteria are met:

252 | 277 |
278 |
279 |

Deliverables

280 |

Recommendation-Track Deliverables

281 | 282 |

283 | Deliverables will be identified from among those listed in 2.1 284 | and chosen by Working Group consensus. All Recommendations 285 | must have associated use cases describing the scenarios that 286 | the deliverable is intended to enable. These will be used to 287 | guide specification development. Use cases are not normative 288 | interoperability specifications. They are informative, so do 289 | not need to be in a REC track document. 290 |

291 | 292 |

293 | The group may produce Recommendation-Track deliverables within 294 | the scope of the Restricted Scope Items of this Charter. These 295 | deliverables, when chosen by the Working Group, will be listed 296 | on the group’s homepage or the GitHub repo linked from the homepage, 297 | under the Restricted Scope Item in which they fit. When rechartering, 298 | specific Recommendation-Track deliverables could also be listed, 299 | but none are listed in this Charter. 300 |

301 | 302 |

Other Deliverables (not W3C Recommendations)

303 | 304 |

305 | The group may also develop other deliverables that are not 306 | Recommendations. These are not limited by the Restricted 307 | Scope. As described above, these must be within the Working 308 | Group Scope. This could include use cases or best practices 309 | for using the APIs being developed or to explore possible 310 | future work in developing future versions of this Charter. 311 |

312 |

313 | The Working Group will liaise with the Web Payments Working 314 | Group on web payments access. The expected non normative 315 | deliverables with Web Payments WG are use case and an 316 | architecture document, focusing on payment integration in the 317 | web payment API designed when payment means relies on 318 | hardware. 319 |

320 |
321 |
322 |

Dependencies and Liaisons

323 |

Internal liaisons

324 | 333 | 334 |

External liaisons

335 |

There are a number of external groups working in areas related to 336 | the ones in scope for the HaSec WG. The Working Group should 337 | determine whom to communicate with and then maintain communication 338 | with them. The following groups are likely to be important:

339 | 345 |
346 |
347 |

Participation

348 |

Participation is open to W3C Members and Invited Experts.

349 |

In order to make rapid progress, the group MAY form several Task 350 | Forces (TFs), each working on a separate topic. Group members are 351 | free to join any number of TFs.

352 |
353 |
354 |

Communication

355 |

356 | This group primarily conducts its technical work on the public 357 | mailing list at public-hasec-wg@w3.org 358 | (archive). 359 | See W3C mailing list and archive usage 360 | guidelines. There is also a member-only list to be used for 361 | administrative or member-confidential purposes at 362 | member-hasec-wg@w3.org (archive). 364 |

365 |

366 | Information about the group (documents under review, face-to-face 367 | meetings, etc.) is available from the Web 368 | Hardware Security Working Group home page. 369 |

370 |
371 |
372 |

Decision Policy

373 |

374 | The group will aim to proceed by consensus. 375 |

376 |

377 | Where there is consensus among the Working Group Participants, 378 | it will be forwarded as a consensus position. Where the group 379 | does not reach agreement, the different positions will be 380 | considered together. 381 |

382 |

383 | All technical resolutions made by a meeting of the group are 384 | provisional until two weeks after being published to the mailing 385 | list. An objection made on the mailing list within two weeks of 386 | publishing a decision has the same standing as if it were made at 387 | the meeting. 388 |

389 |
390 |
391 |

Patent Policy

392 |

393 | This Working Group operates under the W3C 395 | Patent Policy (5 February 2004 Version). To promote the 396 | widest adoption of Web standards, W3C seeks to issue 397 | Recommendations that can be implemented, according to this policy, 398 | on a Royalty-Free basis. 399 |

400 |

401 | The Hardware Security Working Group also provides an opportunity 402 | to share perspectives on the topic addressed by this charter and 403 | create best practices documents. Those are not subject to the 404 | Patent Policy. W3C reminds Participants of their obligation to 405 | comply with patent disclosure obligations as set out in Section 6 of 408 | the W3C Patent Policy for those non-Recommendation-Track 409 | deliverables. 410 |

411 |

412 | For more information about disclosure obligations for this 413 | group, please see the W3C Patent Policy Implementation. 415 |

416 |
417 |

About this Charter

418 |

419 | This charter has been created according to section 5.2 of 421 | the Process 422 | Document. In the event of a conflict between this document 423 | or the provisions of any charter and the W3C Process, the W3C 424 | Process shall take precedence. 425 |

426 |
427 |
WG Chair: Virginie Galindo (Gemalto)
428 |
HaSec Team Contact: Rigo Wenning
429 |

430 | Copyright© 2015 432 | W3C 433 | ® ( 434 | MIT , 435 | ERCIM , 437 | Keio, 438 | Beihang), 439 | All Rights Reserved. 440 |

441 |

Last update: $Id$

442 | 443 | 444 | -------------------------------------------------------------------------------- /hb-secure-services/160426-27_W3C_HWSec_Telekom.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/websec/72e5f531aae220774645d67ca4644bfd82b68cf1/hb-secure-services/160426-27_W3C_HWSec_Telekom.pdf -------------------------------------------------------------------------------- /hb-secure-services/2016-04-26_Morpho_W3C_UseCases_v1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/websec/72e5f531aae220774645d67ca4644bfd82b68cf1/hb-secure-services/2016-04-26_Morpho_W3C_UseCases_v1.pdf -------------------------------------------------------------------------------- /hb-secure-services/SafranIdentitySecurity_Authorization-model-for-Javascript-usage-of-hardware-based-keys.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/websec/72e5f531aae220774645d67ca4644bfd82b68cf1/hb-secure-services/SafranIdentitySecurity_Authorization-model-for-Javascript-usage-of-hardware-based-keys.pdf -------------------------------------------------------------------------------- /hb-secure-services/W3C_hb_secure_services_gemalto.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/websec/72e5f531aae220774645d67ca4644bfd82b68cf1/hb-secure-services/W3C_hb_secure_services_gemalto.pptx -------------------------------------------------------------------------------- /hb-secure-services/etherpad-04-26-27.md: -------------------------------------------------------------------------------- 1 | Notes and Outputs from the W3C Hardware-based Secure Services Workshop, London  - 26th and 27th of April 2016. 2 | 3 | 4 | IRC minutes: Live minutes were captured on W3C's IRC, #hb-secure-services 5 | 6 | Day 1, 26th April 2016: https://www.w3.org/2016/04/26-hb-secure-services-minutes.html 7 | Day 2, 27th April 2016: https://www.w3.org/2016/04/27-hb-secure-services-minutes.html 8 | 9 | 10 | # Use Case Discussions 11 | 12 | 13 | Paul Waller, CESG. "Secure by default".   14 | * replacing large numbers of passwords, software-based crypto for authentication 15 | * risk management of devices fleet and services, 16 | * for government as an enterprise this includes internal services such as web services & email, but also authenticating to a device e.g. disk encryption & VPN 17 | * for citizen services online 18 | Challenges: how to diffentiate service among devices, while presenting the right level of detail to users; how to accumulate confidence (e.g., among multiple methods) 19 | * trusted input and output (how do I know what I see on screen was what provider sent) 20 | * end-to-end secure messaging to an unmanaged device? 21 | "I need to send a message to a user on a previously unseen device" how to bootstrap trust? known device ID, trusted display?  22 | * attestation (TCG, characterizing entire device state; here, perhaps, attestation about device security level) This could just be key attestation, e.g. what sort of credential store is protecting the key used to sign this response?  Doing this securely requires a device certificate, which must be inserted duing production 23 | *solution must be general across a range of different devices, capabilities 24 | * hardware key storage 25 | 26 | 27 | Is there a half-way step? so we don't need to solve everything at once. 28 | Understand the work that already exists, making the business case for integration.  29 | Hardware-backed security for identity and government services.  30 | 31 | 32 | Less about increasing security, than improving usability for what currently exists 33 | 34 | 35 | 36 | 37 | Identity inside the browser (in order to avoid external service ) 38 | (to be detailed) 39 | 40 | 41 | Philip Hoyer, HID Global 42 | [this is a technology trend, not a use case] 43 | TEEs in >450M devices 44 | Contactless protocols maturing 45 | HW sec primitives becoming cheaper, e.g. ECC 46 | HW IDs increasing in number: drivers license, patient IDs, eID,  47 | endpoint architectures multiplying 48 | 49 | 50 | Important:- Dichotomy:  Authentication & Identity  51 |                   - consent recording, signing, voting 52 | 53 | 54 | usability improvements, getting to user-acceptable speeds for secure transaction 55 | continuous/frictionless authentication *and* explicit user consent (e.g. signing, voting, payment) 56 | 57 | 58 | Aurelien Couvert, Gemalto 59 | thoughts from Gemalto's secure element API.  60 | cross-platform secure element (SE) API .  61 | needs access control to the secrets in the SE.  62 | globalplaform.github.io/?? 63 | http://globalplatform.github.io/WebApis-for-SE/doc/ 64 | 65 | 66 | transport level api similar to sim alliance omapi 67 | se manager-reader-session-channel 68 | access control toolbox.  69 | web security model: permissions, same origin policy 70 | se security model. PIN, secure messaging (mutual authN), GlobalPlatform access control  71 | GP Access Control: whitelist, which apps can access what in the SE 72 | Boxes: Web/ [public API] / privileged apps. e.g. AuthN, Signature, Payment, Reload / [restricted API] / SE 73 | 74 | pallette: trusted services, SE built-ins, GP Access Control, domain binding.  75 | 76 | Typical Access control scenario: Access managed hardware 77 | reuse of existing security building blocks, creative combination 78 | 79 | 80 | Joerg Heuer and Peter Hofman, Deutsche Telekom 81 | we've shown a mobile wallet, something that keeps state outside the browser, communicates through the browser. 82 | T-Systems, systems integration. public ticketing. Why are we currently using barcodes or QR codes?  83 | virtual car key in user wallet, provisioned for car rental.  84 | 85 | 86 | Use cases: car key, ticketing, payments (securing online payments as "card-present"); access control; hw-backed authentication 87 | We know how to virtualize the hardware, don't know how to virtualize for the Web 88 | 89 | 90 | Sebastien Bahloul, Morpho 91 | sharing experience about identity, use case.  92 | eID, good practices re level of assurance 93 | * states' motivation: public safety, public services (digital 50x cheaper), capabilities  94 | * level of assurance (defined by the lowest security level of id proofing, authentication factor, id & authentication lifecycle) 95 | 96 | 97 | Features: update profile of card; reload credits; renew certificate; deliver identity attributes.  98 | 99 | 100 | Browsers won't accept unscoped "APDU API". Maybe they will. Chrome for example accepts unscopeed "USB" API provided the user grants permission. 101 | how do we communicate between high-level, low-level API.  102 | 103 | 104 | propose: transaction confirmation API first. including authentication, transaction confirmation, signature 105 | "what you see is what you confirm." 106 | requires trusted output, TEE 107 | 108 | 109 | 110 | 111 | 112 | 113 | Technical Discussion and Requirements  for designing a solution 114 | 115 | 116 | 117 | 118 | (we might start high level and then refine) 119 | 120 | 121 | * About the solution 122 | consider also implementability and economic sustainability of the deployments. 123 | be agnostic in terms of implementation as a good implementation strategy today is to deploy in software first and use hardware 124 |  APDU will never be available to web developers 125 | giving user "trust context" about the information passed (range from medium to high security) - we may need to be more objective to start with - identifying the make and model of the credential store, for example, plus a statemetn of any certifications held. 126 | The solution must be able to run on any type of hardware (NFC reader, smart card, TEE, TPM) 127 | The solution can get benefit of all communication layers available in the device where the browser runs (NFC, BLE, USB, ISO, ....) 128 | The solution must have an access control and request user consent to access the hardware crypto device (to allow who should access the secure element services) 129 | The solution must no send unscoped bearer tokens around 130 | need to mix/bridge web security model and secure element security model (and web service provider security/risk management model) 131 | The secure services might have a root trusted issuer (pre-existing identity delivered by a trusted service provider, CA for certificate management) 132 | The solution may be able to include a user consent (improving the context and recognizing the consent aspects, à la FIDO) 133 | (Note that the association between user and credential might be out of scope) 134 | The solution must follow the SOP (and may build means to avoid being strict about it) 135 | The solution must support multiple users crypto and identity details. 136 | the solution must be able to block repeated request (to avoid attack by repeating) 137 | the solution may be end to end (aka, user agent being a tunnel to pass the data) 138 | 139 | 140 | * About the usability and user perspective 141 | Insure security with usabilitibity,  142 | user must be able to choose to whom (and as whom) he/she is recognised 143 | user interest/choice must be heard (either he/she cares or does not care to give information away) --> right to reconsider choice 144 | The solution must be usable on any browser 145 | A common interface/way to interact to choose the service is important 146 | The solution may have a detailed security qualification of the storage (private information) 147 | 148 | 149 | The solution must be usable for people with disability (either with a replacement mean, or an special care for context description) 150 | 151 | 152 | 153 | 154 | 155 | 156 | *Web service perspective 157 | Web service providers should be able to enforce policies for certain types of transactions (e.g. login with sw-credentials, but transaction signing with HW token) 158 | 159 | 160 | Privileged javascript as a proposal.  161 | Trusted javascript for trusted operations 162 | Rate limitation for the number of subsequent requests to the crypto token 163 | 164 | 165 | Vocabulary aspects : 166 | * Make a clear difference between an unmanaged device and untrusted device 167 | * Make clear identity and credentials are two different things 168 | 169 | 170 | Open question :  171 |     what happens if the service provided by the hardware technology disappears ? Error management/border case has to be managed 172 |     Does W3C have to define user interaction ? 173 |     What is the information that can be brought from the hardware token to the web layer 174 |      175 | 176 | 177 | --- 178 | Adrian Castillo.  179 | capabilities: read from card 180 | services: secure channel between token and server, need the keys from card issuer 181 | runs on IE and FF, Windows; MacOS Safari 182 | 183 | 184 | Sebastien Bahloul.  185 | API looks the same with the presence or absence of hardware features; it's up to the service provider to determine how to handle varying levels of assurance.  186 | 187 | 188 | 189 | 190 | Some things we can do :  191 |      192 | * List what other standards do 193 | and their gaps 194 | * Define a new protocol, with end-to-end authentication between hardware and server 195 | would that get ecosystem support 196 | * Beware of monocultures 197 | 198 | 199 | * Catalog what Apps can do that browsers can't 200 | * secure credential storage, keychains, and protections  201 | (issuance, renewal, revocation) (use) 202 | * key attestation 203 | * environment attestation  204 | * trusted UI  205 | * transaction confirmation service 206 | * biometry 207 | * a strong application security management (access control, digital signature, permissions, ...) 208 | * discoverability / reminder of the tokens used 209 | * app curation 210 | 211 | 212 | * Define which types of hardware tokens (besides smart cards) shall be supported on which transport channels on desktop and mobile platforms (e.g. USB authentication/signature tokens, smart wearables via BLE/mobile,...) 213 | 214 | 215 | --- 216 | Use cases:  217 |      218 |     * User confirming a transaction (request for several markets and scenario) 219 | Government online benefit payment systems (4B in payments); e.g. citizen management of change of address, WYSIWYC;  220 | Banking, adding a new external account. Adding beneficiaries. Transferring money (between a user's accounts; from one user to another) 221 | Confirm a trade 222 | Legal binding : digital signature on contract. Message signature. Note : Legal binding needs possession and knowledge (like in banking cards at the ATM) 223 | personal, or business. (delegation, agency): signing as a principal or as an agent of the company  224 | 225 | 226 | Access to e-government services, health care 227 | trusted proof of claim.  228 | 229 | 230 | consequence of that use case deployment :  231 |     --> need to have a qualification of the 'material' used for the transaction confirmation , like a key attestation - knowing (the security of) where the key ended up 232 | 233 | 234 |     * credential management  (request for several markets and scenario) 235 | Reputation management based on token owned by the user : comments on the web, on social media... 236 | All the use cases mentionned in the transaction confirmation 237 | Secure messaging : allowing an end to end encryption (Whatsapp recent choice) 238 |     related technology : web crypto API  239 |     reinforce WebCrypto use cases with higher security    https://www.w3.org/TR/webcrypto-usecases/ 240 |        241 | Use case: A tangible hardware thing carrying individual or company identity token used for services and authentication that is of moderate security, e.g. for time management and cafeteria 242 | 243 | 244 | -- 245 | # APIs 246 | * Secure Credential Storage (elaborated below) 247 | * Transaction Confirmation API 248 | 249 | 250 | 251 | # Transaction Confirmation API - Champion: Sebastien 252 | flipchart image: https://github.com/w3c/websec/blob/gh-pages/transaction_confirmation.jpg 253 | 254 | JavaScript API 255 | Goal: to give some assurance to a remote entity that a transaction is confirmed. Confirm that what was sent was communicated to the user, and that what was displayed to the user is what was confirmed.  Confirmation should include a signature and also some information about the secure environment (which vendor, is it hardware, is there tamper protection, is there any certification- with clarity of both display and input as these may have seperate security "levels") - this will help the remote entity understand how confident they can be in the response. 256 | May depend on key attestation; trusted UI.  257 | [assuming the component has already been provisioned] 258 | 259 | 260 | enum CVM { "presence", "active" , "none"?}; 261 | [ref FIDO, test of user presence or active authentication] 262 | [added "none" to cater for passive authentication use-cases, where the service provider only needs device authentication] 263 | 264 | 265 | interface SubtleHWCrypto {  266 |   Promise checkPresence(BufferSource dts); 267 |   Promise confirm(DOMString context, CVM mode, String url);  268 |   Promise sign(DOMString context, BufferSource dts); 269 | }; 270 | 271 | 272 | Signing both the context and the data. 273 | Relies upon X509 certificates  274 | 275 | 276 | Acronyms and Definitions 277 | 278 | 279 | SP/RP - Service Provider/Relying party - e.g. a bank 280 | Context: A message to the user that is human readable 281 | SCS - Secure Credential Store 282 | KMS - Key Management Selection 283 | KML - Key Managment List 284 | NRA - Non-repudiation Acknowledgment (M=Message) 285 | TEE - Trusted Execution Environment 286 | OS - Operating System 287 | MW - Middleware 288 | UVM: User Verification Method 289 | 290 | 291 | Use Cases for this API 292 | 293 | 294 | * Non-confidential use case 295 | * Confidential use case 296 | 297 | 298 | IBAN to IBAN transfer (transaction from foreign bank to UK customer) - out of the zone of the local banking system, very difficult to resolve later / traceability issues 299 | * both ends have total clarity of the transaction 300 | 301 | 302 | Usage Flow 303 | 304 | 305 | 1. user consults an HTML page provided by SP (service provider) 306 | 2. the browser checks SOP/CORS JS call to a browser API  307 | 3. the browser gathers information with respect to the UI, execution environment, potential certification, OS quality 308 | 3.bis : [Trusted Environment (not browser controlled)] discovery of certificate the user chooses credential or keys to be used for signing  309 | 4. the user signs data and context (presented in human understandable way) 310 | 5. the browser collects signature and transfers to SP 311 | 312 | 313 | 314 | 315 | Scheme flow 316 | parties : user/SP or RP/ Browser / Transaction confirmation component (TUI TEE, OS, middleware, code running in the browser),  317 | 318 | 319 | https://www.websequencediagrams.com/?lz=dGl0bGUgVHJhbnNhY3Rpb24gY29uZmlybWF0aW9uCgpwYXJ0aWNpcGFudCBFbmQtdXNlciBhcyBFVQAODVNlcnZpY2UgUHJvdmlkAB0GU1AAMQ1Ccm93ADYHQlIASw1UcnVzdGVkICBVSSAoVEUsIE9TIG9yIE1XKSBhcyBUVUkAXA9jdXJlIFN0b3JhZ2UAdQVlciAoZVNFLCBTSU0sIE5GQy9CTEUgU0UgLi4uAD8FU0NTCgpFVS0-U1A6IFJlcXVlc3Qgc2Vuc2l0aXZlIG9wZXIAgWoGU1AtPkJSOiBEZWxpdmVyIHRoZSBIVE1ML0pTIHBhZ2UKQlIAGwZKUyBjb21wdXQAgiEHYWx0IE5STSBvbmx5IChub24gcmVwdWRpAIJCBSkKICAgIEJSLT5UVUk6IE4AEA4AgmUNIHIAgRcHd2l0aAAlBVIAHwtNZXNzYWdlIChOUk0pCmVsc2UAcAUrIERUUwBlESArIGJpbmFyeSBzaWduZWQgZGF0YQA1ViBhbmQgRGF0YSBUbyBTaWduIChEVFMAgRsHRFRTAIIQB3RyYW5zcGFyZW50IAABCwCEZg0Agh0PAIUVBQAUEwCCGgYAXxRuZAoKVFVJPC0-U0NTOiBLZXkgbWF0ZXJpYWwgbG9va3VwAIMJJVRVSS0-RVU6IFByZXMAgSwFaGUgY29udGV4dCwAhBMFawBODHNlbGUAhjoGYW5kIHJldHJpZXZlAIQ7BQCGLgV2ZXJpZmljAIZQBiAgICBFVQCEBwdVABoFYWxpZACECAYoVVYpICsAhBQRYWNrbm9sZXdkZ2VtZW50IChOUkEpICsAgQEFAHMKKEtNAIJvCACDZDUANYFBAIQ9MACEKgUAg2coAIRMBQCINwhOUk0AhlQFYXR1cmUAh1wFU0NTAIdbBwCKAAcAhnEITlJNAIJUQAA_PACBKhZEVFMAgTYKAIhpBnRoZSBzYW0AhVUGdXNlZCB0bwCIOAUAPgkAgUoZRFRTAIc0OgB9ICh3aGljaACGbAU_AIpGBgBqHgCHfAcAi0UGAIJ9D2VsAIY7BXMAij8FIGFuZC9vciBEVFMpICsgVFVJIEF0dGVzAItQBiArIFNDUyBhAAgKAIt6BVNQAINXCgCIDwZtYmluZWQgAIpwEHJlc3VsdAo&s=vs2010 320 | 321 | 322 | 323 | 324 | Note : Transaction confirmation component is in charge of taking care of non repudation, presenting the context. Non-repudiation (can also be used for transaction confirmation and consent recording) 325 | Note : Context message is a text only, localised, presented to the user by the Transaction confirmation module.  326 | Note : NRA is ? Non-repudiation Acknowledgment (M=Message) 327 | Note : KMS is Key Management Selection - key selected by user 328 | Note: KML is Key Managment List - acceptable keys from SP point of view 329 | Note : SCS: Secure Credential Store 330 | Note : attestations are associated with Transaction Confirmation Module and SCS 331 | 332 | 333 | 334 | 335 | Assumptions / Dependencies 336 | 337 | 338 | * Browser: JavaScript, HTML, CSS 339 | * Underlying Trusted Execution Environment / capability 340 | * Reliability 341 | * Human user OR machine-to-machine? 342 | * The Trusted UI integration in browser should not be mandatory in the service usage 343 | * We can think usage flow from the POV: "we have nice new capabilities on mobile phones, let's bring it to the web".  344 | * Or we can think the same usage flow from: "I have a web application written in javascript and I want to have secured consent recording/authentication  345 |    and I want to access certain hardware capabilities".  346 | * Everything which has to be signed is firstly signed by the SP and the hardware secure device would have to first verify it before letting the user signing it 347 | * The signature is operated by the hardware token, and has a direct link with the Transaction Confirmation Component 348 | * Dependency on X.509 certs => Yes 349 | * Dependency to Permission API (WebAppSec WG).  https://www.w3.org/TR/permissions/ to ask for permission to use hardware capabilities (mention the type of operation as well, not only access required but access to sign?) 350 | * GlobalPlatform doesn't mind additional APIs as long as it does not break the protection profile (UI) only needed if addtional information  351 |   is needed by the trusted application from the TEE, not if web application wants something from the secure application.  352 | 353 | 354 | Errors and Exceptions 355 | 356 | 357 | * User blocks / denies access 358 | * Invalid / untrusted domain 359 | * Invalid keys 360 | * Certificate expiry 361 | * OCSP / CRL error (what is this flow?) 362 | * Timestamp error 363 | * latency, network errors 364 | 365 | 366 | Security Considerations 367 | 368 | 369 | * The "dancing pigs" problem around user confirmation / presence 370 | * Availability and Integrity requirement 371 | * Vulnerabilities in underlying OS 372 | * Vulnerabilities in browser 373 | * How the browser collects and stores (hopefully not cached in software) information about the underlying platform / execution environment 374 | * Signing mode Trusted UI should show the choice of certificates/keys - ideally user should  375 | *Patches/updates - how do I know the 'trusted' remote component is up to date? / version number as well as type, should be recorded. May not be necessary to be validated? 376 | * Need to have a consistency of context security descriptionand secuirty error management for accessibility reasons 377 | 378 | 379 | 380 | 381 | Threats / Attacks 382 | 383 | 384 | * Extraction of user data by unauthorised site / person 385 | * Cross-site scripting attacks (breach of SOP) 386 | * Man in the browser attacks 387 |   * including through underlying OS vulnerabilities 388 |   * including malicious browser extensions 389 | * Repudiation attacks 390 | * Time abuse attacks / NTP / local 391 | * Replay attacks 392 | * Abuse of accessibility services to leak / modify information or to display different information between the interfaces 393 | * abusing signature sent back to the RP (bearer token as mentionned by rigo) (scope the bearer tokens used e.g. to date, origin, transactionnumber) 394 | * Attacker fakes the entire system / user interaction process 395 | 396 | 397 | 398 | 399 | * Phishing / social engineering 400 | * Semantic attacks e.g. mixing fonts / making something look like the authentic SP (the RoyBan problem) 401 | 402 | 403 | Privacy Considerations 404 | * Browser is not a confidential environment 405 | * Privacy-preserving attestation of environment 406 | * Confidentiality requirements?  407 | * authentication and exposure of user credentials or uniqueIDs etc should only happen after user interaction (like geolocation)  408 |     [abuse also by trusted parties in the form of dark patterns] 409 | * recording consent as a feature 410 | 411 | 412 | User Considerations 413 | 414 | 415 | * Recording consent 416 | * Readibility of security context - user display / understanding 417 | * indication - e.g. TEE display hardware indicator / user stored image 418 | * User education 419 | * Terms and conditions / display 420 | * Accessibility: some equipment is not designed for accessibility / out-of-band mechanisms 421 | 422 | 423 | General Concerns 424 | 425 | 426 | * In esignature law - Display component needs to be certified by government? Possible in a browser [Germany]? Rigo: may not be a concern 427 | 428 | 429 | Where is this flow currently used? How is it done? (source of example use cases, refinements to the model) 430 | * e.g. transfer from account A to account B, DTS is "account number"+context 431 | 432 | 433 | Work in progress about verifyable attributes: https://www.websequencediagrams.com/?lz=dGl0bGUgVmVyaWZpYWJsZSBhdHRyaWJ1dGVzCgpwYXJ0aWNpcGFudCBFbmQtdXNlciBhcyBFVQAODVNlcnZpY2UgUHJvdmlkAB0GU1AAMQ1Ccm93ADYHQlIASw1UcnVzdGVkICBVSSAoVEUsIE9TIG9yIE1XKSBhcyBUVUkAXA9jdXJlIFN0b3JhZ2UAdQVlciAoZVNFLCBTSU0sIE5GQy9CTEUgU0UgLi4uAD8FU0NTCgpFVS0-U1A6IFJlcXVlc3QgdmVyAIFfEVNQLT5CUjogRGVsaXZlciB0aGUgSFRNTC9KUyBwYWdlIApCUgAcBkpTIGNvbXB1dGF0aW9uCgATBVRVSQBVCnRvIHJldHJpZXYAgkYMIHdpdGggU1AgcHVibGljIGtleSBhbmQgbm9uY2UKVFVJPC0-U0NTOiBBACkKYXZhaWxhYmlsaXR5ClRVSS0-RVU6IFByZXNlbnQAgR4FcgBWHmZvciBhIHRhcmdldCBTUCAoVVJMIG9yIGRvbWFpbiBuYW1lKQCCGgUAgTwFVXNlciB2YWxpZACBVgUgKFVWKQCBMQZlAIN4CWNrbm93bGVkZ2VtZW50AIEPBgCBMgUAglUIAIFnC2QAgkYGeSwgc2lnbmF0dXJlAIFuBQCBdw5lbmNyeXAAgkcFU0NTAIJFBwCESAcANAVlZACCJAUAIQdlZACFGwwAghAFQlIACCkgKyBTQ1MgYXR0ZXMAgzoHQlIAhBgGAGsIdGhlIGRhdGEgYmFjayB0bwCEBgVTUAo&s=vs2010 434 | 435 | 436 | ---- 437 | # Secure Credential Storage and Management 438 | (Credential=cryptographic keys) 439 | 440 | 441 | Introduction text   442 | Goal: To provide for the secure storage and management (issuance, renewal, revocation) of keys for, e.g. identification, authorisation, signature 443 | Scope limitation : we will not manage X509 or any other certificate straucture, but only focus on keys. 444 | two possible use cases : (1) a credential is provisioned by one RP and used by the same RP, (2) a credential is provisionned by a RP and used by other authorised.  445 | Decision : Lets start with one case 1 and work on use case 2 on the basis of (1) 446 | 447 | 448 | Use cases : to be detailed, having in mind use cases where user is in control, and use cases where the RP is in control.  449 | 450 | 451 | Technical assumption and requirements 452 | 453 | 454 | Portability should to be considered  (aka, using any key in a token inserted in any browser) 455 | 456 | 457 | Credential sharing : organization may create credentials to be used by other parties [question: do we require use of a derived credential rather than the original? possibly advantageous from a comprise scenario] 458 | There have to have an access control to control third parties, but still fitting with SOP. A possible solution is to add some metadata (aka, authorised domains to use the credential [question: what are good ways to scale such whitelisting?]) 459 | 460 | 461 | Revocation : a credential may be revoked by the issuer (invalidated) and a authorised SP may also be removed (its access to the credential can be revoked - by whom, the user or the credential-issuer?) 462 | 463 | 464 | Renewal : TBD 465 | ACTION : Rigo will come back with an explanation of a potential technical solution for sharing credentials among parties.  466 | 467 | 468 | 469 | 470 | Functionality :  471 |     We want key to be able to be permanent (persistent)  472 |     We want key to be protected from hardware and software attacks 473 |     Do we want this key non-extractable by default? We may keep both both possibilities, with wrapping capabilities 474 |     Do we want only to use crypto in the hardware token? We don't want to restrict the possibility of extraction.  475 |     Can we migrate keys? (wrapped) - use cases? 476 |     Do we want to extract keys (in plain text)? - use cases? 477 |     Portability of keys - is the key bound to the device or module? (Bound to a URI origin) - installed into a physically removable device or a non-removable device? Can you attest to the difference? e.g. some information/knowledge about that device helps for the SP etc. - e.g. signed make, model, version number 478 |     Selectable [processing] sources - e.g. hashing could be done in the token or in software, for example for performance / efficiency needs 479 |     Note : the speed of operation may be a discriminative point to have the browser being involved in crypto operations. 480 |      481 |     We want the web developer to be able to choose the level of security of the hardware token used. 482 |     In the future we may want have the possibility for the user to choose the token he wants to use.  483 |     We want the UA to be able to handle multiple keys origin [key identity?] clash,  484 |     We want the UA to be able to retrieve keys from a specific origin 485 | 486 | 487 |     Suggested MVP : create key, private stays inside, public can be exported,s key is used to sign/cipher within the hardware crypto token [with preference to /dev/urandom*] 488 |     Key Destruction - SP initiated (security risk of it becoming a kill switch!) and user initiated (e.g. a device factory reset / transfer ownership of device) 489 |      490 |     Different types of keys, some may be associated with user validation/control - needs use cases to explain this properly. Don't want to make this unusable due to [prompting] 491 |     - management aspects to this too (related methods) 492 |     - triggering self-management UI etc. [security issues?] 493 |     There should not be a requriement that requires the security module must make security assets held by other components of the device. i.e. it cannot be expected that the TEE must have access to PIN valdiation assets that are held by the Rich OS.  494 |     open question : do we want the user to be associated with the creation of a key ? if yes, it may be in the form of a user verification (pincode, fingerprint) (also generation of entropy for randomness[*]). The use case could be the user is looking for free spacing.  495 | 496 | 497 | Note: the W3C Key Discovery Note can be reused: https://www.w3.org/TR/webcrypto-key-discovery/ 498 | 499 | 500 | [Interoperability expectation especially if moved around between devices...] 501 | [bootstrapping?] 502 | 503 | 504 | Usage Flow (Full lifecycle of keys needs to be further described) 505 | 506 | 507 | Secure Storage 508 | 509 | 510 | First use case : RP wants to create a key to enable secure cloud storage. Initial context is that the user is using a browser on the website of the upbox service. 511 | 512 | 513 | 1. User wants to store a photograph she is uploading to the upbox photo service. 514 | 2. Browser calls JavaScript API to initiate Key generation in secure hardware 515 | 3. Ciphering operation in secure hardware 516 | 4. Encrypted Photograph is uploaded to upbox. 517 | 518 | 519 | Second use case : User decides to download the image from the upbox cloud service. Context is the same as above. 520 | 521 | 522 | Security goal for this service - prevent leakage of photo to other devices whilst storing it in the cloud. [Note to reader: we need the other use cases for multiple devices / shared services] 523 | 524 | 525 | 1. User initiates the download of the encrypted picture from upbox. 526 | 1.1 Key discovery via JavaScript call to keydiscovery function - from secure hardware. 527 | 2. The JavaScript call to the decryption function is called within the browser.  528 | 3. Decryption operation. 529 | 4. Plaintext image is displayed within the browser in the context of the upbox website. 530 | [or unwrapped key in key storage] 531 | 532 | 533 | Not mentioned here - unwrapping/key manipulation within the secure hardware or within the browser context, dependent on various factors (such as, having one secret key created per document, protected by the master key of the service) 534 | 535 | 536 | Information: possible keys: user, upbox, individual key for photo 537 | 538 | 539 | 540 | 541 | https://www.websequencediagrams.com/?lz=dGl0bGUgUlAgd2FudHMgdG8gY3JlYXRlIGEga2V5IHRvIGVuYWJsZSBzZWN1cmUgY2xvdWQgc3RvcmFnZQoKcGFydGljaXBhbnQgRW5kLXVzZXIgYXMgRVUADg1SZWx5aW5nIHBhcnR5IGFzIFJQAC4NQnJvdwAzB0JSAEgNVHJ1c3RlZCAgVUkgKFRFLCBPUyBvciBNVykgYXMgVFVJAHYNUwCBHwZTAIEZBiAoZVNFLCBTSU0sIE5GQy9CTEUgU0UgLi4uADgFU0NTCgoKb3B0IFVwbG9hZACBHAVob3RvCiAgICBFVS0-UlA6IFVzZXIgdG8AgW4FZSBlbmNyeXB0ZWQgcmVzb3VyY2Ugb24gdGhlIHNlcnZpY2UANwVSUC0-QlI6IERlbGl2ZXIgSFRNTC9KUwBTBUJSLT5TQ1M6AIFrCWNhbGxzIEphdmFTY3JpcHQgQVBJIHRvIGluaXRpYXRlIEtleSBnZW5lcmF0aW9uIGluAIMECGhhcmR3YXIAbgZCUjwAUgdDaXBoZXJpbmcgb3AAFCEAgV8GRQCBTglQaG90b2dyYXBoIGlzIHUAghQFZWQgdG8gdXBib3guCmVuZACCLwZEb3duAIIqDXMAgiYSAIE8CHMAgh4FZAArByBvZgCCLgUAgkMKcGljdHVyZSBmcm9tAGEIAII8DQAyCEpTIGFuZACCfAtkYXRhAIFxD0tleSBkaXNjb3ZlcnkAgmYOc2VuAINiBQAtE1NDUwCDLwZTAB0HYmFjawCBMQZlAGEMAIETBkJSAINcBmRhdGEgaXMgZGlzcGxheWVkAIIbBQ&s=vs2010 542 | 543 | 544 | Third use case: Accessing an eGovernment service and altering information 545 | 546 | 547 | 1. User receives email from town administration to update information about children for subsidies 548 | 2. User directs his browser to https://town.gov.ee and clicks on the link to the changing service 549 | 3. town.gov.ee sends a page with JavaScript that requests access to the hardware with the Estonian citizencard 550 | 4. The page requests to activate the citizencard from the users 551 | 5. The user accepts the request and puts the citizencard near the NFC reader 552 | 6. town.gov.ee sends a challenge 553 | 7. Browser signs challenge with the user's private key  from eID Citizencard<-- new API is used here ! 554 | 8. town.gov.ee sends the page with the form to change the information to the user 555 | 9. The user fills out the form and clicks "submit authenticated" 556 | 10. The browser hashes and signs the form and sends it to town.gov.ee 557 | 11. town.gov.ee verifies the form with the user's public key from eID Citizencard 558 | 12. town.gov.ee updates the database for children subsidies 559 | 560 | 561 | 562 | 563 | Security Considerations 564 | 565 | 566 | * Loss / theft of device [means that user can never access content if tied to the key] - key extraction / backup use case 567 | 568 | 569 | Privacy Considerations 570 | 571 | 572 | 573 | 574 | 575 | 576 | Exceptions and Errors 577 | 578 | 579 | * card/token not present / removed 580 | 581 | 582 | 583 | 584 | Usability for Web Developers 585 | 586 | 587 | * We want web developers to be able to understand the subtle security options of the API. 588 | * Education! 589 |      590 | Usability for End Users 591 | 592 | 593 | * Reduce opportunities for social engineering / fraud. 594 | 595 | 596 | Accessibility 597 | 598 | 599 | 600 | 601 | 602 | 603 | Dependencies and References 604 | * Not duplicating FIDO's authentication work.  605 | * FIDO is doing authentication without identification. Hardware credentials most often are tied to some identity management scheme. So the big difference  606 |    on what we try to achieve here is to use the hardware credential INCLUDING identification and not only device authentication.  607 | * WebCrypto API: https://www.w3.org/TR/WebCryptoAPI/ 608 | * Credential Management, WebAppSec 609 | * Unclear whether X.509 credentials will have to be used and what else is ready or good or an option. We should start with normal key management.  610 | * A challenge in Web Crypto: different formats used in different places (OS native functionality needs a bridge to work interoperably across platforms). Relying on native OS may introduce difficulty in interoperability 611 | * Ahana points to https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf  612 | 613 | 614 | Suggestion is to transport the hardware capabilities in metadata once the user agrees to expose them. The web developer will be able  615 | to create algorithms of which method to use and when to fail with an error message. This is related to the W3C Note on Key Discovery (no  616 | implementation of key discovery so far) 617 | 618 | 619 | Rationale 620 | 621 | 622 | Problem: browser password stores are weakly protected in some browsers/OSes; localstorage may not be secure; 623 | browser auto-complete may supply information meant to be kept secure 624 | Suggestion from David: Expose the problem space first to have a narrowly scoped target work that may convince browsers 625 | 626 | 627 | 628 | 629 | How do Same Origin Policy and Shared Credentials work together?  630 | *  per-origin enrollment? a la FIDO, Android fingerprint sensor, TPMs with attestation keys.  631 | * Rigo s idea is to use a session encryption like in OTR to have the origin added to the general certificate. Will refine the idea with Sebastien 632 | 633 | 634 | 635 | 636 | About Implementations Considerations 637 | 638 | 639 | Aurélien :  640 |     in a secure element, keys are handled into applet, there is a need to have a standard way to create keys and manage it...for example, choosing PKCS11 style of talking to a secure element. 641 |      642 |     Peter : 643 | Code needed in multiple places, including from browser to TEE and SE. That's a challenge for industry.  644 | Virginie: possible open source projects to work with: https://www.linaro.org/ 645 | Open TEE project https://github.com/Open-TEE/project 646 | 647 | 648 | https://www.w3.org/community/hb-secure-services/ 649 | 650 | 651 | 652 | -------------------------------------------------------------------------------- /hb-secure-services/transaction_confirmation.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/websec/72e5f531aae220774645d67ca4644bfd82b68cf1/hb-secure-services/transaction_confirmation.jpg -------------------------------------------------------------------------------- /hbss.html: -------------------------------------------------------------------------------- 1 |  2 | 3 | 4 | 5 | Hardware Based Secure Service features 6 | 7 | 8 | 9 | 10 |
11 |

12 | 13 | W3C 14 | 15 |

16 |

Hardware Based Secure Services features

17 |

Draft version - 29 August 2016

18 |
19 |
Latest version
20 |
21 | https://rawgit.com/w3c/websec/gh-pages/hbss.html 22 |
23 |
History
24 |
25 | https://github.com/w3c/websec/commits/gh-pages/hbss.html 26 |
27 |
Issues
28 |
29 | File a issue (open issues) 30 |
31 |
Editor
32 |
Sebastien Bahloul / Safran Identity & Security
33 |
Aurelien Couvert / Gemalto
34 |
35 |

Copyright © 2016 the Contributors to the Hardware Based Secure Service CG Specification, 36 | published by the Hardware Based Secure Services 37 | under the W3C Community Contributor License Agreement (CLA). 38 | A human-readable summary is available.

39 |
40 |
41 | 42 |
43 |

Abstract

44 | 45 |

TBD

46 |
47 | 48 |

Status of This Document

49 | 50 |

51 | This specification was published by the Hardware Based Secure Services. 52 | It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups. 53 |

54 | 55 |

Working copy

56 | 57 |

Table of Contents

58 | 68 | 69 | 70 |

1. Introduction

71 |

72 | The open web platform runs on diverse devices such as tablets, PCs, smart phones, and cars' systems. Driven by an expectation from users and service providers, a majority of those devices are embedding some technology allowing to offer some secure services. One can think about secure chips such as embedded secure element, TPM, UICC, or proximity smart card, using BLE or NFC communication means. Another technology getting traction is the Trusted Execution environment. Both types of technology are offering some advantages in terms of secure execution and storage. Secure elements and TEEs can offer some services, known as Secure Services, to improve the integrity and confidentiality of data transactions. 73 |

74 |

75 | This document is proposing some use cases where the web apps could benefit from secure services. In addition, in order to demonstrate the feasibility of such secure services, the Hardware Based Secure Services Community Group has identified two services, for which technical rationale and API will be detailed. In addition some protoypes, testing the reliablility of the architecture, will be developed. The elected secure services are (1) secure transaction confirmation and (2) secure credential storage. 76 |

77 | 78 |

1.1 Terminology

79 |
    80 |
  • Secure Service: any web site that manages sensitive operations and would benefit from/depend upon the use of an hardware based security solution to give the security proof of the user confirmation integrity and non repudiation
    • 81 |
  • Relying party: the Web application providing the Secure Service and requesting the hardware access
    • 82 |
  • Issuing authority: the issuing authority is in charge of issuing an associated key/identity pair to a known identity and to maintain its lifecycle. The end-user identification is out-of-scope of this document but is clearly mandatory to associate a key to a genuine identity. As an example, in the well known in X509 certificates scheme, the issuing authority is the certificate authority
    • 83 |
  • Origin: with reference to the Same Origin Policy, in this document an origin refers to an HTTP URL with scheme, host, port without path
    • 84 |
  • User Agent (UA): a user agent is software (a software agent) that is acting on behalf of a user (from Wikipedia)
    • 85 |
  • User Verification Method: This is the way that the Hardware Secure Device ensures that only a natural and genuine person with possession and knowledge is able to access the keys stored in the Secure Element. For example, this method could be knowledge of a PIN code or biometric verification
    • 86 |
  • Identity: to be verified by the issuing authority, the identity is cryptographically linked to the key demonstrating who has confirmed a transaction or signed a document
    • 87 |
  • Key: asymmetric cryptographic public/private key pair, sometimes linked to an identity
    • 88 |
  • Hardware Secure Device: addition of the Secure Credential Storage and the Trusted User Interface with a trusted path between them
    • 89 |
  • Secure Element: A secure element is a tamper proof device, providing a secure storage and execution environment for sensitive data and processing. It offers both physical and logical protection against attacks, ensuring integrity and confidentiality of its content.
    • 90 |
  • Trusted User Interface: User interface component outside the direct browser scope providing 91 | an additional level of trust in regards to the transaction confirmation message presented to the end-user to acquire its acknowledgment. It covers both the display of the information and the input of the user verification method.
    • 92 |
93 | 94 |

2. Problem Statement

95 | 96 |

At this time Secure Element are not yet usable by web applications. For years, various form factors have been usable thanks to many native API and technologies (PKCS#11, Microsoft API like CSP / Minidriver, Java applet ...). Use cases are valid for native applications but browsers have not been working on integrating those technologies. The need to use secure services in all types of application (native, web app, hybrid) is becoming important, especially on the mobile devices. This document aims to define the next generation Javascript API for two specific requirements for hardware based key management and usage: Secure transaction confirmation and Secure credential storage. These two requirements have been identified by the Hardware Based Secure Services Community Group as being as key to enable a strong security and identity ecosystem.

97 | 98 |

The management of keys is associated with the problem of key usage. On the open web platform, the security principle that prevails everywhere is the Same Origin Policy. This strict policy may have some limitation in some specific cases, where several parties are involved in the delivery of a secure service.

99 | 100 |

Same Origin Policy: one main matter of interest of the hardware-based secure services community group members is how to protect key usage considering the special use case where the credentials are used outside their issuing origin. For example: Suppose that a domain foo.com issues a key. Because the key is not accessible by Javascript API from another domain, we have to design a secure system where the domain bar.com is allowed to use this key.

101 | 102 |

There is a need for multiple domain key usage, but that this work will be treated later or when the CG will be a WG.

103 | 104 | 105 |

In this document, we assume that:

106 |
    107 |
  • pre-existing keys and X509 certificates are under the full control of the end-user
    • 108 |
  • any API issued key MUST only be managed and used by its own origin
    • 109 |
110 | 111 |

Position to FIDO and WebAuth standards: this document is focusing on providing web developers means to 112 | issue and use identity keys (whether they are X509 certificates or any other cryptographic model with underlying 113 | asymmetric cryptography). 114 | FIDO standards is related to device authentication: in the FIDO vision, it is up to the relying party 115 | to manage the link between the credential and the identity.

116 | 117 |

Position to WebCryptoAPI standards: this report includes to WebCryptoAPI so that 118 | web developers can rely upon the same API but with a different initialization (like Java Cryptographic Engine with hardware provider).

119 | 120 |

The user verification method is out of scope of this specification. But it should be clear whether a key is protected by:

121 |
    122 |
  • the terminal without any user interaction (passive)
    • 123 |
  • the user presence confirmation (presence)
    • 124 |
  • the underlying OS user verification method like an handle to the registered fingerprint template (os)
    • 125 |
  • a specific and private key bound with user verification method like a specific PIN or a specific fingerprint/iris template (active)

    • 126 |
127 |

The Relying Party should take care that:

128 |
    129 |
  • with the passive option, there won't be any effective user confirmation - it's only about device authentication
    • 130 |
  • with the presence option there is no assurance that the right user is really behind the user-agent
    • 131 |
  • with the os option, there is options provided by the OS manufacturer to manage real world use cases - i.e. sensor not capturing the fingerprint switching to the PIN code
    • 132 |
133 |

Only the active option will guarantee that the user with the right knowledge or biometric characteristic is behind the user-agent.

134 | 135 |

3. Use cases

136 |

137 | Hardware based services are already used in a number of domains which are particularly vulnerable to security attacks. Those domains cover financial and telecommunication industry, government and corporate services. Hardware based technology is used in those domains in specific cases such as managing authentication of the user or of the device, capturing user consent, document signature... The following use cases describe different areas in which hardware based technology is being used today. One should read those use cases as attractive for web application scenario. 138 |

139 | 140 |

3.1 National electronic identity for accessing public services.

141 |

142 | As of 2016, a large number of European countries have already deployed electronic identity systems and offer their citizens access to government services such as paying tax or managing pensions. Examples of countries and associated systems are:

143 |
    144 |
  • Estonia: eEstonia
    • 145 |
  • Belgium: eID with eService ecosystem
    • 146 |
  • Sweden: Tax Agency card and Telia eID
    • 147 |
  • Norway: ID-porten
    • 148 |
149 |

150 | All the deployed solutions are relying on middleware deployment on citizen devices.

151 |

152 | Whatever the service accessed, the citizen will be expected to own a hardware token that will carry their electronic identity. This identity (most of the time a certificate for a key pair) will be used to authenticate the user and sign some transaction he or she will be performing on the government portal. The native environment of the citizen device, or of the public service office, is able to access to the hardware token, thanks to a transport layer (USB, ISO 7816 / 14443, Bluetooth Low Energy ...). 153 |

154 |

3.2 Financial transaction signature, with user consent

155 |

The remote access to financial account, together with the electronic fund transfer are now part of citizen habits in developed countries. Most of the banks do offer in their account package this remote management service. In some conditions, usually defined by the bank, some extra security is requested to the consumer to finalize transactions. This extra security aims at improving the usual login/password security barrier. Depending on the use case, it could be either a one time password sent by SMS, or a user operation to confirm his or her presence, or a digital signature of the transaction itself. That last step requires the user to use some credentials, distributed by the bank, usually stored in a secure container, such as a hardware based token (USB token or proximity token). The data signed by the user generally includes the amount and destination of the transaction, plus additional information as desired by the bank.

156 |

3.2.1 French ecosystem

157 |

158 | In France, a list of trusted issuing certificate authorities is maintained by the Finance Ministry. The face-to-face verification of individual identity acting on behalf of a company is managed by the certificate authorities, as is the delivery of smartcards or USB tokens. 159 | This ecosystem is also used by the French corporate banks to manage 160 | many regulatory related tasks and also to enforce strong authentication but also digital signature, for example to confirm the file containing the widthdrawal of the salary for a company. 161 | Issuing authentication credential is not acceptable according to the 162 | existing risks they are facing in terms cyber attacks: combined social engineering, phishing, stolen Transaction Account Number for multiple attack vectors: 3DSecure online payment confirmation, withdrawal... 163 | Banks are looking to cover the transaction risk by using the right credentials for the risk, with the strongest level of authentication being used for the highest risk scenarios. 164 | Without the capability to rely upon Secure Elements in the browser, banks currently face a major issue in being able to replace the existing identity scheme delegation which provides a strong authentication and signature credential. 165 |

166 | 167 |

3.3 The expectation from secure services

168 |

169 | Whatever is the envisaged use case, signing a tax payment, confirming a transaction payment, validating the signature of a document, the service needs to rely on a genuine signature and user control. Each service provider needs to have a certain flexibility in designing its security model. Nevertheless, there are some minimum common basic functions that one can find in most of the security operations. The Hardware Based secure Services Community Group identified two technical features that are used on a regular basis : the secure transaction confirmation, and the secure credential storage. It is expected that those secure services, when being implemented natively in user agents, will offer a certain level of resistance and a certain level of trustworthiness. In the following section, those features will be detailed in the form of APIs and their security merits. 170 |

171 | 172 |

4. Secure transaction and secure credential storage APIs

173 | 174 |

This section contains the API descriptions and the different rationale for the architecture and design choices. It covers both functionalities related to the storage and usage of credentials in a hardware based token, and the secure transaction confirmation. Those functions rely on the presence of a credential, referred to here as a key.

175 |

The life cycle of this key is usual : creation, usage and deletion. In the framework of this short life community group, we will take the following assumptions on the key lifecycle :

176 |
    177 |
  • the key has already been generated
    • 178 |
  • the service using the key is an authorized service - in the framework of the SOP, it is the same service that created the key. The Community Group is in parallel also working on the definition of a mechanism to allow an entity to use some keys generated by another entity, but this requires the definition of a new type of data, associated with a specific key, and this is for future deliverable. Note : all use cases are envisaged with a pre-existing key set.
    • 179 |
180 |

4.1 Secure transaction interface

181 | 182 |

NOTE: This subpart of the API is relying upon pre-existing keys.

183 | 184 |

4.1.1 Secure transaction API

185 | 186 |
187 |
188 | Web IDL 189 |
190 |
191 | 
192 | 					
193 | [NoInterfaceObject]
194 | enum UVMMode { "passive", "presence", 
195 | "os", "active" };
196 | 
197 | [Exposed=(Window,Worker)]
198 | interface Crypto {
199 | ...
200 |   readonly attribute HWCrypto hwCrypto;
201 | ...
202 | };
203 | 
204 | [Exposed=(Window)]
205 | interface HWCrypto {
206 | 	Promise<any> confirm(DOMString origin, 
207 | 			DOMString NRMessage, 
208 | 			UVMMode mode, 
209 | 			ArrayBuffer[] issuingAuthorities);
210 | 	Promise<any> deviceAuthentication(DOMString origin, 
211 | 			BufferSource challenge, 
212 | 			ArrayBuffer[] issuingAuthorities);
213 | 	Promise<any> sign(DOMString origin, 
214 | 			DOMString NRMessage, 
215 | 			BufferSource data, 
216 | 			UVMMode mode, 
217 | 			ArrayBuffer[] issuingAuthorities);
218 | }
219 | 					
220 |
221 |
222 |
223 | 224 |

4.1.2 Secure transaction API details

225 | 226 |

The secure transaction confirmation aims to give the assurance to a remote entity that a transaction is confirmed by the user. Its value relies in the fact that the requested confirmation was sent to the user, was displayed to the user with no alteration and that the user confirmed exactly what was displayed. This is the 'What You See Is What You Confirm' principle.

227 |
    228 |
  • Transaction confirmation: This operation is defined to request from the browser and underlying security capabilities to ensure that the transaction context, also called non-repudiation message, has been presented to the end-user and provide non-repudiation
    • 229 |
  • Device authentication: This operation should be used when the relying party is trying to use a hardware key to authenticate the device without any user consent
    • 230 |
  • Digital signature: This operation is defined to allow binary data signature.
    • 231 |
232 | 233 |

234 | 4.1.3 Data types

235 | 236 | 237 |
238 |
UVMMode
239 |
240 | The type of user verification method mode prior to the key usage for the corresponding method. The recognized user verification modes values 241 | are "passive", "presence", "active" and "os". "passive" means that the no user interaction has been done, "presence" means that someone confirms the operation on the device, "active" means that the user has been actively authenticated and "os" means that the confirmation relies upon the OS either through PIN, fingerprint or any other end-user verification methods. The user experience of verification (including recovery procedures) is the same as provided natively by the OS itself, which may carry its own strength or weakness. 242 |
243 |
244 |

4.1.4 Methods and parameters

245 | 246 |
4.1.4.1 The confirm method
247 | 248 |

249 | The confirm 250 | method returns a new Promise object that will display the origin and the 251 | NRMessage, sign the hash of the NRMessage using 252 | the a key issued by one of the issuingAuthorities and by verifying the user according to the UVMMode. It must act 253 | as follows: 254 |

255 |
    256 |
  1. 257 |

    258 | Let mode be the mode parameter 259 | passed to the confirm method. 260 |

    261 |
    2. 262 |
  2. 263 |

    264 | Let issuingAuthorities, origin and NRMessage be the result of cloning the data 265 | of the issuingAuthorities, origin and NRMessage parameters passed to the 266 | confirm method respectively. 267 |

    268 |
    3. 269 |
  3. 270 |

    271 | If an error occurred, return a Promise rejected with 272 | the corresponding invalid parameter(s). 273 |

    274 |
    4. 275 |
  4. 276 |

    277 | Let promise be a new Promise. 278 |

    279 |
    5. 280 |
  5. 281 |

    282 | Return promise and asynchronously perform the remaining steps. 283 |

    284 |
    6. 285 |
  6. 286 |

    287 | If the following steps or referenced procedures say to 288 | throw an error, 289 | reject promise with 290 | the returned error and then 291 | terminate the algorithm. 292 |

    293 |
    7. 294 |
  7. 295 |

    296 | The trusted UI should request the selection of a key by the user. The list proposed by the browser should rely upon those available 297 | in the various secure elements or requests the user to add the secure element (connected or contactless) and update the list correspondingly. The list should be 298 | filtered according to the issuingAuthorities: this parameter should include the array of the public keys of the issuing authorities. If this values is empty, no filtering should be applied. This step can be bypassed if the user has registered a prefered key for this origin, but then the key should be presented with the NRMessage. In this case, the browser should ensure that the prefered key is still acceptable in regards to the current operation issuingAuthorities parameter. 299 | At this step, if the user cancels the operation or if no key match the requirements, then let throw a AbortError. 300 |

    301 |
    8. 302 |
  8. 303 |

    304 | Let present to the end-user the origin and the non repudiation message (NRMessage) and the user interface to either confirm the presence or authenticate according to the UVMMode. 305 | At this step, if the user cancels the operation or if the user verification method fails too many times, then let throw a AbortError. 306 |

    307 |
    9. 308 |
  9. 309 |

    310 | Let signature-nrmessage be the result of performing the signature 311 | operation with the hash of the NRMessage. 312 |

    313 |
    10. 314 |
  10. 315 |

    316 | Resolve promise with signature-nrmessage and, if applicable, key the public part of key used to sign. 317 |

    318 |
    11. 319 |
320 |
4.1.4.2 The deviceAuthentication method
321 | 322 |

323 | The deviceAuthentication 324 | method returns a new Promise object that will sign the hash of the challenge using 325 | a key issued by one of the issuingAuthorities. It must act 326 | as follows: 327 |

328 |
    329 |
  1. 330 |

    331 | Let issuingAuthorities and origin 332 | of the issuingAuthorities and origin parameters passed to the 333 | deviceAuthentication method respectively. 334 |

    335 |
    2. 336 |
  2. 337 |

    338 | If an error occurred, return a Promise rejected with 339 | the corresponding invalid parameter(s). 340 |

    341 |
    3. 342 |
  3. 343 |

    344 | Let promise be a new Promise. 345 |

    346 |
    4. 347 |
  4. 348 |

    349 | Return promise and asynchronously perform the remaining steps. 350 |

    351 |
    5. 352 |
  5. 353 |

    354 | If the following steps or referenced procedures say to 355 | throw an error, 356 | reject promise with 357 | the returned error and then 358 | terminate the algorithm. 359 |

    360 |
    6. 361 |
  6. 362 |

    363 | Let signature be the result of performing the signature 364 | operation with the hash of the challenge. The signature should be performed with the first key that is issued by one of the issuingAuthorities. The requesting SP has to ensure that the corresponding key will not require a user verification method otherwise it will throw a AbortError. 365 |

    366 |
    7. 367 |
  7. 368 |

    369 | Resolve promise with signature and, if applicable, key the public part of key used to sign. 370 |

    371 |
    8. 372 |
373 | 374 |
4.1.4.3 The sign method
375 |

376 | The sign 377 | method returns a new Promise object that will display the origin and the 378 | NRMessage, sign the hash of the NRMessage and the hash of the data using 379 | the a key issued by one of the issuingAuthorities and by verifying the user according to the UVMMode. It must act 380 | as follows: 381 |

382 |
    383 |
  1. 384 |

    385 | Let mode be the mode parameter 386 | passed to the sign method. 387 |

    388 |
    2. 389 |
  2. 390 |

    391 | Let issuingAuthorities, origin, data and NRMessage be the result of cloning the data 392 | of the issuingAuthorities, origin, data and NRMessage parameters passed to the 393 | sign method respectively. 394 |

    395 |
    3. 396 |
  3. 397 |

    398 | If an error occurred, return a Promise rejected with 399 | the corresponding invalid parameter(s). 400 |

    401 |
    4. 402 |
  4. 403 |

    404 | Let promise be a new Promise. 405 |

    406 |
    5. 407 |
  5. 408 |

    409 | Return promise and asynchronously perform the remaining steps. 410 |

    411 |
    6. 412 |
  6. 413 |

    414 | If the following steps or referenced procedures say to 415 | throw an error, 416 | reject promise with 417 | the returned error and then 418 | terminate the algorithm. 419 |

    420 |
    7. 421 |
  7. 422 |

    423 | The trusted UI should request the selection of a key by the user. The list proposed by the browser should rely upon those available 424 | in the various secure elements or requests the user to add the secure element (connected or contactless) and update the list correspondingly. The list should be 425 | filtered according to the issuingAuthorities: this parameter should include the array of the public keys of the issuing authorities. If this values is empty, no filtering should be applied. This step can be bypassed if the user has registered a prefered key for this origin, but then the key should be presented with the NRMessage. In this case, the browser should ensure that the prefered key is still acceptable in regards to the current operation issuingAuthorities parameter. 426 | At this step, if the user cancels the operation or if no key match the requirements, then let throw a AbortError. 427 |

    428 |
    8. 429 |
  8. 430 |

    431 | Let present to the end-user the origin and the NRMessage and the user interface to either confirm the presence or authenticate according to the UVMMode. 432 | At this step, if the user cancels the operation or if the user verification method fails too many times, then let throw a AbortError. 433 |

    434 |
    9. 435 |
  9. 436 |

    437 | Let signature-nrmessage be the result of performing the signature 438 | operation with the hash of the NRMessage and signature-data be the result of performing the signature operation with the hash of the data. 439 |

    440 |
    10. 441 |
  10. 442 |

    443 | Resolve promise with signature-nrmessage and, if applicable keythe public part of key used to sign. 444 |

    445 |
    11. 446 |
447 | 448 |

4.1.5 Exceptions

449 |

450 | The methods of the HWCrypto interface return errors 451 | by rejecting the returned promise with a predefined exception defined in ECMAScript 452 | [ECMA-262] or 453 | DOMException. The following predefined exceptions are 454 | used: TypeError. The following DOMException types from 455 | [DOM4] are used: 456 |

457 | 458 | 459 | 460 | 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 |
TypeMessage (optional)
NotSupportedErrorThe UVMMode is not supported
AbortErrorThe operation was aborted
SyntaxErrorA required parameter was missing or out-of-range
UnknownErrorThe operation failed for an unknown transient reason (e.g. out of memory)
DataErrorData provided to an operation does not meet requirements
OperationErrorThe operation failed for an operation-specific reason
489 |

490 | When this specification says to 491 | throw an error, the user agent must 492 | throw an error as described in 493 | [WebIDL]. When this occurs in a sub-algorithm, 494 | this results in termination of execution of the sub-algorithm and all ancestor algorithms 495 | until one is reached that explicitly describes procedures for catching exceptions. 496 |

497 | 498 |

4.1.6 Security considerations

499 |

This 4.1 section covers the various usages of keys. The use cases (transaction confirmation, signature, device authentication) are not highly sensitive in terms 500 | of transaction confidentiality, which means that standard SOP rules are considered sufficient without any need for end-to-end encryption (i.e. from SP to the Hardware Secure Device).
501 | To avoid context swapping, it is mandatory that the non-repudiation message contains specific data for the requested 502 | transaction with the requesting party, the purpose of the transaction and the date of the operation.

503 | 504 |

Assumption: for many different reasons, complex data are not the right 505 | format to get the end-user consent and confirm her/his acknowledgment:

506 |
    507 |
  • Liability: The major reasons is that this type of API is targeting valuable transactions with liability. 508 | And for most regulations, liability relies upon the end-user capability to understand the message and confirm it. 509 | So only the simplest format should be considered: no color, no emphasis, no image. 510 |
    • 511 |
  • Technical: structured documents (XHTML, XML, RDF, PDF ...) cannot be presented in trusted UI
    • 512 |
  • Accessibility: no image should be used
    • 513 |
514 |

So it should be:

515 |
    516 |
  • text only
    • 517 |
  • not too short: it should give enough context information to protect against social engineering and replay attacks
    • 518 |
  • not too long: it should be displayable on almost every end-user terminal and read by the end-user
    • 519 |
  • scoped: it should target a particular operation (type, amount, beneficiary ...) at a particular time
    • 520 |
  • localized (UTF-8)
    • 521 |
522 |

What it should not be:

523 |
    524 |
  • full list of terms and conditions - but it can be the operation to confirm that the end-user agree with a particular version of the terms and conditions
    • 525 |
  • a generic operation request because it would not be scoped (i.e: "Do you confirm this signature operation ?" or "Do you want to confirm the authentication ?")
    • 526 |
527 |

528 | NOTE: a particular attention should be paid to UTF-8 characters support with the wide variety of similar characters. 529 | Therefore, both the context and the data should be signed at the same time with the same key. It is then up to the relying 530 | party to ensure that the data associated with the context are both signed and they match the initial request 531 | The user has accepted the context (and liability may rely only on that context in regards to this cryptographic operation) 532 | The data signature (i.e. PDF signature) is then a way to embed into the data the user consent.

533 |

It could occur that the binary data are altered before signature by a malware or javascript or any software attacking the user agent. in such scenario, the altered binary data would be successfully signed on the user agent side. It is up to the relying party to check that the binary data and the context received are signed with the same key. In addition, the relying party, as part of its security policy, will be able to reject any attempt to submit binary signed data if they are not provided with a valid signed context. 534 |

535 |

Within this signature operation, the mode for the user verification method MUST NOT be neither "passive" nor "presence".

536 | 537 | 538 | 539 |

4.2 Secure Credential Storage

540 | 541 |

This subpart describes a JavaScript API for discovering named, origin-specific pre-provisioned cryptographic keys stored into hardware secure device to be used with the Web Cryptography API. Pre-provisioned keys are keys which have been made available to the UA by means other than the generation, derivation, importing and unwrapping functions of the Web Cryptography API. Origin-specific keys are keys that are available only to a specified origin. Named keys are identified by a name assumed to be known to the origin in question and provisioned with the key itself.

542 | 543 |

4.2.1 Secure Credential Storage API

544 | 545 |

This API relies on the existing WebCrypto API and provide some additionnal features to support key naming, as proposed in WebCrypto Key Discovery note, but also defines the notion of HardwareSecureDevice which represents any form of hardware cryptographic device acting as cryptographic provider, in a similar way of what JAVA defines with its framework Java Cryptography Architecture (JCA), to bring new capabilities to the SubtleCrypto interface and in particular the persistent and secure storage of keys.

546 | 547 |
4.2.1.1 Window interface
548 | 549 |

Window interface is enhanced to expose hardware secure device management service.

550 | 551 |
552 |
553 | Web IDL 554 |
555 |
556 | 
557 | 					
558 | [NoInterfaceObject]
559 | interface GlobalHardwareSecureDeviceManager {
560 |   readonly  attribute  HardwareSecureDeviceManager  hsdm;
561 | };
562 | 
563 | Window implements GlobalHardwareSecureDeviceManager;
564 | WorkerGlobalScope implements GlobalHardwareSecureDeviceManager;
565 | 					
566 |
567 |
568 |
569 | 570 |
4.2.1.2 HardwareSecureDeviceManager interface
571 | 572 |

The HardwareSecureDeviceManager interface provides access to hardware secure devices and is the source of events notifying their presences. 573 | The notion of presence is important because a hardware secure device may not always be fixed in the same hardware environment as the user agent (e.g. an embedded secure element or a TEE); some hardware secure devices may be shared with several user agents (e.g. smart cards or NFC cards).

574 | 575 |
576 |
577 | Web IDL 578 |
579 |
580 | 
581 | 					
582 | [Exposed=(Window,Worker)]
583 | interface HardwareSecureDeviceManager : EventTarget {
584 |     readonly  attribute  HardwareSecureDevice[]  hardwaresecuredevices;
585 |               attribute  EventHandler?           onHardwareSecureDevicePresent;
586 |               attribute  EventHandler?           onHardwareSecureDeviceRemoval;
587 | };
588 | 					
589 |
590 |
591 |
592 | 593 |

The attribute hardwaresecuredevices represents the list of hardware secure devices present and acccessible by UA at the time the attribute is accessed. UA is in charge to add or remove element in that array depending of the evolution of the environment in term of presence and absence of hardware secure device. User MAY define two event listeners (onHardwareSecureDevicePresent and onHardwareSecureDeviceRemoval) which will be called by UA to notify the user of the ongoing changes of the environment in term of presence or absence of hardware secure device.

594 | 595 |
4.2.1.3 HardwareSecureDevice interface
596 | 597 |

The HardwareSecureDevice interface extends the SubtleCrypto interface providing a different implementation of one or more SubtleCrypto methods in order to let the hardware device handle the cryptographic operation internaly instead of the UA in software. 598 | It can be viewed as a cryptographic provider bringing cryptographic capabilities of a hardware device to the WebCrypto API in a transparent manner. 599 | UA MAY defines other classes extending the HardwareSecureDevice one representing different types of hardware secure device with specific implementation. One implementation COULD be using PKCS#11 as transport layer to communicate with a compatible hardware secure devices

600 | 601 |
602 |
603 | Web IDL 604 |
605 |
606 | 
607 | 					
608 | [Exposed=(Window,Worker)]
609 | interface HardwareSecureDevice : SubtleCrypto {
610 | 	readonly  attribute  DOMString     name;
611 | 	readonly  attribute  boolean       ispresent;
612 | };
613 | 					
614 |
615 |
616 |
617 | 618 |

The attribute name is used to identify in a human readable way the hardware secure device. It will typically be used by the browser when requesting permission to the user to access a given hardware secure device. The attribute ispresent is used by UA to indicate if the given hardware secure device is currently accessible. This attribute will typically be checked by UA before trying to perform any cryptographic operation on the hardware secure device.

619 | 620 |
4.2.1.4 CryptoKey interface
621 | 622 |

The CryptoKey interface as defined in the WebCrypto Key Discovery note requires some modification in order to support hardware secure device. The CryptoKey interface and in particular the method getKeyByName is improved to add an optional parameter of hardwaresecuredevice type. If this parameter is provided, the look up for a key with the given name MUST occur only in the targeted hardware secure device. Prior to that, UA MUST validate the presence of the targeted hardware secure device first and then UA MUST call the same method than the callee one but on the provided hardware secure device object. The remaining executive flow remains unchanged as defined in WebCrypto API. In case of absence UA MUST throw an exception by using the reject promise. If the optional parameter is not provided, the search MUST occur only in software wherever the keys are usually stored by UA.

623 | 624 |
625 |
626 | Web IDL 627 |
628 |
629 | 
630 | 					
631 | [NoInterfaceObject]
632 | interface CryptoKeys {
633 |     Promise getKeyByName (DOMString name, 
634 |                           optional HardwareSecureDevice hsd);
635 | };
636 | 					
637 |
638 |
639 |
640 | 641 |
4.2.1.5 SubtleCrypto interface
642 | 643 |

The SubtleCrypto interface as defined in the WebCrypto API requires some modification in order to support hardware secure device. All the methods of the SubtleCrypto interface are improved to add an optional parameter of hardwaresecuredevice type. If this parameter is provided, the cryptographic operation MUST occur in the targeted hardware secure device. Prior to that, UA MUST validate the presence of the targeted hardware secure device first and and then UA MUST call the same method than the callee one but on the provided hardware secure device object. The remaining executive flow remains unchanged as defined in WebCrypto API. In case of absence UA MUST throw an exception by using the reject promise. If the optional parameter is not provided, the cryptographic operation MUST occur only in software with the default UA implementation.

644 | 645 |
646 |
647 | Web IDL 648 |
649 |
650 | 
651 | 					
652 | [Exposed=(Window,Worker)]
653 | interface SubtleCrypto {
654 | 				   
655 |   Promise encrypt(AlgorithmIdentifier algorithm,
656 |                        CryptoKey key,
657 |                        BufferSource data
658 |                        optional HardwareSecureDevice hsd);
659 | 
660 |   Promise decrypt(AlgorithmIdentifier algorithm,
661 |                        CryptoKey key,
662 |                        BufferSource data
663 |                        optional HardwareSecureDevice hsd);
664 | 					   
665 |   Promise sign(AlgorithmIdentifier algorithm,
666 |                     CryptoKey key,
667 |                     BufferSource data
668 |                     optional HardwareSecureDevice hsd);
669 | 					   
670 |   Promise verify(AlgorithmIdentifier algorithm,
671 |                       CryptoKey key,
672 |                       BufferSource signature,
673 |                       BufferSource data
674 |                       optional HardwareSecureDevice hsd);
675 | 					  
676 |   Promise digest(AlgorithmIdentifier algorithm,
677 |                       BufferSource data
678 |                       optional HardwareSecureDevice hsd);
679 | 
680 |   Promise generateKey(AlgorithmIdentifier algorithm,
681 |                           boolean extractable,
682 |                           sequence keyUsages
683 |                           optional HardwareSecureDevice hsd);
684 | 						  
685 |   Promise deriveKey(AlgorithmIdentifier algorithm,
686 |                          CryptoKey baseKey,
687 |                          AlgorithmIdentifier derivedKeyType,
688 |                          boolean extractable,
689 |                          sequence keyUsages
690 |                          optional HardwareSecureDevice hsd);
691 | 						 
692 |   Promise deriveBits(AlgorithmIdentifier algorithm,
693 |                           CryptoKey baseKey,
694 |                           unsigned long length
695 |                           optional HardwareSecureDevice hsd);
696 |   
697 |   Promise importKey(KeyFormat format,
698 |                          (BufferSource or JsonWebKey) keyData,
699 |                          AlgorithmIdentifier algorithm,
700 |                          boolean extractable,
701 |                          sequence keyUsages
702 |                          optional HardwareSecureDevice hsd);
703 | 						 
704 |   Promise exportKey(KeyFormat format, 
705 |                          CryptoKey key
706 |                          optional HardwareSecureDevice hsd);
707 | 
708 |   Promise wrapKey(KeyFormat format,
709 |                        CryptoKey key,
710 |                        CryptoKey wrappingKey,
711 |                        AlgorithmIdentifier wrapAlgorithm
712 |                        optional HardwareSecureDevice hsd);
713 | 
714 |   Promise unwrapKey(KeyFormat format,
715 |                          BufferSource wrappedKey,
716 |                          CryptoKey unwrappingKey,
717 |                          AlgorithmIdentifier unwrapAlgorithm,
718 |                          AlgorithmIdentifier unwrappedKeyAlgorithm,
719 |                          boolean extractable,
720 |                          sequence keyUsages
721 |                          optional HardwareSecureDevice hsd);
722 | };
723 | 					
724 |
725 |
726 |
727 | 728 |

4.2.2 Permission

729 | 730 |

UA MUST not start to exchange with an Hardware Secure Device without the express permission of the user. UA MUST acquire permission through a user interface, unless they have prearranged trust relationships with users. The user interface MUST include the host component of the document's URI and a reminder of the Hardware Secure Device name targetted. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context is navigated to another URL) must be revocable and UA MUST respect revoked permissions.

731 |

Some Hardware Secure Device MAY require to be unlocked, using a secure mechanism, before being accessed. In that case, UA MUST provide a way to unlock through a user interface with input capability (text value, fingerprint...). The user interface MUST include the host component of the document's URI and a reminder of the Hardware Secure Device name targeted. The data used to unlock the Hardware Secure Device MUST be transmitted in a secure way and UA MUST NOT store those data.

732 | 733 |

5. Implementation requirements

734 | 735 |

These requirements are provided to split the responsibilities of each vendor / software providers for the different implementation environments

736 | 737 |

5.1 Attestations

738 |

739 | Both the Secure Element and the TrustedUI should be securely identified 740 | by attestation. These attestations should be implemented as exposed in the the FIDO 2.0 Attestations. 741 |

742 | 743 |

5.2 PC-like environments

744 | 745 |

It is typically the environment where secure elements - either smartcards with readers or usb tokens - are used 746 | with middleware through PKCS#11 or Microsoft Minidriver. In this architecture, the trusted UI is:

747 |
    748 |
  • Either the middleware when the signature is requested through PKCS#11 library
    • 749 |
  • Or the Microsoft Windows operating system which manage the secure element user interface for CSP/CNG API
    • 750 |
751 |

In this implementation, it means that the origin of the request and the non repudiation message 752 | should be displayed by the middleware or the Windows OS in a trusted way.

753 | 754 |

To limit the capability of a website to request the usage of the cryptographic API, 755 | browser implementers SHOULD support a mechanism of white / black lists of 756 | authorized domains (like camera access), so that an end-user could reject 757 | any request from an unknown origin. 758 |

759 |

760 | NOTE: transaction confirmation could be supported by providing the merge of the origin and the 761 | non repudiation message as the data to sign for existing API. It MUST be displayed to the end-user with the user verification method input. 762 | But signature operation will require a interface definition new method for both PKCS#11 and CSP/CNG 763 |

764 | 765 |

5.3 Mobile environments

766 | 767 |

In mobile environments, Secure Elements are either:

768 |
    769 |
  • device binded like embedded Secure Element
    • 770 |
  • roaming like SIM or external NFC/BLE factors
    • 771 |
772 |

773 | But there is no capability to add middleware. It is up the OS manufacturer to provide support for the 774 | Secure Elements and provide an API for third party applications including browsers. 775 |

776 | 777 |

5.3.1 Generic mobile environments

778 |

779 | In this situation, the trusted user interface should be part of the Operating System, interacting with the Secure Element 780 |

781 | 782 |

5.3.2 Mobile environments with Trusted Execution Environment

783 |

784 | In this situation, the browser is a trusted app and the trusted UI is relying upon the existing 785 | TEE functions (See [GP_TEE]) 786 |

787 | 788 |

5.4 About implementations considerations

789 | 790 |

Implementation into a mobile phone will require:

791 |
    792 |
  • browser modifications to interact with TEE
    • 793 |
  • a trusted application interacting with the Secure Element
    • 794 |
795 | 796 |

6. TODO

797 |

The following topics need to be managed later:

798 |
    799 |
  • Attestation retrieval by the issuing authority to evaluate the environment (TrustedUI & SE)
    • 800 |
  • Post issuance of the key: a specific operation should be added to the Secure Credential Storage API for two reasons: filtering the certified public keys to match the one accepted by the service provider and adding the certified public key during transaction confirmation, device authentication or signature
    • 801 |
  • Need to confirm is this API being operated only in the context of Priviledged Context or not
    • 802 |
803 | 804 |
805 |

7. Dependencies

806 |

This report relies on underlying specifications.

807 |
808 |
DOM
809 |
810 |

811 | A conforming user agent MUST support at 812 | least the subset of the functionality defined in DOM4 that this specification relies 813 | upon; in particular, it MUST support Promises and 814 | DOMException. 815 | [DOM4] 816 |

817 |
818 |
HTML
819 |
820 |

821 | A conforming user agent MUST support at 822 | least the subset of the functionality defined in HTML that this specification relies 823 | upon; in particular, it MUST support the 824 | ArrayBufferView typedef and the 825 | structured clone algorithm. 826 | [HTML] 827 |

828 |
829 |
Web IDL
830 |
831 |

832 | A conforming user agent MUST be a 833 | conforming implementation of the IDL fragments in this specification, as described in 834 | the Web IDL specification. [WebIDL] 835 |

836 |
837 |
838 |
839 | 840 |

A. References

841 | 842 |

A.1 Normative references

843 | 844 |
845 |
DOM4
846 |
847 | W3C DOM4, 848 | A. van Kesteren, A. Gregor, Ms2ger, Alex Russell, Robin Berjon. W3C. 849 |
Editorial note
A reference will be added to ECMAScript 6 once "Promises" are stable.
850 |
851 |
ECMA262
852 |
853 | 854 | ECMAScript 5th Edition, A. Wirfs-Brock, P. Lakshman et al. 855 |
856 |
WebCryptoAPI
857 |
858 | W3C WebCryptoAPI, Ryan Sleevi, Mark Watson. W3C. 859 |
860 |
WebCrypto Key Discovery
861 |
862 | W3C WebCrypto Key Discovery Note, Mark Watson. W3C. 863 |
864 | 865 |

A.2 Informative references

866 | 867 |
868 |
CryptoAPI
869 |
870 | Cryptography Reference, Microsoft Corporation. 871 |
872 | 873 |
OpenTEE
874 |
875 | OpenTEE project. 876 |
877 | 878 |
PKCS#11
879 |
880 | PKCS #11: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD, RSA Laboratories/EMC. 881 |
882 | 883 |
PC/SC
884 |
885 | PCSC, standard for integrating smart cards and smart card readers, PC/SC Workgroup. 886 |
887 | 888 |
Replacement for <keygen>
889 |
890 | Keygen and Client Certificates, W3C TAG. 891 |
892 |
Trusted Execution Environment
893 |
894 | Trusted Execution Environment, Global Platform. 895 |
896 | 897 |
FIDO 2.0 Attestations
898 |
899 | FIDO 2.0: Key Attestation Format, W3C WebAuth. 900 |
901 | 902 |
JCA Reference Guide
903 |
904 | Java Cryptography Architecture (JCA) Reference Guide, Oracle. 905 |
906 | 907 | 908 |
909 | 910 | 911 | -------------------------------------------------------------------------------- /hwsec-charter.html: -------------------------------------------------------------------------------- 1 | Hardware-Based Security DRAFT 2 | 3 | This page has moved to hasec-charter.html

4 | -------------------------------------------------------------------------------- /security-roadmap.md: -------------------------------------------------------------------------------- 1 | DRAFT for team discussion, 14 October, 2015, wseltzer@w3.org 2 | 3 | # W3C Security Strategy # 4 | 5 | Securing the Web is a multi-layered challenge. To secure the Web 6 | experience of end-users: its confidentiality, integrity, and 7 | authentication; we need to provide tools for end-users, for 8 | application developers, and for platform security. Moreover, the 9 | security of Web applications depends on underlying protocols, on 10 | browser and server software, hence we need to enlist the cooperation 11 | of participants throughout the ecosystem. A joint approach, can help 12 | re-establish trust in the platform as a place for commerce and 13 | communication, addressing concerns of an increasing number of Web 14 | users. We must address these challenges now because individual and 15 | enterprise users are demanding greater security and privacy; if we do 16 | not respond constructively, we risk losing trust in the platform, and 17 | losing users to other forms of interaction. 18 | 19 | # Goals 20 | 21 | Through our security and privacy efforts, W3C aims to establish 22 | justified trust in the Web platform. We aim to provide the components 23 | to uesrs and developers to assure the integrity, authenticity, and 24 | confidentiality of interactions on the Web. We must also assure that 25 | W3C Recommendations are high-quality and do not introduce new security 26 | vulnerabilities as they add new capabilities to the platform. 27 | 28 | We enlist the support of the Web community in reaching these goals, 29 | through a strategy that can be described in three layers: 30 | 31 | - Web user security 32 | 33 | - Web application security 34 | 35 | - Web platform security 36 | 37 | We also note that some security challenges are outside our ability to 38 | affect directly: operating environment and lower-level protocol flaws, 39 | poorly coded implementations, and human error cannot be specified 40 | away. Working to assure that we introduce no additionl security flaws, 41 | but rather tools for security improvement, we can cooperate to raise 42 | the Web platform. 43 | 44 | # 1. Web User Security # 45 | 46 | At the most user-facing level, we are working to secure the login and 47 | authentication experience and support secure communication channels. 48 | 49 | * Web Cryptography API 50 | 51 | [WebCrypto](http://www.w3.org/2012/webcrypto/) provides a first step 52 | toward enabling secure authentication and communication from the 53 | browser. The 54 | [Web Cryptography API](http://www.w3.org/TR/WebCryptoAPI/) spec, 55 | currently in Candidate Recommendation and implemented across major 56 | browsers, provides standard APIs to cryptographic functions such as 57 | encryption, decryption, signing, hashing, and verification. WebCrypto 58 | allows a web developer to build in their application a reliable 59 | security model protecting the user (such as authentication or secure 60 | communication between the browser and the server). 61 | 62 | 63 | * Authentication 64 | 65 | Building on the multi-factor authentication work of the 66 | FIDO Alliance, [Secure Authentication] will aim to standardize 67 | multi-factor authentication for the Web, using the combination of 68 | "something you have" with "something you know," so that hacking a 69 | password database is no longer sufficient to hijack user 70 | accounts. [Hardware-based Security] aims to improve the levels of 71 | assurance to which users and application providers are able to protect 72 | their online accounts and communications, by making hardware security services available to the Web. 73 | 74 | * HTTPS for Communications and Data Security 75 | 76 | The [Privileged Contexts](http://www.w3.org/TR/powerful-features/) 77 | draft recommends that powerful features of the Web platform, including 78 | application code with access to sensitive or private data, be 79 | delivered only in secure contexts, over authenticated and confidential 80 | channels that guarantee data integrity. As the draft indicates, 81 | "delivering code securely cannot ensure that an application will 82 | always meet a user's security and privacy requirements, but it is a 83 | necessary precondition." 84 | 85 | 86 | # 2. Web Application Security # 87 | 88 | Users' security also depends on Web application authors' ability to 89 | ensure that their applications are delivered as intended, free from 90 | spoofing, injection, and 91 | eavesdropping. [WebAppSec](http://www.w3.org/2011/webappsec/) is 92 | addressing this challenge from several angles. 93 | 94 | * Content Security Policy 95 | 96 | [Content Security Policy](http://www.w3.org/TR/CSP/) provides a policy 97 | language by which application developers can declare a security policy 98 | for a web resource. The goal of this specification is to reduce attack 99 | surface by specifying overall rules for what content may or may not 100 | do, thus preventing violation of security assumptions by attackers who 101 | are able to partially manipulate that content, for example by script 102 | injection or cross-site request forgery. An application delivered over 103 | a secure channel with CSP enabled can assure that users receive it as 104 | it was intended to be executed. New tools, such as Subresource 105 | Integrity enable the secure incorporation of aditional elements into 106 | the application. 107 | 108 | 109 | * HTTPS support 110 | 111 | Several specifications help Web application developers HTTPS-enable 112 | their Web Apps, including the 113 | [Upgrade Insecure Requests](http://www.w3.org/TR/upgrade-insecure-requests/) 114 | and [Mixed Content](http://www.w3.org/TR/mixed-content/) 115 | drafts. These, along with work such as HSTS and HPKP, help to ease the 116 | HTTPS transition for server operators, and as the proportion of HTTPS 117 | traffic grows, set user expectations that Web traffic should be 118 | secure, integrity-protected, and authenticated. 119 | 120 | * Visibility and Sandboxing 121 | 122 | Upcoming in WebAppSec, [IronFrame] proposes to eliminate clickjacking 123 | by assuring element visibility at the graphics rendering level. A 124 | developer deploying IronFrame can assure that users clicking their 125 | site's "pay" button aren't being tricked into transferring their bank 126 | balances to an imposter instead. Prompted by the 127 | [Digital Marketing Workshop](https://www.w3.org/2015/digital-marketing-workshop/agenda.html), 128 | we may see proposals for new sandboxing capabilities, to permit the 129 | trustworthy mash-up of active content from multiple sources. 130 | 131 | #3. Web Platform Security # 132 | 133 | Finally, we need to make the Web Platform a place users can expect and 134 | demand security from all their interactions. That entails upgrading 135 | the baseline security and privacy of Web interactions -- supporting 136 | the HTTPS roll-out; standardizing permission requests; sharing best 137 | practices; and assuring that all specifications include security and 138 | privacy considerations. 139 | 140 | * HTTPS transition 141 | 142 | The WebAppSec work described above not only helps to secure the 143 | experience of the applications that use HTTPS, but also set user 144 | expectations about the platform. As more providers deliver their Web 145 | applications via HTTPS, users and their user-agents can exercise a 146 | preference for secure applications. 147 | 148 | * Security and Privacy Considerations. 149 | 150 | The [TAG](https://tag.w3.org/), WebAppSec, and 151 | [Privacy Interest Group](http://www.w3.org/Privacy/) are developing a 152 | [Privacy and Security Self-Review Questionnaire](https://w3ctag.github.io/security-questionnaire/) 153 | to help groups assess the privacy and security implications of their 154 | specifications. To make such self-review a routine part of groups' 155 | progress along the Recommendation-track, we would like to require that 156 | every spec include a "Security and Privacy Considerations" section -- 157 | and ensure that WGs have access to expert advice to review and address 158 | these considerations effectively. We can do that via Process changes 159 | or guidance to and from the Director at transition reviews. Since 160 | effective security review of specifications requires participation of 161 | subject-matter experts (Working Group participants) and security 162 | experts, we believe that a strong signal to stakeholders in the work 163 | will help to spur that participation: a signal from the Director that 164 | drafts will not advance to Candidate Recommendation without explicit 165 | Security and Privacy Considerations need not depend on a change to the 166 | Process, but such a change may help to bring it to Members' attention. 167 | 168 | * Internal Liaisons 169 | 170 | An increasing number of W3C groups are recognizing that their specs 171 | will require security design in order to succeed. These include Web 172 | Payments, Web and Automotive, Web of Things, and Web Platform. To help 173 | them design security and privacy into their architecture, where it can 174 | be most effective, we propose to work toward a team of community 175 | liaisons who can work between PING / WebSec and the subject-specific 176 | WGs, becoming internal experts on the subject matter and its security 177 | and privacy implications. 178 | 179 | 180 | # Focus for 2016 # 181 | 182 | * Improved authentication: Secure Authentication and Hardware-Based 183 | Security 184 | * Web Application Security: keep specs moving forward 185 | * Improved reviews: Chair training, team and community expert advice; 186 | require Security and Privacy Considerations 187 | * Internal liaison with security requirements around W3C: Web 188 | Payments, Web and Automotive, Web of Things, Web Platform 189 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [94247] 3 | , "contacts": ["wseltzer", "samuelweiler"] 4 | , "policy": "open" 5 | , "repo-type": "process" 6 | } 7 | -------------------------------------------------------------------------------- /web-authentication-charter.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | [DRAFT] Web Authentication Working Group Charter 7 | 8 | 9 | 10 | 11 | 47 | 48 | 49 | 71 | 72 | 73 |
74 |

STATUS: Charter Approved

75 |

An updated version of this charter has been approved by the W3C Membership and Director. The Web Authentication Working Group is now launched and on GitHub.

76 |

[DRAFT] Web Authentication Working Group Charter

77 | 78 |

This charter was sent for W3C Advisory Committee review December 18, 2015.

79 | 80 |

81 | The mission of the Web Authentication Working Group, in the Security Activity is to define a client-side API providing strong authentication functionality to Web Applications.

82 | 83 | 84 | 85 |
86 |

Join the Web Authentication Working Group.

87 |
88 | 89 |
90 | 91 | 92 | 95 | 98 | 99 | 100 | 103 | 106 | 107 | 108 | 115 | 116 | 119 | 123 | 124 | 125 | 128 | 131 | 132 | 133 | 136 | 141 | 142 |
93 | Start date 94 | 96 | [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 97 |
101 | End date 102 | 104 | [dd monthname yyyy] (1 year from start date) 105 |
117 | Chairs 118 | 120 | Richard Barnes, Mozilla
121 | Anthony Nadalin, Microsoft 122 |
126 | Team Contacts 127 | 129 | TBD (0.2 FTE) 130 |
134 | Meeting Schedule 135 | 137 | Teleconferences: 1-hour calls will be held weekly. 138 |
139 | Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, no more than 3 per year. 140 |
143 | 144 |
145 | 146 | 147 |
148 |

Goals

149 |

The Web Authentication Working Group will develop recommendation-track specifications defining an API, as well as signature and attestation formats which provide an asymmetric cryptography-based foundation for authentication of users to Web Applications.

150 | 151 | Overall goals include obviating the use of shared secrets, i.e. passwords, as authentication credentials, facilitating multi-factor authentication support as well as hardware-based key storage while respecting the Same Origin Policy. 152 |

153 | 154 |
155 |
156 |

Scope

157 |

158 | The Working Group will determine use cases that the API needs to support and use these to derive requirements. Success will be determined by the implementation of API features as defined in this section of the charter. 159 |

160 | API Features in scope are: 161 | (1) Requesting generation of an asymmetric key pair within a specific scope (e.g., an origin); (2) Proving that the browser has possession of a specific private key, where the proof can only be done within the scope of the key pair. 162 |

163 | Dependencies exist on the Credential Management API in the W3C Web Application Security Working Group. 164 |

165 | Note that the details of any user experience (such as prompts) will not be normatively specified, although they may be informatively specified for certain function calls. 166 |

167 | The Web Authentication Working Group should aim to produce specifications that have wide deployment and should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The APIs should integrate well with Web Applications and so should be developed in concert with Web Application developers and reviewed by the Web Application Security and Web Platform Working Groups. 168 |

169 | Comprehensive test suites should be developed for the specification to ensure interoperability. User-centric privacy considerations of device management and credentials should be taken into account. The Working Group may produce protocol standards as needed by the API. 170 | 171 | 172 |

173 | 174 |
175 |

Out of Scope

176 |

Out of scope: federated identity, multi-origin credentials, low-level access to cryptographic operations or key material.

177 | 178 |
    179 |
180 |
181 | 182 |
183 |

Success Criteria

184 |

In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each feature defined in the specification.

185 |
186 |
187 | 188 | 189 | 190 |
191 |

192 | Deliverables 193 |

194 | 195 |

The group will aim to produce FPWDs of its normative deliverables in Q1 2016, and send them to CR by December 2016. More detailed milestones and updated publication schedules will be available on the group publication status page.

196 | 197 | 198 |
199 |

200 | Normative Specifications 201 |

202 |

203 | The working group will deliver at least the following: 204 | 205 |

Web Authentication API
206 | 207 |
This specification will make secure authentication available to Web application developers via a standardized API providing the operations detailed in the scope section. The FIDO 2.0 Web APIs will be an input into this standard.
208 |
209 |
Data and signature formats
210 |
211 | Formats for signed data and verifiable attestation of a signer's properties. The FIDO 2.0 Attestations and FIDO 2.0 Signature Format will be inputs into this standard.
212 | 213 |
214 | 215 |

The specifications must contain a section detailing any known security implications for implementers, Web authors, and end users. The Web Authentication WG will actively seek an open security review. 216 |

217 | The specifications should take advantage of existing platform and operating-system authentication libraries as appropriate. 218 |

219 | 220 | 221 |

222 |

223 | Other Deliverables 224 |

225 |

226 | Other non-normative documents may be created such as: 227 |

228 | 229 | Test suite for the Web Authentication API; Primer or Best Practice documents to support Web developers when designing applications utilizing the Web Authentication API. 230 | 231 |
    232 |
  • Use case and requirement documents;
    • 233 |
  • Test suite and implementation report for the specification;
    • 234 |
  • Primer or Best Practice documents to support web developers when designing applications.
    • 235 |
  • Overall protocol design description and flow diagram, including reference to the protocol by which a web site interacts with a token by way of a 236 | browser, to accomplish the above API features.

    237 |
238 |
239 |
240 | 241 | 242 | 243 |
244 |

Coordination

245 |

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working Groups, and with the TAG. Invitation for review will be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.

246 | 247 |

Additional technical coordination with the following Working Groups will be made, per the W3C Process Document:

248 | 249 |
250 |

W3C Groups

251 |
252 |
Web Application Security Working Group
253 |
Coordination with Credential Management API and application security. 254 |
Web Platform Working Group
255 |
Coordination on API design. 256 | 257 |
Privacy Interest Group
258 |
Coordination on privacy implications. 259 | 260 |
Accessible Platform Architectures (APA) Working Group
261 |
Coordination to review accessibility requirements for APIs and for any direct user interfaces that may be specifie.d 262 | 263 |
264 | 265 | 266 |

External Organizations

267 |
268 |
IETF Token Binding Working Group
269 |
Coordination on token and session management.
270 |
271 | 272 | 273 |
274 |
275 | 276 | 277 | 278 |
279 |

280 | Participation 281 |

282 |

283 | To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a day per week towards the Working Group. There is no minimum requirement for other Participants. 284 |

285 |

286 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. 287 |

288 |

289 | The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy. 290 |

291 |
292 | 293 | 294 | 295 |
296 |

297 | Communication 298 |

299 |

300 | Technical discussions for this Working Group are conducted in public. Meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests. 301 |

302 |

303 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Authentication Working Group home page. 304 |

305 |

306 | Most Web Authentication Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. 307 |

308 |

309 | This group primarily conducts its technical work through a GitHub repository and on the public mailing list public-webauthn@w3.org (archive). The public is invited to raise github issues. 310 |

311 |

312 | The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. 313 |

314 |
315 | 316 | 317 | 318 |
319 |

320 | Decision Policy 321 |

322 |

323 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

324 |

325 | However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections. 326 |

327 |

328 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. 329 | 330 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. 331 | 332 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group. 333 |

334 |

335 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director. 336 |

337 |

338 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes). 339 |

340 |
341 | 342 | 343 | 344 |
345 |

346 | Patent Policy 347 |

348 |

349 | To promote the widest adoption of Web standards, W3C Recommendations have a Royalty-Free IP commitment from Working Group participants, which operate under the W3C Patent Policy (5 February 2004 Version). 350 | 351 | The W3C Patent Policy Implementation details the disclosure obligations for this group. 352 |

353 |
354 | 355 | 356 | 357 |
358 |

Licensing

359 |

This Working Group will use the W3C Document License for all its deliverables.

360 |
361 | 362 | 363 | 364 |
365 |

366 | About this Charter 367 |

368 |

369 | This charter has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 370 |

371 | 372 | 443 |
444 | 445 | 446 |
447 | 448 | 469 | 470 | 471 | 472 | --------------------------------------------------------------------------------