Consider using OAuth 2.0/OIDC

[decentralgabe]

Today each message has its own signature. This is convenient as each message is independently verifiable, but also carries some overhead that we may be able to reduce.

OAuth 2.0 and OIDC are widely used and adopted standards on the web today for doing authorization and authentication. As an alternative to today's tbDEX messages we could follow the OAuth + OIDC method of doing things which would be to:

• Authenticate with a party (like a PFI), via SIOPv2, gaining an access token and id token
• Use the access token in an authorization header for subsequent requests

This has a number of benefits:

• standardization - access tokens are widely adopted and have a ton of existing open source tooling and documentation
• simplicity/performance - centralization of security logic (token validation is simpler than independent signature validation); and tbDEX messages can be simpler too (no need for canonicalization schemes, supporting a multitude of signature verification schemes)
• revocation/expiry - allow PFIs/parties you're interacting with to revoke/expire your access to their APIs via access tokens
• delegation/consent - allow entities interacting with PFIs/parties to have fine-grained access control to different APIs/resources

We can also leverage new extensions to OAuth 2.0 such as Demonstrating Proof of Possession (DPoP) to bind access tokens to specific clients cryptographically. This can help mitigate token theft and replay attacks that can be present with the use of bearer tokens.

[phoebe-lew]

We frequently talk about using DIDs as a "novel auth mechanism", so am generally in favor of using something more widely accepted! Anecdotally, the DID authn was confusing for some partners during hack weeks, who would ask if they still needed an API key etc.

I've only used OAuth from the client perspective, but curious if DIDs would still be in this flow? Like would the client authing present their DID and get an access token in return, which they'll use for future requests?

Also mentioned sync whether message integrity could still be ensured with this approach, @decentralgabe mentioned that the bearer token + TLS should be satisfactory, but feel free to add any other context!

[KendallWeihe]

So basically each user is it's own authorization server. Makes sense to me. This is a concept which is lower-level than just tbDEX, which would be an application of DID+OAuth tech -- @decentralgabe is there an existing body of work around the intersection of DID's+OAuth (perhaps some implementations)?

Couldn't it also be that a third party, in the case of tbDEX the issuer of the Sanctions/KYC/etc (whatever the Offering defines) credentials acts as the authorization server? In this case, we would still want to make sure the users private keys are used as a source of provenance, because, for example, the user needs to be able to assert ownership over the contents of the message.

My initial thinking is this is a no-brainer, for the purposes of integrating into already widely adopted solutions, and doing so without the loss of any value. To @phoebe-lew's point, the only reduction in features that I see is the loss of the signature also acting as an integrity check. But, we could also implement that in a different mechanism. @decentralgabe can you elaborate further on this (from above comment)

the bearer token + TLS should be satisfactory

I'm not an expert in access tokens, but I didn't think they offered any sort of integrity check functionality.

---

This made me think of something which I'm not sure we have touched on -- man-in-the-middle attacks. Which is, encrypting the message over the wire. We're currently progressing down the HTTP transport layer path, which, obv has HTTPS for this, but it may be worth discussing not relying on HTTPS; if only, because once we go to a different transport then we'll have to concern ourselves, but also because HTTPS is one of the areas DIDs shine, in that they're better pub/private key cryptography (or at least, can be, depending on the given DID method).

[decentralgabe]

@phoebe-lew wrote

but curious if DIDs would still be in this flow?

Yes, they are used as a part of SIOPv2 which facilitates the auth flow I described. You can see the property subject_syntax_types_supported which include DID methods.

@KendallWeihe wrote...

is there an existing body of work around the intersection of DID's+OAuth (perhaps some implementations)?

Yes, see above!

Couldn't it also be that a third party, in the case of tbDEX the issuer of the Sanctions/KYC/etc (whatever the Offering defines) credentials acts as the authorization server?

We don't need to restrict to DIDs, necessarily. A user with a direct relationship with an existing auth server could leverage that relationship to authenticate. Of course, we want to promote self sovereignty and reusable identity.

the only reduction in features that I see is the loss of the signature also acting as an integrity check

TLS does provide integrity protection via a message digest. But we would be relying on our transport layer to provide message layer security. I believe this is sufficient, as the risk of a corrupt message seems small. The bigger risk would be an intercepted authorization (bearer) token, which you mention....We can leverage an extension to OAuth 2.0, DPoP to have auth tokens cryptographically bound to a party's DID, reducing the risk of MITM.

Which is, encrypting the message over the wire. We're currently progressing down the HTTP transport layer path, which, obv has HTTPS for this, but it may be worth discussing not relying on HTTPS

OIDC supports encrypting tokens and messages (see: section 10.2 and request_object_encryption_alg_values_supported using JSON Web Encryption). OID4VP (Verifiable Presentations) also supports encryption.

Outside of the flows existing OAuth/OIDC specs cover, I believe we can (and should) specify an option to encrypt tbDEX messages.

[KendallWeihe]

One killer feature of this: corporations who have existing OAuth authorization servers for disclosing user personal data for downstream B2B integrations could adopt DID-based accounts without affecting those existing B2B integrations (beyond maybe requiring the user to re-auth once). For example, I think Plaid is a big user of OAuth-based flows. You could imagine a user who has an account with their financial institution, let's say their regional bank XYZ, who has previously enabled a Plaid-based integration for some downstream fintech app. In which case, their regional bank XYZ could integrate w/ the tbDEX network by becoming a PFI and said user could exchange with them and still make-use of their downstream Plaid integration without any additional work needed.

---

We don't need to restrict to DIDs, necessarily. A user with a direct relationship with an existing auth server could leverage that relationship to authenticate. Of course, we want to promote self sovereignty and reusable identity.

VERY good point! Although, I do think there is a plethora of assumptions of DID involvement throughout the implementations & even the spec. Still though, it's a keen callout.

---

Created a new ticket for message encryption https://github.com/TBD54566975/tbdex/issues/185

[decentralgabe]

For example, I think Plaid is a big user of OAuth-based flows. You could imagine a user who has an account with their financial institution, let's say their regional bank XYZ, who has previously enabled a Plaid-based integration for some downstream fintech app. In which case, their regional bank XYZ could integrate w/ the tbDEX network by becoming a PFI and said user could exchange with them and still make-use of their downstream Plaid integration without any additional work needed.

Exactly right, and there is the FAPI also by the OpenID Foundation which powers many of these open banking APIs. Some more resources:

• https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf
• https://openid.net/wordpress-content/uploads/2022/07/OIDF-Whitepaper_Open-Banking-Open-Data_1st-Editors-Draft_2022-07-29.pdf
• https://darutk.medium.com/financial-grade-api-fapi-explained-by-an-implementer-d09fcf2ff932

[decentralgabe]

This is done