-
Notifications
You must be signed in to change notification settings - Fork 46
Home
Martin Paljak edited this page Jan 25, 2017
·
59 revisions
- The library provides the
hwcrypto
object with a set of functions, as described in the API doc - There is also a small FAQ and BestPractices document
- The main publishing point is Github
- Releasing is manual, released (generated) files are also version controlled in the same repository (for Bower to work from the same repo)
- Released files are published in the tagged commit and by Travis in the Github release
- Versioning follows semantic versioning
- Release tags are signed
Relates to WebCryptoAPI and WebCrypto.Next but is meant for use with existing credentials and existing browsers and due to the nature of centrally issued credentials, ignoring SOP (Same Origin Policy). Only use of pre-issued credentials, no provisioning like with <keygen>. The abstraction level exposed to application developer is WebCrytoAPI level, not APDU level.
The purpose is to demonstrate the feasibility of a single unified API via different "browser-penetration" components.
- Enrich API with WebIDL
- Make sure https://www.w3.org/2001/tag/doc/promises-guide is followed
- Investigate https://www.w3.org/TR/webcrypto-key-discovery/
- communicate to http://html5apps-project.eu/standards-coordination/
- integrate localhost services, like
- SCS (Specification PDF) from Finland
- German TR-03124 ?
- Other plugins
- Backends-SignWiseAPI (application/x-signwiseplugin and Chrome extension)
- Some "native" code needs to be present on the host platform for talking to the hardware, be it a browser plugin or local web service or browser itself or something else. The implementation details are left to component developers but generic implementation suggestions are given and the adapter framework described. The purpose of the API is to provide for "portable web code".
- Essentially all the relevant on-host components have a "NAT-traversal" nature, meaning that they enable to connect endpoints (web applications and pre-issued keys on a smart card) which browser vendors would not like to allow.
- The de facto standard for extending browser capabilities has been NPAPI which is showing its age and is being actively abandoned by browser vendors (together with other relicts like Java applets).
- http://polycrypt.net/
- http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world
- http://www.chromium.org/developers/npapi-deprecation
- proposal for WebCrypto from Microsoft - https://www.w3.org/2012/webcrypto/wiki/images/d/dd/CertAndKey_Management_Requirements_for_WebCrypto_microsoft.pdf
- another sensible proposal for signatures on the web - http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html
- OASIS DSS - http://docs.oasis-open.org/dss-x/localsig/v1.0/csprd02/localsig-v1.0-csprd02.html
- 1.7.3.1 Introduction of a User Agent unfortunately states that: This profile does not specify how the User Agent obtains the digital signature value: it is left to the implementers.
- What it is all about - connecting to native in a better way than NPAPI: https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf