<jfontana> Ian, I need the WebEx URL
IJ: Which deliverables would be useful?
Nicolas: +1 to education materials.
Lauren: +1
John: +1 to use cases
Jonathan: +1 to use cases documentation
<jeffh> +1 to use cases
<kenrb> +1 from me also
IJ: Any templates people like for use case documentation?
IJ: Suggest consumer journey.
Jonathan: +1 to consumer journeys for enrollment, then accessing credentials, then transaction
IJ: We started with the "from an iframe" use case last week.
Jonathan: ... I am a consumer, I
am on a merchant site, I want to register authenticator. How
can I be sure I can register my authenticator?
... what does the merchant need to do in advance?
... for Payment, I need to access my credentials but also want
to authenticate to my bank during the transaction.
USE case: Share authentication results so bank is happy
IJ: To whom did I first authenticate to?
Jonathan: Generically, I could
auth to a merchant, to the owner of a payment method, to a
payment handler.
... we need to look into these different flows.
... as the user I don't want to have to authenticate too
much
... how can I leverage FIDO once and share results.
IJ: What is the WebAuthn description of this?
JeffH: We don't have that at this
time. the term we've been using to label this is
"delegation."
... in the WebAuthn context, it is presently unsolved and
unaddressed in the specs.
... we are discussing ways to possibly address it in the next
rev of the spec.
Jonathan: That would be
interesting to discuss in this group.
... there might be different options, e.g., if credentials are
generated and owned by merchant, or whether owned and generated
by the issuing bank.
IJ: Is it useful to be specific:
first merchant, then issuing bank?
... I ask this because it might relate to trust boundaries
Gerhard: I liked Jonathan's description. We might want to list separate use cases:
a) Merchant wants to leverage issuer credentials.
b) Merchant wants to pass on to issuer its credentials as proof that it's done webauthn.
scribe: I think that both use cases are useful.
Jonathan: +1
JeffH: From the user's perspective, what you are talking about is a single event.
Gerhard: Correct.
Jonathan: I agree both (a) and (b) are interesting. For (b), I think there might be some suboptions:
b.1) Issuer trusts the merchant's authentication (and some high level results are provided)
b.2) Issuer does not necessarily want to trust the merchant, and basically it amounts to data sharing between FIDO servers.
JeffH: When you say "the issuer does not step up" you mean, the issuer does not perform an explicit auth event that interrupts the user's task.
Jonathan: Yes
JeffH: I hear that you don't want to interrupt the user's task. The goal I hear is to not interrupt the user flow, not do a full page navigation, etc.
Jonathan: We need to deep dive into how to give issuer confidence.
JeffH: Threat model is important
here.
... I'm not sure that having the issuer share credentials with
the merchant is workable given the flow that the payment folks
are wishing to work with.
[IJ mentions trust tokens]
JeffH: Trust tokens are imaginary at this time.
Ken: Another flow was proposed by some colleagues at Google - the user agent authenticates to the issuer, but initiated by the merchant.
Gerhard: Some of that is already
done in 3DS. The challenge is that the merchant also wants to
know a little bit about the user.
... the merchant wants to prevent illegal transfer, or to
protect the merchant's assets
... so there are multiple situations where the merchant wants
to provide context to the issuer.
... the issuer gets to make the choice of authenticating the
user.
... it's the second authentication that could result in
abandonment.
... I am thinking more about someone going to the banking site
and installing an authentication payment handler, and the
merchant can pass on some information to the issuer, but the
issuer also gets a sort of pre-delegation for specific auth
events that is passed along with payment info.
... and issuer almost has proof that the issuer was present up
front.
Jonathan: We need to follow both routes.
IJ: Any volunteers?
JeffH: We (Google) are working on
coming up with various approaches to this overall delegation
problem. We will have stuff written down to inject into this
discussion. Not sure when.
... maybe rough by the next call or after the holidays.
JeffH: At a high level we need to
define the use cases from the consumer's perspective,
merchant's perspective, and issuer's perspective. Understand
the requirements. And analyze different solutions in the
context of threat models.
... and how they map to the requirements, such that the use
case is satisfied from those perspectives.
11 December