An alternative to OAuth2

Dear List,

I have not read many of the numerous documents that have been floating around in this list so I may be totally off here :(

Anyway, as you probably know, many Open Banking APIs builds on OAuth2.  So what's wrong with that?

In Open Banking a primary drawback is that you have to (in some way) tell the merchant (resource consumer) which bank you have in order to pay.

In W3C's most recent iteration of payment technology (, this is accomplished by the user giving (through typing) the merchant his/her account number.
    "A merchant also already has a more powerful identifier,
     i.e. the raw credit card number the user provided, that
     it used to exchange to the credential ID via trusted
     server side integration with the issuing bank"

To cope with this I'm working with a different approach, partly derived from a previous Microsoft research effort called Information Cards.

In this scheme, credentials contain a URL to their issuer which removes the need for users supplying such information.

However, this is not enough since you still want to limit information to the resource consumer beyond to what is actually required.  The solution I have added to information cards, is encrypting the grant (with an issuer-specific key stored in the credential), before handing over it to the resource consumer which in turn can use it to extract the actual data or in my case perform a transaction.
This scheme also permits "credential filtering" so that resource consumers may be able to skip credentials from issuers they have no relation or knowledge about.

For identity schemes where there is no such thing as a "card processor", the requester would also have to be cryptographically bound to a grant.  A grant may be single- or multi-use.

There are no redirects in this scheme.

It is possible that this is 1) already in VC schemes or 2) doesn't really work for VC scenarios.


Received on Sunday, 13 June 2021 16:39:25 UTC