SecurityError vs NotAllowedError for "allowed to use" check

[zcorpan]

If this's relevant global object's associated Document is not allowed to use the "payment" permission, then throw a "SecurityError" DOMException.

Should this not throw an "NotAllowedError" exception instead?

[stephenmcgruer]

Possibly! Is there prior art that permission policy checks should result in NotAllowedError ?

[marcoscaceres]

@stephenmcgruer, re: whether there's precedent, yes:

I checked what WebKit throws for each permissions policy failure:

Error	API	Feature
NotAllowedError	Screen Wake Lock	screen-wake-lock
NotAllowedError	WebAuthn	publickey-credentials-get
NotAllowedError	Digital Credentials	digital-credentials-get
NotAllowedError	Web Share	web-share
NotAllowedError	getUserMedia	camera / microphone / display-capture
SecurityError	Payment Request	payment
SecurityError	Gamepad	gamepad
SecurityError	WebXR	xr-spatial-tracking
TypeError	Fullscreen	fullscreen
NetworkError	Sync XHR	sync-xhr

NotAllowedError is the majority (5 vs 3 for SecurityError).

The Permissions Policy spec is silent on this, but I filed an open issue asking for guidance: w3c/webappsec-permissions-policy#396.

All three engines currently throw SecurityError here, so changing it is a web-compat question. I'd leave it unless there's appetite from implementers to align... but happy to update the spec if there is.

We should fix Permissions Policy though, @zcorpan. WDYT?