Meeting minutes
See also: 27 March minutes, 29 March minutes
GNAP and SPC for payments
Justin: Hi all. I'll introduce GNAP today
Justin: Gnap (pronounced Guh-nap)
[Ian does not plan to scribe details of presentation]
Justin: This is not "OAuth 3"
Justin: Fundamentally, GNAP is a protocol (rather than a framework as was the case with OAuth)
… protocol for negotiating access; methods for interacting with humans; validating and verifying client software; methods for binding keys to message requests; data model for what's being requested
Justin: GNAP is a delegation protocol. Client gets a right of access from an authorization server in order to get something from a resource server. This is done after a permission grant by the resource owner (who may or may not be the end user)
… one thing that's new in GNAP compared to other protocols is clarity on grant request lifecycle
Justin: GNAP allows conversation -- negotiation about what is wanted; conversations can be augmented over time; users can get involved when needed
… of import to today's discussion is indicating different ways to authenticate the user
… GNAP features a lot of expressivity in what can be protected, right out of the box
… in GNAP there is no assumption that client is pre-registered
… the client always introduces itself; sometimes the authorization server knows it (pre-registration) but sometimes it does not; it's a policy decision
… implications: (1) no need for complex pre-confirmation...but can be used when makes sense (2) all requests start the same way (3) systems can adapt at run time based on what's possible and what's needed
… GNAP does not assume end user and resource owner are the same people.
[On interacting with users]
Justin: There's a negotiation "what I can do" and subsetting by the authorization server "what works in this context"
… the client doesn't necessarily need to know the server's full list of capabilities at the start of negotiation
… this allows for dynamic negotiation when needed
Justin: The authorization server (AS) makes decision based on context. This differs from OAuth where the AS holds the user account and that information is used to mint the token. In GNAP, this is more of a *process*
Justin: Client instances in GNAP are identified by keys; this is enabled by key-proofing mechanisms
… you can add to an HTTP message to prove you are the client holding a key
[Types of Data]
Justin: Client can ask for information about user, can provide information about the user, can ask about APIs the client wants to access, etc.
… sometimes the client knows more about the user than the AS does (initially).
… we don't assume the client is "smarter than the AS," but we allow for scenarios where the client has knowledge about the user.
Justin: There are ways in GNAP to use "shortcuts" (for frequent operations)
… you can also request multiple access tokens to do different things at the same time (instead of sequentially getting a set of tokens)
clinton: Is there a concept in GNAP of distributed access server?
justin: You can deploy your AS in a distributed fashion; does not need to be a single web server
… but there is a single URL and HTTP request
NickTR: When you get multiple tokens for a single request...can those multiple tokens have different lifecycles?
Justin: Yes
… access tokens all have independent lifetimes, and can be managed independently
NickTR: The reason I ask ... you touched on the topic of recurring transactions.
… was wondering whether you could get a single token for an initial amount, and then a longer-lived token for a smaller repeating amount (e.g., 100 up front; 10 monthly thereafter)
Justin: Yes, absolutely
Justin: You can also get a token for an initial amount; and that can stick around for a long time. You could develop your system so that when you need to do the smaller payment, you could poke the AS again and say "hey, remember me, I need another small token to do this amount"....the AS can say "ok, that's within limits, here's a short-lived token"
<AdrianHB_> Token lifetime can be short but the grant lifetime is long. i.e. Grant = mandate and token is access token for payment under mandate
NickTR: Is persistence managed between client and AS?
Justin: yes. There's a whole API for managing grants
… you can make create requests to the API and then update requests
JeanLuc: I used to work with DPOP; does GNAP mean we no longer need to use additional layers?
Justin: Yes, that's correct.
<AdrianHB_> Challenge with payments is resource related limits. I.e. AS should apply policy around what is "allowed" and RS should also apply policy when a request comes in to check that resource usage under the grant hasn't exceeded limits
Justin: ...the signing methods in GNAP are directly inspired by the DPOP work
… the TLS binding in GNAP is lifted from another RFC
JeanLuc: Does GNAP allow use of DIDs?
Justin: There can be; we don't talk about it directly.
… you can use them as identification for users and client software and key addressing
<AdrianHB_> E.g. A Grant allows making $10/month in payments. AS can issue a token for a single payment less than $10 but RS needs to check how many payments have already been made under the grant for the current month.
Justin: The other way to use DIDs (IMO more interesting) relates to the notion of the AS as factory
… the user shows up at an authorization server and pushes a button to turn the light on; in GNAP the notion of "what is an interaction" is abstracted up a layer
… you could very easily say as a client: "I have a verifiable claims wallet that I can point you at. If you have a way to talk to this, you can figure out who the user is."
<nicktr> @AdrianHB_ what's the user experience if the payment exceeds the grant?
<AdrianHB_> @nicktr that is outside the scope. The client should get the token from the AS and then attempt the payment before it tells the user it is able to make the payment
Justin: so you could connect a wallet and AS through whatever fabric the wallet is running on.
JeanLuc: So I am hearing DIDs can be used (1) when client sends info to the AS and (2) when there's a third party (e.g., wallet) on which the AS can rely go get information.
Justin: Yes
Justin: There is one other case where the AS can issue verifiable credentials to the client software; but that more or less amounts to API access
… the AS CAN store information in that format, but isn't required to
… what's important is the pattern of sending user to the AS, have them push a button, and send them back
JeanLuc: So AS could be used as ID provider for third parties
Justin: Yes
<nicktr> @AdrianHB_ so the client here might be a payment handler?
<AdrianHB_> @nicktr - I think it could be
Steve_C: Regarding Nick's scenario of tokens: can one token be issued contingent on success of issuing another token?
Justin: Can you say more?
Steve_C: If token issuance for $100 token, for example AS does not issue smaller value token?
Justin: You're supposed to treat the multiple parts of a token request as "independent" in the sense that they represent different rights of access, etc BUT related in the sense that the same client is asking for these at the same time.
… so they could be contingent on the same authorization
… so an AS can say "no" to all parts of a request
… but for some protocols you may wish to say "no" to one thing but "yes" to other parts
… e.g., client might need to provide more information for one of the tokens, or maybe the client can just live with lesser access
Adrian Hope-Bailie slides on GNAP and SPC
AdrianHB_: Thanks to Justin for the helpful intro; I'll speak about extensions and the use of SPC
… Omer (on this call) and I have put together the IETF draft "GNAP Secure Payment Confirmation Extension"
… the draft explains how to use SPC as an interaction mode; will presented at the IETF meeting (in Japan) on Friday
[Slide on how SPC works with GNAP]
AdrianHB_:
* Client tests if SPC is possible
* Client request a grant to perform a payment from the authorization server
… that request also provides some user identity hints and/or assertions
AdrianHB_,: AS determines SPC is preferred interaction and user has enrolled (SPC) credentials
… AS sends challenge and candidate credentials and requests that the client perform SPC
… a future refinement might be for the client to provide additional data (fingerprint?) to allow AS to send back more specific credentials
… Client then calls SPC
… User authenticates
… Client sends assertion back to the AS
… AS returns a grant, or rejects request, or requests a different interaction
[Prerequisites]
* Is SPC supported? Cf isSecurePaymentConfirmationAvailable; would imply changes to extension appendix
* User hints and attestations
* Device identification
AdrianHB: How do we pass context on client if not a software instance but relies on backend software
… I note that "frictionless flow" is possible here; AS can simply return a token based on context or previous information
… or under the hood there is some level of device detection
… the AS would only use SPC as an authorization method if the user has enrolled credentials
Ian: Any new IETF news on device id protocols (e.g., to have confidence that this is the same device used to make a payment with a given instrument)?
Justin: That topic keeps coming up. Device identification has largely been used so far in the commercial sector (e.g., signed binaries in the app store)
… there has been some discussion on generalizing that type of stuff in mobile and embedded scenarios
… e.g., supply chain (SCITT)
… e.g., to be sure that information about crate location has not been tampered with
… but I've not seen a generic solution yet that would be applicable.
… this is something that we've considered to be important, but we (in GNAP) did not want to invent a solution
… we've left this work to extensions
AdrianHB_: I think that can be done with a FETCH request that contains whatever cookies are available; essentially giving the AS a direct link back to the client context
… GNAP has nice hooks for something like this, but we'd need to define what's going to happen
AdrianHB_: Note that when AS says "no matching credential" we can use GNAP for fallback authorization experiences
… but one thing the client needs to do is to know how to resolve the AS URL
… (in our case we are using payment pointers)
… there might be a variety of ways (e.g., directories to convert strings to URLs)
[AHB talks about GNAP and EMV® Secure Remote Commerce (SRC)]
AHB: There are a lot of topics that 3DS and SRC seek to address and there's overlap with GNAP functionality
[Next steps]
AHB: We'll continue to evolve our extension spec as SPC evolves. One thing we've not looked at in detail is that the grant request should map nicely to the SPC request
… we'd also like to support returning instrument details for SPC invocation
… there is a GNAP implementation in the Rafiki project
AHB: We are building implementations of all this into our Fynbos wallet; will share progress in the next few months
clinton: +1 to analysis of separation of concerns among these various technologies
NickTR: Thank you both for this presentation
PIX and SPC
Gustavo Kok and Victor T.M. Silva slides on PIX
Gustavo: Today we'll talk about PIX, faster payments system in Brazil
… I am head of payments fraud at Netflix; we've been paying close attention to SPC
… we are interested in SPC authentication experience for a variety of payment methods
… one driver for the development of PIX was inflation; people needed faster payments so that money would not lose value during delays
… at the same time there are numerous fraud challenges..."Brazil is not for amateurs"
… Also Brazil has 5 World Cup titles
Victor: +1 to FIFO World Cup titles; Itau is a sponsor ;)
Victor: Itau is largest bank in LatAm and Brazil
… we are the biggest issuer of credit cards to our 70M customers
… I work on risk management (first at Citibank, then ELO, then Itaú). I have no World Cup titles.
Gustavo: I've been working on fraud for many years; also member of the US faster payments council fraud WG. I have no World Cup titles.
<SameerT> one of the best introduction slides I have seen
<Ian> +10!
Gustavo: PIX is new but gaining traction rapidly
… it was first announced only about 5 years ago
… it was built by looking at experience in other places
… they found key stakeholders in the market to ensure success
… lots of public consultations and involving experts
… there was a lot of pressure to get it out quickly.
… officially launched at the end of 2020
… it's been a bumpy road but huge adoption now.
… we are looking now at more business use cases
Gustavo: Goals (1) real-time (2) 24/7/265
… other goals: no cost to end user
… to spur adoption focused on large banks, then small banks joined, then rest of ecosystem joined in
… central bank wanted to increase innovation / competition (in part to reduce costs and prices)
… account numbers are not super sensitive in Brazil (e.g., TAX ID); these keys are used to make landscape easier to use
… there are a variety of initiation mechanisms (e.g., QR codes)
Gustavo: Scheduled payments are also possible.
Clinton: How do TAX IDs work for people who are not Brazil residents?
Gustavo: I don't know the exact answer. I think it's not hard to get a TAX ID (since they want you to pay taxes), but there are also other payment identifiers.
Victor: You can open an account without a TAX ID but it's bank specific
<Zakim> AdrianHB_, you wanted to ask how the identifier mapping is governed
AdrianHB_: A big challenge always with pay-by-proxy systems is how is mapping managed? How do you prevent SIM swap or people claiming identifiers that aren't theirs?
Gustavo: the Brazil Central Bank created a centralized repository with rules
… e.g., bank incurs liability if there is fraud because they are responsible for ID&V
Victor: We have some interacts with phone numbers related to sim cards; in short we have sim swap detection
… the central bank built in a lot of controls to avoid bad usage of credentials
… the companies that are connected to the central bank are regulated; there are controls for accessing APIs (e.g., thresholds for accessing information)
Gustavo: If I have a link to a bank account, I have to authorize with a TAX ID
<AdrianHB_> Liability is a big motivator
Victor: We also have a regulation to apply multi factor authentication for non-payment events like moving credential from one bank to another
Gustavo: Regarding brute force attacks; the threshold for access is designed to limit risk of brute force attacks
<Zakim> nicktr, you wanted to ask about confirmation of payee
NickTR: in open banking UK there is a concept of "confirmation of payee"
… in the push payment, authorized push payment fraud is high
… this is where bad actors convince you to make a payment to a fraudster
… they've introduced a "confirmation of payee" thing
… do you have something like that in PIX?
… and, are you seeing this same kind of fraud (recipients giving out fraudulent credentials)?
Victor: We have this kind of fraud, but do not yet have this kind of security feature
… we are mitigating this problem by not allowing new PISPs to perform transactions
… we are not yet enlarging our open financing environment yet
… and are taking inspiration from UK experience and also CIBA flows
[Diagram of PIX system]
Victor: Central bank holds database of keys
… the "scheme owner" for PIX is the central bank
… only huge financial institutions directly access the central bank.
… there is another class of entities called "indirect partners" who connect to the "direct partners" who connect to the central bank
… we basically copied open finance and instant payments from UK model
… in addition to internal faster payments, the Brazil central bank would like to extend functionality to cross-border transactions (when all partners are ready)
… we are using QR codes today, with lots of P2P transaction
… we'd like to discuss QR codes in e-commerce with this WG
Gustavo: PIX launched in 2021 officially; number of keys is now at about 600M
Gustavo: More than 100M individuals have used PIX at least once
… there are almost 400M accounts
Gustavo: and about 3B transactions monthly
… majority relates to P2P
<Zakim> AdrianHB_, you wanted to ask if senders have any way to verify payee details before sending?
<nicktr> @AdrianHB_ - that's the question I just asked - Victor said not yet
<AdrianHB_> @nicktr - that's not what I heard :( Happy to clarify
<nicktr> @AdrianHB_ ask away!
Gustavo: PIX mostly P2P initially; growing P2B transaction volume
AdrianHB_: I'd like to ask a clarifying question: if I'm a regular bank user like an Itau customer and I want to send a payment to someone and I use their email address...
… is there any way to verify that the email address is the person I expect?
Gustavo: You'll get a confirmation of the name of the person with whom that address is registered, and you'll get a partial of their TAX ID
… risk is social engineering when sharing information
AdrianHB_: The mitigation you have here, presumably, in terms of privacy protection, is that only direct participants can make those queries?
… so not easy for third parties to scrape
Gustavo: There are risks still with fraudsters accessing large amounts of information, but after a few episodes risk was taking much more seriously.
Victor: In practice we monitor "strange behavior" (e.g., enumeration) with controls in place
… in the end you have a repression strategy; the central bank will punish bad behavior
… it's not bullet proof but different layers help add friction
… we've not had any new cases of enumeration in the past year or so
… that is : no new breaches of the central database
[Risk overview of PIX]
Gustavo: One attractive feature of the protocol is availability, as well as real-time settlement
… another risk had to do with lack of knowledge by users, especially newly banked
Victor: On day one of the PIX launch there was fraud; the major problem we see today is social engineering
Victor: We have a database of bad URLs
… lots of SMS phishing
… user follows a link, calls a (fake) bank
… user gives away credentials to fraudster
… 70% of loss today is due to social engineering
<praveenas> This is very interesting information, thanks for sharing!
Victor: Multifactor auth is mandatory to keep fraud down
… all PIX transactions involve multi factor auth
… you have a token on your device;
… biometrics common in Brazil
… but we have attacks on facial recognition
… we chat with the Central Bank on a weekly basis to keep up on fraud attacks and solutions
Victor: the central bank convened the big banks to create this fraud committee
Victor: A bit on context and why we're here today
(1) We have LGPD (similar to GDPR), so we need user consent to collect information
(2) FIDO; Itaú is already using FIDO for some app-focused solutions
(3) Low confidence in the Web channel due to several different types of attacks
Victor: We are implementing FIDO in open finance and other protocols as well
Victor: Web channel in Brazil today is considered "weak"
… we are influencing our business partners to NOT USE WEB for critical or high-risk transactions
… but we have a lot of clients that want to use the Web; we just don't have a solution (YET)
(4) On the corporate side, bank as a service initiatives are surfacing, but weakness of web holding us back
… corporate clients using web; we need to solve the web channel problem
(5) Hardware keys are used today (e.g., Yubikeys) but we'd like to enhance the approach to use platform authenticators (especially for corporate use cases)
(6) We have a good connection with the central bank; we are showing them fraud cases and building with them the security protocols we are using with PIX; so solutions adopted with PIX may migrate to other payment methods
Victor: Questions for group today:
a) Can we use SPC and FIDO2 to enable security for PIX P2M Web transactions in Brazil?
b) Can we use SPC and FIDO2 to enable security for PIX corporate Web/Baas channels transitions in Brazil?
Victor: I am interested in the GNAP+SPC approach, for example.
NickTR: Thank you both for the presentation!!
… it would be great to see some experimentation
<AdrianHB_> Answer: Yes!
smcgruer_[EST]: We've been looking at PIX from Chrome. One thing we heard is that for Web transactions that are happening involve this flow:
a) copy a PIX code from the merchant page
b) Switch to a bank app, paste the code, and proceed
smcgruer_[EST]: there are Android intent Url schemes; is there a reason those aren't used?
Gustavo: is this similar to UPI (in India)?
smcgruer_[EST]: Don't know. But you could have bank say "We handle PIX URLs"
Gustavo: Bank was not as comfortable with that those links (when first considered)
… so they came out with copy-paste PIX
… I'm not sure how the thinking evolved; I know they were talking with platform providers about apps and maintaining a safe list (and cost of doing so)
Victor: Basically the speed of implementation of PIX and complexity of understanding how to use the method in a security way led to this initiative landing in a parking lot
… copy/paste solved the problem and was "easy enough" even if not a great uX
Gustavo: copy/paste approach was familiar to people via Boleta
… there are some ongoing discussions about topics like recurring payments
<clinton> SRC topic.. please
<nicktr> @clinton - absolutely. #1 on the agenda as we bumped you from Monday
Ian: Any obstacles you already know to using SPC with PIX?
Gustavo: Different regions have different views of privacy requirements. Do you foresee a way to support different levels of privacy?
See also: 27 March minutes, 29 March minutes