Integrate with Feature Policy and possibly Permissions and define appropriate identifier value for WebAuthn

[equalsJeffH]

update 3-Apr-2019: wrt @agl's comment:
Yes wrt Permissions, tho this general "how to safely orchestrate cross-origin + iframe webauthn usage" topic, along with the potentially enabling technologies (feature policy, permissions, digital asset links, et al), is complex (cf. the original post). I expect that we have more investigation to do here wrt feature policy vs permissions and such before deciding on a particular solution approach.

update 24-Jul-2018: Recent further investigation reveals that this is actually a technical issue if one wishes to actually integrate with Feature Policy, i.e., defining a feature-identifier value is only one aspect. One also posibly needs to update their algorithms to check feature policy and act accordingly. See the payment-handler integration with feature-policy, see also how picture-in-picture integrates feature policy evaluation in its algorithm, and defines its feature name.

---

original post (OP):

(framed?) webapps may request permission to use the PaymentRequest interface via the feature-policy feature-identifier value payment.

Given the desire for webauthn to be usable in a webpayment context and its being a "powerful feature", ought we mint a webauthn feature-identifier value ?

this may depend to some degree upon resolution of w3c/permissions#177

see also w3c/webappsec-permissions-policy#168, w3c/webappsec-permissions-policy#166, w3c/webappsec-permissions-policy#75

see also discussion here: Relationship of Permissions, Feature Policy, Origin Policy?

[jcjones]

Completely agreed. In assumption that we'll do this, I've opened an implementation issue at Firefox.

[selfissued]

This makes sense to me to do.

[selfissued]

I think it's time for a PR implementing this...

[equalsJeffH]

It's on the to-do list...

[equalsJeffH]

marking this issue as technical:

Recent further investigation reveals that this is actually a technical issue if one wishes to actually integrate with Feature Policy, i.e., defining a feature-identifier value is only one aspect. One also posibly needs to update their algorithms to check feature policy and act accordingly. See the payment-handler integration with feature-policy, see also how picture-in-picture integrates feature policy evaluation in its algorithm, and defines its feature name.

[nadalin]

@equalsJeffH My view is that this a new feature that will require breaking changes that are best done in Level 2

[equalsJeffH]

agreed.

[rlin1]

This about an RP opening an iframe for another party (e.g. a 3DS payment provider) to explicitly allow using the RP's credential.

[agl]

the Webauthn working group is considering implementing this using Permissions, although we would welcome guidance from webappsec on this point.

[equalsJeffH]

wrt @agl's comment above

Yes wrt Permissions, tho this general "how to safely orchestrate cross-origin + iframe webauthn usage" topic, along with the potentially enabling technologies (feature policy, permissions, digital asset links, et al), is complex (cf. the original post). I expect that we have more investigation to do here wrt feature policy vs permissions and such before deciding on a particular solution approach.

[nadalin]

@equalsJeffH @agl to open PR

[equalsJeffH]

on 24-Apr-2019 call: we are going to just alloc the feat policy string, and provide some nominal guidance say in a Note: and see what the feedback is, and target L2-WD-01

[equalsJeffH]

Further investigation reveals that we apparently need to incorporate FP into CredMan proper.

See WebAuthn PR #1214 (now merged into WebAuthn L2 FPWD which was published in 4-Jun-2019)

see Feature Policy PR w3c/webappsec-permissions-policy#306 and issue w3c/webappsec-permissions-policy#168

see also CredMan issues w3c/webappsec-credential-management#135 & w3c/webappsec-credential-management#136, and PR w3c/webappsec-credential-management#138

[cyberphone]

It might be useful knowing that the use of WebAuthn in payments seems unlikely to happen in a big way since the payment industry in general have invested in native mode payment applications running in mobile operating systems like Android and iOS. The logic behind this is quite simple:

• It is doable with existing technology
• Such systems may also support non-Web scenarios like paying at a POS terminal or sending money to a friend (P2P payment)

These applications do usually not build on the OAuth paradigm, they rather represent variants of the age-old EMV scheme where static, account specific keys are used to sign locally presented/rendered payment requests. This is (at least) as secure as authenticating to server and getting a token back, but the main motive behind this concept actually lies in an improved UX. Apple Pay also builds on this concept.

The W3C Payment WG have not considered the impact of native mode payment applications on their activities and work items, including how the aforementioned mobile payments systems could be used together with "desktop" Web applications, an area suffering from major interoperability and scalability issues. To address this standards deficit, an alliance of mobile payment service providers was recently created: https://empsa.org/

A related topic can be found here:
https://lists.w3.org/Archives/Public/public-payments-wg/2019Sep/0000.html

[jcjones]

As an update, Mozilla agreed with using the allow="webauthn" syntax (where webauthn is whatever the decision is): https://groups.google.com/a/chromium.org/d/msg/blink-dev/NB6BMfcyKok/10QtWW0oDAAJ

[equalsJeffH]

thanks @jcjones :)

I assert that PR #1276 will complete the resolution of this particular issue—i.e. via integration with Feature Policy. If anybody has some perceived need to also integrate WebAuthn with the Web Platform's "permissions" functionality (which is distinct from Feature Policy, and is about displaying notifications to the user soliciting user "permission" to allow the webapp to access web platform functionality), they should submit a new issue.

[equalsJeffH]

closing given that we merged #1276 just now....