Integrate with Feature Policy and possibly Permissions and define appropriate identifier value for WebAuthn #911
Comments
|
Completely agreed. In assumption that we'll do this, I've opened an implementation issue at Firefox. |
|
This makes sense to me to do. |
|
I think it's time for a PR implementing this... |
|
It's on the to-do list... |
equalsJeffH
changed the title
|
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. |
|
@equalsJeffH My view is that this a new feature that will require breaking changes that are best done in Level 2 |
|
agreed. |
|
This about an RP opening an iframe for another party (e.g. a 3DS payment provider) to explicitly allow using the RP's credential. |
|
the Webauthn working group is considering implementing this using Permissions, although we would welcome guidance from webappsec on this point. |
jcjones
changed the title
|
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. |
|
@equalsJeffH @agl to open PR |
|
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 |
|
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 |
equalsJeffH
changed the title
this improves #911 -- we'll look in to adding indication of framedness in WD-02 * feature-policy initial inclusion * add 'allowed to use' to create/get algs * grovel around fixing cross-ref linkage breakages * polish linkages * remove 'allowed to use', it belongs in credman * polish Feature Policy integration * oops, promises must return errors, not throw them * add Note to isUVPAA() wrt rejecting if not 'allowed to use'
|
It might be useful knowing that the use of
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: |
|
As an update, Mozilla agreed with using the |
|
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. |
|
closing given that we merged #1276 just now.... |
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
webauthnfeature-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?
The text was updated successfully, but these errors were encountered: