RE : Requirements on an SE API

You are shifting discussion from "defining SE api"  to "defining SE", which is obviously not the objective of w3c.
--
Olivier



-------- Message d'origine --------
De : Anders Rundgren <anders.rundgren@telia.com>
Date :
A : sysapps <public-sysapps@w3.org>
Objet : Requirements on an SE API


If rubber-stamping or dropping the work-item aren't viable alternatives maybe a requirement specification could be useful?

1. Scope: The primary purpose of the SE API is supporting provisioning and management of cryptographic keys for authentication, signing etc. to remote services.
The provisioned keys MUST be available for existing applications like WebCrypto and TLS client-certificate authentication.

2. Limitation: In order to promote interoperability the SE API MUST support a specific set of objects and methods rather than arbitrary "frameworks".

3. Openness: The SE API (and thus the underlying SE), MUST NOT presume any relationship between issuers and SE vendors; anybody MUST be able to use the SE as is.

4. Trust model: Since #3 effectively disables issuer=>SE authentication, it is the user that grants issuers access.  Due to #2 the UA can verify the correctness and applicability of commands to be sent to the SE and thus protect the SE from DoS attacks (=filling it with nonsense data) by malicious issuers.  Issuers' trust in the SE is assured through SE-based device-attestations.

This is essentially the antithesis of currently shipping devices featuring embedded SEs.

The reason for the proposed a U-turn, is that the concept of using SIM-cards for various add-on services like banking has failed on the market although it has existed for at least 15 years.  The current incarnation of the Google Wallet is more recent example of this (non-working) idea.

Anders