Re: Notes from WebAuthN / Web Payments discussion

fwd'g because I do not see this in the public-webauthn@ archives...

----- Forwarded message from John Bradley <ve7jtb@ve7jtb.com> -----
    Date: Wed, 9 May 2018 14:37:02 -0300
    From: John Bradley <ve7jtb@ve7jtb.com>
Subject: Re: Notes from WebAuthN / Web Payments discussion
      To: =JeffH Hodges <Jeff.Hodges@kingsmountain.com>
      Cc: W3C Web Authn WG <public-webauthn@w3.org>, Ian Jacobs <ij@w3.org>

OBIE is alighted with the OIDF FAPI profile.  
https://openid.net/wg/fapi/ <https://openid.net/wg/fapi/>

The payment initiation API is at  
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5786479/Payment+Initiation+API+Specification+-+v1.1.0  
<https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5786479/Payment+Initiation+API+Specification+-+v1.1.0>

The Account and transaction detail API is at:
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0  
<https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0>

They are defined for server based OAuth clients capable of mutual TLS.

In principal the TPP could do the authorization request to the ASPSP  
in a iframe if we could deal with this issue.

At the moment because the origins are different it won’t work.

I have been working with OBIE for a couple of years on the API, so am  
interested in finding a way to demo this.

John B.



> On May 9, 2018, at 1:59 PM, =JeffH <Jeff.Hodges@KingsMountain.com> wrote:
>
> > 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
>
>
>
>
>
>

----- End forwarded message -----

Received on Wednesday, 23 May 2018 15:48:18 UTC