Re: Notes from WebAuthN / Web Payments discussion

 > On 3/29/18, 1:06 PM, "Ian Jacobs" <ij@w3.org> wrote:
 >
 > I am recording here a conversation that looks place this week between
 > Chairs of the Web Authentication and Web Payments Working Groups
 > (along with staff). Here some brief notes about the topics we
 > discussed, in seeking to further align our work.


thanks!


 > * PSD2 use cases
 > * Different PSD2 authentication models: redirect, embedded,
 >   disconnected.

Are there any more detailed notes wrt the thoughts shared on the above?


 >   Right now WebAuthn does not support iframe.

Well, that statement is not quite correct since it does not state any of 
the relevant preconditions.

Credman/Webauthn [0] _DOES_ "support iframes" if and only if the "nested 
browsing context" [1] responsible for invoking the webauthn API methods 
[2] is "same-origin with its ancestors" [3].

[0] https://w3c.github.io/webappsec-credential-management +
     https://www.w3.org/TR/webauthn/
[1] https://html.spec.whatwg.org/#nested-browsing-context
[2] https://html.spec.whatwg.org/#responsible-browsing-context
[3] 
<https://w3c.github.io/webappsec-credential-management/#same-origin-with-its-ancestors>


So, yes, presently one can have "framed content" (ie a "responsible 
browsing context") that invokes the webauthn API. However, that 
responsible browsing context must be uniformly "same origin" [4]  with 
all of its parent browsing contexts [5].

[4] https://html.spec.whatwg.org/#same-origin
[5] https://html.spec.whatwg.org/#parent-browsing-context


 > * With Payment request API, it is possible to have user-side software
 >   (mobile apps or web sites) initiate the authentication challenge.

So, is the issue actually something like this:

A "payee", aka "merchant", webapp ("payee origin") may utilize "payment 
handler(s)" [6] associated with "payment method provider(s)" (PMP) [7], 
which may be sourced from an origin (PMP origin) _distinct from the 
payee origin_.

It is within the context of the payment handler(s) that the user will 
need to authenticate with the payment method provider(s), and for UX 
friction-reduction reasons, there is a desire to "frame" [1] the payment 
handler's responsible browsing context [2] rather than perform a 
top-level navigation (ie load an entire new page).

Thus, there is a desire to "relax" credman/webauthn's stipulation of the 
"nested browsing context" [1] responsible for invoking the webauthn API 
methods [2] MUST be "same-origin with its ancestors" [3].

[6] https://w3c.github.io/payment-handler/#dfn-payment-handler
[7] https://www.w3.org/TR/payment-request/#dfn-payment-methods


..yes?


 > * Discussions with various open API efforts (Open Banking UK,
 >   Berlin Group)

 > * FIDO work with EMVCo regarding data requirements (via the extension 
 >   framework)

 > * Talking with OBIE to see if we can get some prototyping experience
 >   with Payment Request API, Payment Handler API, WebAuthN, and
 >   open banking API.

Any specifics/details to share regarding the above discussions?  OBIE?


thanks, HTH,

=JeffH

Received on Wednesday, 9 May 2018 17:05:44 UTC