Potential bug in access delegation to cross-origin iframe for feature that has default allowlist value "self"?

[shuranhuang]

According to the explainer, when no declared policy presents, a powerful features that has default allowlist value "self" should be allowed in the top-level document and its same-origin frames, but blocked in cross-origin frames, unless allow attribute is used to set this policy and the origin of the document in the frame matches the iframe's src attribute.

However, the following step from the "Define an inherited policy for feature in container at origin" algorithm,

webappsec-permissions-policy/index.bs

Lines 912 to 915 in b363be8

	1. If the result of executing <a abstract-op>Is feature
	enabled in document for origin?</a> on |feature|, |container|'s
	<a>node document</a>, and |origin| is "<code>Disabled</code>",
	return "<code>Disabled</code>".

which steps into "Is feature enabled in document for origin?" algorithm to the following steps

webappsec-permissions-policy/index.bs

Lines 949 to 952 in b363be8

	1. If |feature|'s <a>default allowlist</a> is <code>'self'</code>, and
	|origin| is [=same origin=] with |document|'s origin, return
	"<code>Enabled</code>".
	1. Return "<code>Disabled</code>".

will return "Disabled" for the case mentioned at the beginning, where "Enabled" is expected.

Could this be a bug or I am missing something here?

[clelland]

That does seem like a bug -- that step should be checking to see if the feature can potentially be delegated to the child frame, or if it is blocked by the policy in the containing document. Either 9.8 needs to return Enabled in all default cases, or 9.7 should be calling something different in this step.

This algorithm needs to be rewritten to handle #480 as well, so I'll see if I can come up with text that fits that and matches the intended behavior for default-self inheritance.

[shuranhuang]

Thanks for confirming! I think this issue was first introduced in #501. The fix should be easy.