1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Adopt PAR & RAR as recommended way to convey authorization data

Issue #275 resolved
Torsten Lodderstedt created an issue

Based on what I learned at FData Summit, I would suggest we include PAR & RAR as interoperable way to convey authorization request data from client to AS. Right now, every open banking initiative solves that challenge differently (lodging intent, parameters, …), which is an interop issue. Extending the FAPI Profile scope to include PAR & RAR will make FAPI a complete solution for API authorization.

Comments (24)

  4. Ralph Bragg

    Fully supportive of this, I’d be really keen to get vendor feedback on likelihood of adoption and timescales. It’s one thing to have a standard that addresses the issue but avoiding fragmentation or “alternatives” being invented will depend on industry take up and adoption.

    ‌

  5. Joseph Heenan

    For the record, I support this.

    ‌

    To Ralph’s point; I believe both connect2id and Authlete have live product that supports PAR.

    I think RAR is more of a pattern; it would always require custom processing on the AS and vendors generally already make custom fields available for integrators to process.

  6. Anders Rundgren

    Just for the record, there is another method for accomplishing “PAR-like” functionality which though requires a more advanced technology stack which permits counter-signing and embedding. The following Gas Station payment message shows how it works: https://cyberphone.github.io/doc/saturn/hybrid-payment.html#8

    This particular example holds no less than 5 stacked signatures. What’s the point with this? Well, here are some:

    • Simple bank integration. The transaction backend only needs to support “Reserve Funds” and return an identifier (in the sample #0100345136) to that as well as a matching “Resolve” using that identifier. The API decoder does all the gory stuff.
    • By embedding all message steps in a single container you are relieved from storing references to previous steps. Inside of the encryptedAuthorization object you’ll find the user’s part of the plot.
    • Note the absence of REST URIs and dependence on HTTP headers for carrying information. This is “Old School” POST but using “XML-inspired” typed JSON objects.
    • The API is supposed to be synchronous, otherwise you cannot really reap the benefits of embedding and counter-signing.

    Right, this scheme does not use a separate Authorization Server since there is nothing to store (“lodge”); the “API Server” does both the authorization and execution. It is essentially “EMV on steroids” following (but greatly extending) the trail already set by Apple Pay. There is no TTP either; only the parties that are directly involved in the transaction sign message data. This scheme heavily depends on discovery services like: https://mobilepki.org/webpay-payeebank/

    I think it would be worthwhile trying to explain how PAR is supposed to deal with multi-step transactions.

  7. Torsten Lodderstedt reporter

    @Anders Rundgren the need to store something is not the reason why an authorization server is used in OAuth. The main motivation for having a dedicated authorization server is to perform authentication and authorization (in the sense of the user agreeing to delegate some rights to a client) in a single place across multiple APIs. This allows to bundle the user/credential management in one place, to utilize SSO across APIs and relieves the APIs from the burden to authenticate user and/or client. It’s trusted 3rd party scenario like Kerberos.

    PAR is a way to carry large amounts of data, such as needed for fine grain payment transactions, to the authorization server.

    Can you please explain what you mean by multi-step transactions?

  8. Anders Rundgren

    @Torsten Lodderstedt I don’t contest the value of OAuth but all schemes tend to have a limit where they start to become awkward. Since I’m (unlike you) is not an OAuth guru, I guess I don’t fully see the light here 😇

    Regarding multi-step transactions, this is what the Gas Station example represents.

    Note that there is no client (using OAuth terminology) in the scheme I presented. The scheme targets the following: https://www.ecb.europa.eu/press/key/date/2019/html/ecb.sp191126~5230672c11.en.html
    👉 But progress at the back-end has not translated into similar progress at the front-end, which remains fragmented, with no European solution emerging for point-of-sale and online payments 👈

  9. Tom Jones

    well, there is a client. The gas station pump in the user's client in the sense that i makes are request for user assets in the name of the user. The problems with open id and oauth in general is that they are a simple restful (in most cases) protocol that maintains limited user state and no proof (ID and grants) of any action by the user. UK OBIE layers that kind of stuff over openid on their own. It is not clear to me why the front-end is of use to you. It is inherently insecure. What security it has is transaction security. Peace ..tom

  10. Anders Rundgren

    @Tom Jones Right, using FAPI et al there is no defined (user-side) client. The idea seems to be that FinTechs should compete with proprietary (mostly secret) user-side solutions and then the market selects which one(s) to use through Darwinian processes. Another school claims that the idea is rather that large retailers should offer their own “Apps” like Starbucks in the US. Unfortunately the Merchant-side of the coin is also entirely proprietary (unless the Merchant is the TTP/PISP as well).

    The Open Banking Wallet represents a different way addressing payments which though requires a patch in the Open Banking security concept, heavily “inspired” by quite successful predecessors like EMV, Apple Pay, AliPay, and Swish (.SE). In case you would like to offer a Starbucks-like experience, you would do that through standard Web technology rather than forcing users to install yet another (moderately useful) app.

    Regarding what (and how) you authorize as a user at the Gas station pump: https://www.youtube.com/watch?v=OWn8sg7Oy3I&feature=youtu.be&list=PL2hDUr0L67peLTaxhkmwdH0F62g3F4f7Q&t=619

  11. Anders Rundgren

    @Tom Jones Regarding the “front-end”, my definition (FWIW) it is the part of a payment infrastructure that authorizes and initiates a payment. If that part is “inherently insecure”, the whole system is (by definition) insecure.

    In spite of all the news about vulnerabilities in Android, I don’t see that there actually is a major problem here since almost none of them have managed penetrating the sandbox which is the reason why you can have malware (or just “badware”) in your phone and still be able to perform secure payments. Even if malware fools you to reveal a PIN code, it wont’t get anywhere with that because the keys authorized by the PIN are only accessible by the proper App due to the sandbox. This makes phones more secure than smart cards except for physical attacks.

  18. Tom Jones

    The title of this thread continues to bother and milead me. APAICT the PAR and RAR convey request data, not authz data. Can we be sure that the distinction is made?

  19. Francis Pouatcha

    @Tom Jones I do believe PAR an RAR deal with request authZ data and not with request data. For example in an open banking payment initiation request, request data can be an ISO20022 PAIN.001 xml document. Request authZ data will only consist of a json subset of the request data prepared for the AS so AS can proceed with the authZ.

  25. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
FAPI 1: Advanced
Milestone
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!