Criteria for selecting financial data Verifiable Credentials Issuers

[jacksophtron]

When a user of TBDex wants to obtain financial data such as his account and routing number, transaction history or balance to apply for a loan or to buy or sell bitcoin an API that can provide the data automatically, without copy/paste error and signed as accurate is usually the preferred option.

When more than one option exists to obtain a VC with the required financial data the hub should select the provider without asking the user. This is to optimize the user experience (and because the user rarely has the information required to make an informed selection).

When more than one provider is available the selection criteria should be:

Privacy - Some providers resell the financial data or store it for long periods. Other providers are third parties (they are not the data source, but are intermediaries that screen scrape the data or call the data source’s API and then issue a VC) that must access the data on behalf of users, but are contractually obligated to delete the data and never reuse it.

Speed - Some services are faster than others and the speed can range from a few milliseconds to over 3 minutes among providers.

Cost - Some providers have an annual minimum payment in the tens of thousands of dollars with a per connection fee at over a dollar each. Other providers do not have annual minimums and charge only 1,000 satoshis per API call.

Accuracy - Financial data is often inaccurate or missing. For example obtaining the full account number more than 90% of the time or obtaining more than 90 days of transaction history is still a significant selling point among financial data providers as of 2022.

The identity hub reference implementation should include a simple algorithm to select a VC issuer. It should be easy to understand and modify to reflect their particular use cases and target users of a specific implementation.

One option is to assign an arbitrary number of points to privacy, speed, cost and accuracy that are then multiplied by the provider's score in each of these areas.

Let's call these priority points and assign an arbitrary value to each.

Default Priority Points:

Privacy - 12 priority points Speed - 7 priority points Cost - 14 priority points (with a maximum cap to default to 10,000 sats) Accuracy - 9 priority points

This means that if provider A has excellent privacy but is very slow, cheap and accurate it would be awarded 12+0+14+9 = 34 points. If provider B has poor privacy, but is very fast, cheap and accurate it would be awarded 0+7+14+9 = 30 points. As a result provider A would be selected over provider B in this example.

Since providers are usually not either 100% good or bad in these areas we can assign them an arbitrary number of points based or their self reported behavior (although as with accuracy a better mechanism for obtaining this data should be considered an open work item):

Privacy:

Original data source without any third parties accessing the data - 100 privacy points.

Third party without access to credentials, with access to data but is contractually obligated to immediately destroy all copies - 90 privacy points.

Third party with access to credentials and data, but is contractually obligated to immediately destroy all copies - 80 privacy points.

Third party without access to credentials, with access to data and is not obligated to immediately destroy all copies - 30 privacy points.

Third party with access to credentials and data that is not obligated to to immediately destroy all copies - 0 privacy points

Speed:

0-10 seconds - 81 to 100 speed points

11-30 seconds - 80 to 61 speed points

31-90 seconds - 60 to 41 speed points

91-120 seconds - 40 to 11 speed points

121 - 200 seconds - 10-1 speed points

Over 200 seconds - 0 speed points

Cost:

0 - 1,000 sats 100 cost points

1,001 - 4,000 sats 60 cost points

4,001 - 10,000 sats 20 cost points

Over 10,000 sats - 0 cost points

Accuracy:

This is a difficult criteria because it is specific to a given financial institution and data field. For example a provider might retrieve the account number from Chase 99.999% of the time, but obtain the routing information only 10% of the time.

For now this can be treated as an open work item as initially there will not be many cases where more than one provider is available for a given financial institution and the subset where data accuracy would be the deciding factor is approaching zero, but the ideal solution is for wallets to report success rates over time so that they can be used to route requests.

Example Calculation

Let's assume provider A is a third party that does access user credentials and data, but is contractually obligated to delete all data (80 privacy points), will take 20 seconds to retrieve the data (70 speed points) and charges 1,000 sats (100 cost points).

To convert from privacy, speed and cost points to selection points we multiply the two numbers

Privacy - 12 priority points Speed - 7 priority points Cost - 14 priority points (with a maximum cap to default to 10,000 sats)

80 (privacy points) 12 priority points = 960 selection points 70 (speed points) 7 priority points = 490 selection points 100 (cost points) * 14 priority points = 1400 selection points

With a total of 2850 selection points provider A will be chosen when the alternative providers have fewer than 2850 selection points.

This was briefly discussed with @csuwildcat on a call last week.

[LiranCohen]

Is this under the assumption that TBDex will use the standard interfaces (Collections,Threads) from the Identity Hub spec to accomplish the BID/ASK portion of the TBDex proposal? Or will there be custom interfaces loaded into the Identity Hub to support TBDex?

[jacksophtron]

I will reread the identity hub spec because I may have missed something important. I was assuming that the speed, privacy and cost would be published in the catalog along with the other information about the availability of given DID issuer and that the identity hub would select a DID issuer based on this criteria.

For example when a seller of bitcoin offers a price in the bid/ask process they might also specify this offer requires a DID that includes the bank account balance of the buyer (and maybe an allow list of DID issuers), but the identity hub would then need to select an acceptable DID issuer (based on this criteria).

[LiranCohen]

That might be the case, and I'm not fully sure how TBDex will be implemented exactly.

But currently the IdentityHub spec has a set of common interfaces (collections, threads, and permissions), those coupled with a specific Schemas are able to create many different types of applications/interactions between different DIDs.

I was kind of under the impression that TBDex would be a custom-loaded interface/module, and the feature detection would let you know if a hub is compatible with those interfaces. I'm not involved with that team so I'm not sure what the plans are with regard to that.

[jacksophtron]

After going through the spec again briefly I think that this is not specifically addressed. When a hub has determined it needs to obtain a DID with a specific schema and more than one DID issuer is available it needs to choose. This is a suggested method for choosing when the schema is "bank account data."

