Previous discussion on identity
IJ: We broached topics of
identity
... what are the identity requirements in the SRC payment
method?
Jonathan: Who does the
identification and how to you retrieve that information? How
can that be used as input to SRC protocols to retrieve
data?
... what are the different options for being identified to the
payment handler?
... e.g., one option is "you are logged into the browser; how
can the payment handler leverage browser as identity provider?
Or can web authentication be used to retrieve this
identity?"
... another question is whether they can get the identity
formatted in a way that is useful for SRC
tomasz: I think of three use cases for providing identity to SRC system:
1) The browser
2) Payment handler leverages identity verification mechanism of SRC system. (That's part of SRC)
3) Merchant
scribe: merchant has relationship with user and could provide hint
IJ: What about payment handler itself?
tomasz: It's true, the payment handler could also provide attestation of identity verification
Jalpesh: Is the identity discussion orthogonal to SRC as a payment method?
"This specification describes an imperative API enabling a website to request a user’s credentials from a user agent, and to help the user agent correctly store user credentials for future use."
IJ: So maybe there is general approach to this, but also SRC-specific things (what SRC expects as input)
https://caniuse.com/#feat=credential-management
https://platform-status.mozilla.org/#credential-management
<stpeter> see also https://github.com/mozilla/standards-positions/issues/172
Jalpesh: Should we try to solve identity as part of this or delegate top payment handler?
IJ: What about merchant provided identity?
Jalpesh: Is that one necessary
for initial spec?
... is it specific to SRC or beyond SRC?
jonathan: It may be related to SRC. It's about how to facilitate the use of SRC ID to get the cards. Are there options to facilitate the collection?
Jalpesh: Which element specifically are you referring to?
tomasz: I think we are talking
here about the consumer identity.
... in terms of the SRC system 1.0 that's "email address"
... but if there is some other identifier, then there is no
authentication of the consumer, meaning the SRC system will not
return the list of cards
... for selection
... what were are talking about here is more having the ability
to authenticate the consumer so that the SRC system can trust
the Attestation of the authentication and then trust the
retrieval of the cards
<Zakim> AdrianHB, you wanted to suggest that any PH will ned to authenticate a user and that always starts with identification
AdrianHB: I think I am agreeing
with Jalpesh's comment that there's a generic requirement
here.
... the assumption with payment handlers was that there would
be a user session and it would be like any other user
session
... sounds like there are multiple options such as "logging in"
or "providing a hint from the merchant"
... e.g., the merchant could provide the identity as known to
the merchant (e.g., email), but the payment handler might need
to authenticate the user before proceeding
Jonathan: SRC systems expect the id in a specific format.
Jalpesh: Payment handler ->
SRC system is based on the EMV standards and the payment
handler will do the right thing (provide format that's
required)
... I think we should decouple (1) how they get identity and
(2) how they present to SRC system
Jonathan: Identity is an email address. The question is: if the payment handler has the connection to the SRC system, can the payment handler leverage the fact that the user is logged into the browser?
AdrianHB: What does that mean to
log into the browser?
... email address is a hint, but the user still needs to
authenticate (to the SRC system)
... I am hearing SRC supports attestation
Jalpesh: I think once the SRC
gets the identity, it's up to the SRC system and their
assurance logic to verify the identity
... if input is email, output could be a step up
<AdrianHB> The PR API already prompts for email so if the user provides this it COULD be passed to payment handler to be used as the identifier
<AdrianHB> This is not done today
Jonathan: We are talking here
about providing access to the list of cards.
... you could say that the SRC does something like an OTP
... I was wondering whether we could leverage fact that user is
logged into the browser.
... to avoid multiple logins
<AdrianHB> "leverage fact that user is logged into X" is what I refer to as attestation (i.e. X attests that this user is identified as Y)
<AdrianHB> IJ: What is the SRC system prepared to accept as an attestation?
IJ: What else does SRC Spec support beyond "the identifier"
tomasz: There is a federated ID
token in the spec (the attestation)
... it already includes the identifier of the consumer
... who owns the SRC profile
IJ: What systems today produce the federated ID token?
Jalpesh: The SRC systems generate
it
... if that would be extended, it would be the payment handlers
that provide it
... and they, in turn, might be able to delegate to any entity
upstream to them
Jonathan: That's the point
tomasz: Similarly, the merchant
session might be a source of the token
... so payment handler could use a merchant-provided token
IJ: That argues for an optional
parameter from the merchant (the token) that could be evaluated
by the payment handler
... how does web site get info about being logged in?
peter: This is done with OAuth
<AdrianHB> +1
peter: You can set up an account associated with the origin that distributes the browser (e.g., Firefox account, Google account)
tomasz: Is there any API to access this information (e.g., I'm logged into google)
AdrianHB: That's what the
credential management API does
... it helps sites leverage existing federated
credentials
... I wanted also to make the point that, if this flow involves
a payment request getting passed into a payment handler,
currently as implemented today, that's a browser window
... and if the origin of that payment handler is bobwallet.com,
if the user was logged into bobwallet.com already, then that
session will already exist
... so there's a cascade of things:
- Payment handler may have an active session with the user,
- If not, it might have info about who the user is but use some other mechanism (e.g., credential API) to confirm the user is "who the payment handler things the user is"
scribe: there's no attestation to say "I'm certain" but there can be hints from merchant, browser
IJ: Is it more likely merchants could provide these tokens than browsers?
<Zakim> AdrianHB, you wanted to talk about PH capabilities and to suggest this is at odds with current discussions around privacy and the interactions between merchant and PH
IJ: I am hearing that payment handlers gather information (session info, data from merchant, whatever) and converts to the SRC-required format
AdrianHB: This discussion raises
an interesting question about user identity hints (from the
merchant)
... we could go one step further and try to define some
standard ways of doing this; but I think OAUTH would be the
easiest way to standardize this
... and it would be up to each payment method to define what
attestations they "accept"
... there are privacy implications about sharing ,say ,email
and whether, e.g., user gets notified if info is shared
IJ: Should I invite Mike West (the editor) to a call?
<scribe> ACTION: Ian to see if Mike West can join a task force call to talk about credential management
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
<scribe> ACTION: Jonathan to follow up on use of Web Authentication for identity information
<trackbot> Created ACTION-123 - Follow up on use of web authentication for identity information [on Jonathan Grossar - due 2019-07-17].
===
SRC payment method draft
Issues for which we want larger group input.
SRC briefing - card scheme members of the group reflect on SRC v1 and how it fits with the work of WPWG? (volunteers needed!)
On taking up SRC as a Rec-track deliverable
Web Payment Security Interest Group preview (Ian)
====
Jonathan: I think we should also
continue conversations on 3DS that we initiated some time
ago
... how browser functionality could make it easier for merchant
or payment handler to invoke 3DS
(IJ: See also 8 August Web Payment Security IG discussion on risk assessment and privacy)
https://www.w3.org/2018/Talks/ij_tpac_auth/#start
IDFA
AAID (Google)
IJ: What are the requirements for
this?
... how different from cookies?
Brian: It probably comes down to being able to say "This is the same browser"
<AdrianHB> FYI: https://discourse.wicg.io/t/proposal-a-non-modifiable-unique-id-for-the-client-device/2812
Brian: can state be pulled from cookie to say same user/browser
https://tools.ietf.org/html/draft-mandyam-eat-00
The Entity Attestation Token (EAT)
AdrianHB: See above proposal from
media industry for unique client identifier
... long discussion thread there
peter: Various browsers are doing things to get these things under control ;might be better in the long run (as Rouslan is typing) is more of an API than relying on cookies
<AdrianHB> Note that one valuable trait of a device id, even if it can be changed anytime by the user, would be if it is provably hard to guess (i.e. fake)
IJ: For me this comes down to what are the requirements for 3DS?
Brian: API could also provide an id. And privacy could include resettability.
IJ: What would prevent people from doing what they already do AND this new thing?
Brian: Fraud prevention v. advertising..how do we find that line
24 July
(More on TPAC agenda planning for that date)