Intent to Ship: Capability Delegation with Payment Request

[Mustaq Ahmed]

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Specification

https://wicg.github.io/capability-delegation/spec.html

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

Blink component

Blink>Input

TAG review

https://github.com/w3ctag/design-reviews/issues/655

TAG review status

Approved subject to minor changes.

(Work in progress, see https://github.com/WICG/capability-delegation/pull/23).

Risks

Interoperability

Interop risk here like any new API: new use-cases relying on delegation will fail in a browser that hasn't implemented this feature.  In such a browser, the new API (postMessage() call with an additional option) will silently get ignored while preserving the legacy behavior.  More precisely, the postMessage() call will be treated as if it was meant to send the message object only, and the delegated capability will behave in the target Window as if no delegation has taken place.

Compatibility

There is no compat risk because this is a new feature.

External signals

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/565)

WebKit: No signal

Web developers: Positive (https://discourse.wicg.io/t/capability-delegation/4821/3)

Debuggability

Developers can test the delegated API by calling it from the console of postMessage-target Window.  Additionally, on the console of the sender Window, navigator.userActivation.isActive API can be utilized to check the consumption of user activation as a side-effect of delegation.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Work in progress: https://chromium-review.googlesource.com/c/chromium/src/+/3413851

Flag name

--enable-blink-features=CapabilityDelegationPaymentRequest

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1130558

Estimated milestone

M100

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5708770829139968

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/9CeLYndESPE/m/AhEttheMBQAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/UK0lGnKuAAAJ

This intent message was generated by Chrome Platform Status

[Yoav Weiss]

Thanks for pushing this useful feature!

On Tuesday, January 25, 2022 at 10:46:12 PM UTC+1 Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Do I understand correctly that this intent is to only ship the "payment" delegation value and not others? 

Specification

https://wicg.github.io/capability-delegation/spec.html

Given the initial positive signals from Mozilla, might be worthwhile to talk to them about integrating this spec directly into HTML. 

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

Blink component

Blink>Input

TAG review

https://github.com/w3ctag/design-reviews/issues/655

TAG review status

Approved subject to minor changes.

(Work in progress, see https://github.com/WICG/capability-delegation/pull/23).

Risks

Interoperability

Interop risk here like any new API: new use-cases relying on delegation will fail in a browser that hasn't implemented this feature.  In such a browser, the new API (postMessage() call with an additional option) will silently get ignored while preserving the legacy behavior.  More precisely, the postMessage() call will be treated as if it was meant to send the message object only, and the delegated capability will behave in the target Window as if no delegation has taken place.

Is it safe to assume that browsers would not require user activation until this would be in place? Or do they already do that? (In which case, this doesn't change the status quo)

Any results/learnings from the experimentation?

[Mike Taylor]

Hi Mustaq,

On 1/25/22 4:45 PM, Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Specification

https://wicg.github.io/capability-delegation/spec.html

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

Can you expand more on the relinquishing aspect and how regaining the capability happens? I can't find any normative text in https://wicg.github.io/capability-delegation/spec.html that explains how it happens. Do we look for expired timestamps in DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?

(maybe I'm looking in the wrong place!)

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

What happens if the delegation is refused (or fails) by the browser for some reason? As a developer, how do I know that I shouldn't fire off a PaymentRequest that's going to fail? Do we signal anything in the message event, if not, should we?

(From the PaymentRequest side, I guess I can handle the failure if PaymentRequest.show() is rejected.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7vK4UUEzD%3DwJGnAdyTRxgRrmx7AgfoQjCndi91DF2hGA%40mail.gmail.com.

[Mustaq Ahmed]

Thanks Yoav, my answers to your questions are inline below.

Mustaq

On Wed, Jan 26, 2022 at 10:42 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for pushing this useful feature!

On Tuesday, January 25, 2022 at 10:46:12 PM UTC+1 Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Do I understand correctly that this intent is to only ship the "payment" delegation value and not others? 

That's correct: we are shipping only "payment" delegation along with the general framework that makes it possible.

To clarify further, allowing the delegation of any other capability (for example, "fullscreen") using this general framework still requires changes in the relevant spec (i.e. the FullScreen spec in our example here), therefore would need its own  separate spec discussion and intent process.

Specification

https://wicg.github.io/capability-delegation/spec.html

Given the initial positive signals from Mozilla, might be worthwhile to talk to them about integrating this spec directly into HTML. 

Great suggestion, and we have got the same feedback from jyas...@chromium.org too!  We will kick off the discussion soon, possibly right after landing two pending PRs to our HTML monkey-patch (#20 and #23).

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

Blink component

Blink>Input

TAG review

https://github.com/w3ctag/design-reviews/issues/655

TAG review status

Approved subject to minor changes.

(Work in progress, see https://github.com/WICG/capability-delegation/pull/23).

Risks

Interoperability

Interop risk here like any new API: new use-cases relying on delegation will fail in a browser that hasn't implemented this feature.  In such a browser, the new API (postMessage() call with an additional option) will silently get ignored while preserving the legacy behavior.  More precisely, the postMessage() call will be treated as if it was meant to send the message object only, and the delegated capability will behave in the target Window as if no delegation has taken place.

Is it safe to assume that browsers would not require user activation until this would be in place? Or do they already do that? (In which case, this doesn't change the status quo)

Currently postMessages don't require user-activation.  In a browser that does not support delegation, nothing will change.  In a browser that supports it, the user activation requirement kicks in only when the postMessage call has the "delegate: payment" option, so past use-cases (without this additional option) won't change anything.  Does it answer your question?

Unfortunately our main expected origin-trial partner could not participate during the trial, due to delays on their side. However they are working with us to test the feature locally, and believe that it addresses their use-case.

[Mustaq Ahmed]

Hi Mike:

Appreciate your feedback.  My answers are inline.

Mustaq

On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Mustaq,

On 1/25/22 4:45 PM, Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Specification

https://wicg.github.io/capability-delegation/spec.html

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

Can you expand more on the relinquishing aspect and how regaining the capability happens? I can't find any normative text in https://wicg.github.io/capability-delegation/spec.html that explains how it happens. Do we look for expired timestamps in DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?

(maybe I'm looking in the wrong place!)

You got it right: our proposal missed the normative text around the relinquishing, yikes!  I opened this spec issue, we will send out a PR to fix this when we get a chance.  In the meantime here is what we wanted to mean: access to activation-gated APIs is lost from the sender frame through consumption, and the receiver frame checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

What happens if the delegation is refused (or fails) by the browser for some reason? As a developer, how do I know that I shouldn't fire off a PaymentRequest that's going to fail? Do we signal anything in the message event, if not, should we?

(From the PaymentRequest side, I guess I can handle the failure if PaymentRequest.show() is rejected.)

Yes, just trying PaymentRequest.show() works on the receiver side today.  As we get more use-cases around delegation, we can explore signaling on the received message event.  I would suggest starting a new issue to discuss this.

As for error handling on the sender side, we have a few synchronous failure conditions in our postMessage algorithm already, can easily new ones as needed.  However, if you are thinking about an asynchronous failure (e.g. detected later when the browser decided to run the posted task), it seems like an existing problem with postMessage unless we change it to return a Promise (a separate problem).

[Mike Taylor]

Appreciate the replies, Mustaq.

This seems like a useful addition to the platform, thanks for working on it. LGTM1.

On 1/27/22 12:35 PM, Mustaq Ahmed wrote:

Hi Mike:

Appreciate your feedback.  My answers are inline.

Mustaq

On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Mustaq,

On 1/25/22 4:45 PM, Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/WICG/capability-delegation

Specification

https://wicg.github.io/capability-delegation/spec.html

Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it trusts.

Can you expand more on the relinquishing aspect and how regaining the capability happens? I can't find any normative text in https://wicg.github.io/capability-delegation/spec.html that explains how it happens. Do we look for expired timestamps in DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?

(maybe I'm looking in the wrong place!)

You got it right: our proposal missed the normative text around the relinquishing, yikes!  I opened this spec issue, we will send out a PR to fix this when we get a chance.  In the meantime here is what we wanted to mean: access to activation-gated APIs is lost from the sender frame through consumption, and the receiver frame checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.

If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

What happens if the delegation is refused (or fails) by the browser for some reason? As a developer, how do I know that I shouldn't fire off a PaymentRequest that's going to fail? Do we signal anything in the message event, if not, should we?

(From the PaymentRequest side, I guess I can handle the failure if PaymentRequest.show() is rejected.)

Yes, just trying PaymentRequest.show() works on the receiver side today.  As we get more use-cases around delegation, we can explore signaling on the received message event.  I would suggest starting a new issue to discuss this.

That's fair - I'll file an issue, but I don't consider this to be a blocking concern.

[Yoav Weiss]

LGTM2 % fixing the spec issue.

[Chris Harrelson]

I'm a bit confused about the bit regarding transitioning existing sites. Am I correct that currently Chromium allows the Payment Request API to be used unconditionally in iframes? Do you then intend to send another intent to change the behavior to require activation, after a suitable period and working with sites to migrate?

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV8fECzjRrKi-kUraV80jHokb1FYgjPTmZBxLSfoUxx-w%40mail.gmail.com.

[Stephen Mcgruer]

> Am I correct that currently Chromium allows the Payment Request API to be used unconditionally in iframes? Do you then intend to send another intent to change the behavior to require activation, after a suitable period and working with sites to migrate?

Correct. This is Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation. We had hoped to land them simultaneously (as we have a good relationship with the primary user that does not currently have user-activation when calling show()), however our partner is having trouble with their migration and we may request to push the enforcement (aka the deprecation) back to M102. (TBD still; I expect to make the request on the deprecation thread in the next few days.)

[Chris Harrelson]

On Fri, Jan 28, 2022 at 9:01 AM Stephen Mcgruer <smcg...@chromium.org> wrote:

> Am I correct that currently Chromium allows the Payment Request API to be used unconditionally in iframes? Do you then intend to send another intent to change the behavior to require activation, after a suitable period and working with sites to migrate?

Correct. This is Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation.

LOL. I feel like I might have LGTMed that one.

 

We had hoped to land them simultaneously (as we have a good relationship with the primary user that does not currently have user-activation when calling show()), however our partner is having trouble with their migration and we may request to push the enforcement (aka the deprecation) back to M102. (TBD still; I expect to make the request on the deprecation thread in the next few days.)

SGTM!

LGTM3 for this intent (shipping the API).

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae-L9g0W3KSXyXpuuqAgdym3cFAGLk0uicacOpN%3D%3DE85Q%40mail.gmail.com.

[Mustaq Ahmed]

Looks like we missed asking for the official position of Webkit.  Just sent the request.