[csuwildcat]

Some clarifications:

There is no custom tbDEX interface, tbDEX is just a set of schema'd objects sent over Threads and data objects fetchable in Collections. The point of this tech is specifically that you don't create new interfaces or API surfaces, your messages are your own API that you get by simply defining their schemas and how to handle them. You'll never see a tbDEX-specific feature, because tbDEX is literally just a set of message types that are defined independently.

Jack, I'm not sure, but I think you may again be twisting up Decentralized Identifiers with Verifiable Credentials. No one issues DIDs, users just have them, and Issuers issue credentials. That said, you can tell which Issuers can issue which credentials by looking for Credential Manifest objects present in their Collections. Credential Manifests are schema'd objects that define what credentials an Issuer can issue.

[jacksophtron]

Yes, I opened this before I got clarity on VCs vs DIDs.

"...you can tell which Issuers can issue which credentials by looking for Credential Manifest objects present in their Collections."

Would it make sense to change things so that:

"...you can tell which Issuers can issue which credentials and their cost, speed and confidentiality by looking for Credential Manifest objects present in their Collections."

[LiranCohen]

Thanks for the clarification @csuwildcat, I wasn't sure exactly how the plan was for TBDex to accomplish its needed set of features.

@jacksophtron these are some good questions and maybe we can try to map it out to see where these requirements would come into play.

I'm trying to put a mental model together on how one would build this given the TBDex whitepaper.

Looking at the On Ramp example

Steps 2-4 say:

2. Through the wallet user interface, Alice initiates a flow to request cryptocurrency XYZ in exchange for 100.00 USD.
3. The wallet generates a semantic message that reflects an ASK, encoded with the parameters of Alice’s request.
4. The wallet sends the ASK message to the Identity Hubs of each PFI it desires to include as a potential fulfillment counterparty.

Is this ASK actually a "CollectionsQuery" request against a "TBDex Bids and Requirements" schema?

In which case the PFI would respond back with a response array of Bids & Requirements, which would then potentially detail cost & confidentiality? I'm not sure how speed would play into this scenario, that would be something the client would have to determine?

If that's the case, then Alice would still need to "accept" any of those bids in a new messages.

@jacksophtron Are you thinking about a scenario where Alice could "auto accept" a given bid? And would that be something defined within the spec? I'm not sure how that would work as Alice would still need to sign the acceptance, and those keys should only be available within her wallet and not within her Hub (Node).

Also @csuwildcat, if I'm thinking about this correctly, would we need to define some sort of "schema defined properties" in the CollectionsQuery request? Right now there is only a "dateSort" field which would allow some sorting, but nothing that would allow Alice to specify how much she is looking to purchase in her request to the PFI.

I'm going to think about this a little more within the context of the spec myself and see if I can gain some better understanding, but would definitely appreciate some further conversation around how these things could be accomplished.

[jacksophtron]

I think your comment helped me realize issuers of VCs should be seen as a sub-type of PFI.

When you use the bid/ask process to evaluate offers from bitcoin sellers part of those offers are required prerequisites (VCs).

Then you should start a new bid/ask process to obtain a VC from competing providers. The cost of a VC in sats alone could be higher than the fees charged by a liquidity provider (and users are mostly paying with massive privacy compromises) so competition here is arguably more important than among liquidity providers (especially for small first time purchases).

[jacksophtron]

So instead of trying to get all of the decisioning criteria above hard coded we can just define various types of VCs and then reuse the bid/ask process (only changing the criteria that makes up a bit or ask to include these additional attributes). Thoughts @csuwildcat @LiranCohen ?

[mistermoe]

@jacksophtron take a look at the Presentation Exchange specification. It's the means through which a PFI communicates which VCs they require from Alice and which issuers they trust for those VCs.

This state machine diagram details the current message flow we're envisioning for tbDEX. It's early days so this might change (the rest of this README is in flux so i'd ignore everything except for the diagram 😄).

The IDVRequest message will contain the Presentation Definition and the IDVSubmission message will contain the Presentation Submission.

In order to prevent unnecessary back and forth between Alice and the PFI only to realize that Alice doesn't possess the VCs required by a PFI, wallets will likely make a request to a PFIs DWN to prefetch the VCs required by a given PFI to engage in a value exchange with them. This won't return all possible VC requirements simply because not every VC will be required for every exchange. some exchanges could require additional VCs (e.g. exchanges above $10,000 or something similar)

I'm working on an architecture diagram that i should have ready by mid next week that i'll share. Hopefully it'll provide a bit more clarity!

[jacksophtron]

This makes sense. One thing I noticed in the message exchange is that it assumes you are buying another currency and it doesn't allow for additional attributes (sorry if I'm jumping hate and you just haven't included it yet). For example I might want to buy bitcoin from a vendor that at least promises to delete their records. Or I might want to buy something else (like a VC or a loan).

Would it make sense to have a "product" that contains required attributes (asset being sold) and options attributes (trade retention policy) as part of the bid/ask messages?

[csuwildcat]

Yes, we may need a more generalized set of properties in some areas, and will mod accordingly to ensure the flow is extensable for non-currency exchanges.

[jacksophtron]

I was thinking even for currency to currency exchanges the payment methods themselves also need to be negotiated. I wouldn't accept an standard ACH payment for bitcoin (as an individual seller), but I might accept Zelle. Thought if the ACH payment was insured against reversal I'd accept it.

Would it be helpful if I started a table with the things people seem likely to buy on TBDex and the attributes that we think will get negotiated?

[mistermoe]

@jacksophtron going to go ahead and close this out. Feel free to re-open if we missed anything