IG/webcryptonext workshop

W3C Workshop on Authentication, Hardware Tokens and Beyond : Next Steps

The workshop was held on the 10-11 September 2014, Silicon Valley (Mountain View), California This wiki page aims to collects minutes, discussion and potential W3C draft charter, allowing the topics discussed to be landing in W3C.

Workshop minutes

Actual minutes of the workshop are available day1 and day2

Workshop Take Away

Purpose of this section : gather the common technologies the workshop attendees would be ready to work on, requiring some definition/clarification/dive in

Next steps a status about that workshop has been made to the W3C TAG on the 1st of Oct here [1]

What are the use case we want to address ?

identity ? yes/no
authentication of a user ? yes/no
authentication of a device ? yes/no
signing a transaction ? yes/no
getting benefit of the existing fleet : re-using token distributed by government, banking, other service providers ? yes/no
one-click button for encrypting/decrypting a message ? yes/no
WebRTC authentication ? yes/no
provisioning user credentials, owned and managed by the user ? yes/no
proof of possession management (cookies and others) by the user independently from the browser ? yes/no
protecting user data from service/device providers or government spoofing ? yes/no
one click button allowing user to activate protection of user communication ? yes/no
contextual information completing the authentication ? yes/no
manage keys not owned by a browser, from a browser ? yes/no
please add your use case !

What technical feature has been discussed up to now, with support form the workshop attendees ?

simple dev facing authent API (either Two Factor, Kill Passwords) -> 14
Web Crypto API extensions - algo discovery -> 14
Web Crypto API extensions - key discovery -> 25
Web Crypto API extensions - device discovery -> 23
Web Crypto API extensions - big nums -> 11
Web Crypto API extensions - certificate metadata -> 9
Web Crypto API extensions - hardware token in scope -> 30+
Web Crypto API extensions - attestation provenance -> 21
Web Crypto API extensions - discovery w/ access control model, possibly extension of CORS -> 15
Web Crypto API extensions - key storage persistence -> 12
Web Crypto API extensions - system key -> 10
Web Crypto API extensions - multi origin support -> 16
Web Crypto API extensions - user owner key, spec from origin bound key -> 14
Web Crypto API extensions - way to fold origin signature, attested signature, context -> 15
local user authentication gesture + binding of key usage -> 22
anonymous credential -> 9

Potential security features for those use case

defining assurance level provided by the services ? yes/no
enable tools for risk management on the service providers side ? yes/no
re-thing the Same Origin Policy associated with the current web crypto key management ? yes/no
defining a policy associated with credentials (aka keys) managed ? yes/no

What mechanism do we need to implement the use cases ?

Means to allow user to choose his/her secure enabler ? yes/no
Trusted UI ? yes/no
Discovery mechanism of the secure enablers available ? yes/no
Security mediation mechanics to take into account the user and the service provider wishes ? yes/no
Biometric management from a web app ? yes/no

Can the proposed APIs be implemented in a way that allows open competition and permisionless innovation compatible with Open Stand principles? http://open-stand.org/permissionless-innovation-impacting-the-future-of-the-internet/

Some proposals made require pay-to-play implementations of some necessary components. For example, the ability to put a trusted application (TA) into a TEE is typically gated by contracts with mobile operators and/or hardware vendors. Without any evidence of any of these gatekeepers offering RAND access to these services, such APIs mostly enable rent-seeking by those controlling the access instead of free user choice among services and permissionless innovation. If the W3C can or must choose between which proposals to pursue and develop, should those that offer open or RAND access to all web applications be preferred over those which do not?
Other proposals such as independent tokens that include smart cards integrated with web browsers will leave the control to users. These can be used not only for centrally managed identities if the user chooses to but also for user managed identities again if the user chooses to.

Other questions related to vocabulary !

What do we mean by attestation ?

What do we mean by secure enabler ?

What do we mean by secure storage ?

Potential things that need do be done to complete/prepare the technical work?
list use cases
list the suggested list of token (eg : estonien eID, US, ...)
list necessary functions
guidelines for middleware integration
list standardization bodies to liaise with

Can we re-use FIDO technology ?

What are the features not present in FIDO today, required to implement e-gov scheme, e-banking expectations ?

     (Keeping in mind that user managed identity, e.g. UAF, has very little in common with any of the centrally managed identities, e.g., e-gov or e-banking. 
      While both should and can co-exist one cannot replace the other.)

Good practice designing API : what do we mean by a box ?

A box is enabling services, taking into account the flavor of form factor supporting the operations (software/hardware/TEE), allowing balance between sever and client operations.
The box should allow the user and the service provider to choose the functions.
The box may deliver some information about the way services are implemented. Attestation ?
the box should be privacy respectful
the box has to be design with usability in mind

Workshop Next steps : charter and discussion

A draft charter based on workshop discussions is currently under construction here. All exchanges related to this rechartering discussions should happen over the W3C Web Security IG mailing list, subscription is open to anyone here