Jonathan: When the user grants
permission to a merchant to access the issuer credentials
(previously minted),
... the Google proposal last time was to have a binding at
minting time.
... the question I had was: is it necessary to have credential
bound to both at minting time, or could it be possible for a
merchant to leverage previously minted issuing bank
credentials?
Ken: My understanding is that the
proposal that's out there has a specific constraint - does not
want the client to have to connect to the bank. This may not be
a constraint we want in all cases.
... it's mostly for apps on phones I believe
... having to connect to the bank apparently causes some rate
of drop-off
... perhaps we don't need the same on the web and we could
relax the constraint.
Tony: Or perhaps the restriction
could be relaxed to a recommendation.
... At last week's FTF we decided to prohibit creation of
credentials in a cross-origin iframe.
... so issuing bank will not be able to create credentials from
within a cross-origin iframe.
Ken: But they can call webauthn at transaction time (to verify)
btidor: Will requesting an assertion be allowed from a cross-origin origin?
Ken: Yes, with the right feature policy on the iframe. So if there has been previously enrolled credential, you can get an assertion to verify it.
IJ: Is the expectation then that there's a redirect to the bank for first party credential creation?
Ken: That's probably the most likely way to deal with that situation.
Tony: That was the suggested workaround.
Jonathan: What is the impact on the proposal we saw two weeks ago?
Ken: I don't think that proposal
envisioned a cross-origin iframe scenario.
... The use case is you have an app on your phone...you contact
the issuer to issue a credential.
... on the web I am hearing you'd have to redirect.
IJ: Could you do a binding at transaction time?
btidor: It sounds like there's one use case that works:
- Merchant redirects to issuing bank
- The bank either onboards the user or collects assertion them
- Redirects back to merchant and forwards the assertion
btidor: What in that flow are we trying to change?
Jonathan: I'm interested in the flow where the user can visit multiple merchants and the issuer can reuse previous credentials; merchant B doesn't have to do anything beyond including the code from the issuing bank.
btidor: The proposal from 2 weeks
ago is to create credentials that two parties can make use
of.
... the question is whether there's a way to allow that access
in a meaningful way on the get_assertion side
Jonathan: My view is that today we have 2 possibilities that work with WebAuthn:
a) Merchant has no FIDO server. They redirect to the issuer; the issuer auth's the consumer. Consumer authenticates to the bank.
b) Merchant has delegation from issuer; the merchant creates its own FIDO credentials; Merchant authenticates the user and then lets the issuer know (e.g., some form of signal with some data )
Jonathan: I heard 2 weeks ago a sort of hybrid option:
c) Issuer credential is bound to one merchant. The merchant can access the credential.
scribe: and the issuer can verify it as well
Ken: The change to WebAuthn allows the issuer to issuer a credential to the merchant.
btidor: For non-payment handler use cases, there's no centralized party. And we want to support that use case....merchants coordinate with issuers
JeffH: If the merchant creates credentials for payment handlers, that will facilitate scaling.
btidor: I think it's still worth considering, especially if merchants want to verify assertions, how to manage that trust
Ken: On the question of whether we can have a credential created by the issuer and reusable....if you have iframes or redirects that's possible, but we don't have any proposal to square the proposal with the security requirements of Web Authentication.
18 March