Re: CfC to remove Peripherals APIs from the Devices and Sensors WG Charter

On 2026-08-25 15:49, Will Morgan wrote:
> As an interested user of these APIs, we'd prefer to retain them as 
> tentative deliverables, provided the paper's concerns are addressed in 
> a threat model review. Or is the implication that they will move to 
> the Peripheral APIs workstream, and undergo the review there?
>
> The paper itself suggests the findings are fixable within the APIs, so 
> the specifications can be amended. Some of my own suggestions would be 
> to add more granularity, possibly by gating them behind some of the 
> new permissions proposals, time-limiting the grants, adopting 
> mitigations similar to COEP + COOP used for SharedWorker, or 
> specifying an opt-in CSP policy, might help?
>
> What about dropping the deliverables, but if Peripherals is not 
> established within 6 months, re-adopting them as tentative and 
> addressing the issues here?

That's also doable. Just to make sure everyone is on the same page 
process-wise, dropping them then "re-adopting them as tentative" in 6 
months would mean proposing a new charter for the group at that time. 
That's explicit in the current (and currently proposed) Charter through:
"If additional in-scope Recommendation-track deliverables need to be 
added to the Charter before the Charter expires, the Working Group will 
prepare an updated Charter that differs only in deliverables."

François.


>
> On Mon, 24 Aug 2026 at 21:30, Mike Jackson (EDGE) 
> <mjackson@microsoft.com <mailto:mjackson@microsoft..com>> wrote:
>
>     Microsoft believes these APIs address important use cases and fit
>     within the scope of the Devices and Sensors Working Group. We
>     would prefer that the group retain them as tentative deliverables
>     and continue developing them, while taking the documented security
>     concerns including firmware reprogramming, device abuse,
>     persistent grants, and fingerprinting seriously.
>     The Formal Objection's alternative conditions largely describe
>     work that will be necessary regardless of venue: documenting known
>     exploit classes, defining normative mitigations where feasible,
>     obtaining appropriate security and privacy review, and clearly
>     identifying risks that remain with user agents or device vendors.
>     Adoption as a tentative deliverable would provide a venue for that
>     work and would not endorse the current designs or guarantee
>     advancement to Recommendation.
>     Despite our concerns, we will not block consensus to remove these
>     deliverables from the DAS charter. Given the proposed WHATWG
>     Peripheral APIs workstream
>     (https://github.com/whatwg/sg/pull/264), removal would primarily
>     change the venue rather than end the work. We encourage continued
>     iteration on these APIs and expect the concerns raised by the
>     Formal Objection to be addressed before they advance in either venue.
>
>     -Michael
>     Sent from Outlook <http://aka.ms/weboutlook>
>
>
>
> -- 
> Will Morgan
> Head of Innovation, Physical Access
> iProov
>
> This email (and any attachment) is confidential.  If you are not the 
> intended recipient, kindly forward the email to security@iproov.com 
> <mailto:security@iproov.com> and delete it from your systems; you must 
> not use the email or any of its (or any attachments) content for any 
> purpose, or reproduce, store, or disclose it or any such content to 
> anyone.  Views expressed may not be those of the Company, but be the 
> personal views of the email’s author.   No right or licence is to be 
> deemed granted, or obligation deemed accepted, by the Company until a 
> written agreement is negotiated and executed between the relevant 
> parties.  Agreements may only be concluded by officers authorised to 
> execute contracts on behalf of the Company.
>
> iProov Limited (Registration No.07866563), incorporated in England and 
> Wales.  Registered Office: 14 Bank Chambers, 25 Jermyn Street, London, 
> SW1Y 6HR.
>
> References to Company mean iProov Limited and (where relevant) its 
> subsidiaries iProov, Inc. (a Delaware corporation) and iProov PTE Ltd 
> (a Singapore company).
>