This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Raised during the W3C TAG review ( https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41521737 ) and expanded upon subsequently. To aid implementors, a clear description of the operating environment (non-normatively) should be provided. In particular, the concept of a "cryptographic provider/module" and a "provider key handle" should be established, in an abstract sense, so that the limitations and design decisions of the API are clearer. This makes it clear that the Key object is a holder for a "provider key handle", which is a platform-specific object that cannot be represented (normatively) within ES. This is akin to the File API's specification of the internal snapshot state representing an operating system file. This will also provide context for terminology like "perform the underlying operation with the key represented by key".
Ryan, Mark, are you able to provide some editorial suggestion *this week* so that we can close that bug ? Or we will have to close the bug raised by the TAG as WONTFIX - euheum, not good :) Virginie
It seems cryptographic provider has been defined adequately in the spec now: "an abstraction for a specific implementation of a set of algorithms. The operating system or library may come with a default provider, and users are frequently allowed to add additional providers, reconfigure the set of enabled algorithms, or otherwise customize how cryptographic services are provided. While it is assumed that most user agents will be interacting with a cryptographic provider that is implemented purely in software, it is not required by this specification. As a result, the capabilities of some implementations may be limited by the capabilities of the underlying hardware, and, depending on how the user has configured the underlying cryptographic library, this may be entirely opaque to the User Agent."