Possibility of "chaining" (or delegating) DAPs (or DIDs)?

[aparkersquare]

I was thinking about how I would like to use DAPs in a world where my apps/banks provided me with DAPs that resolved to money addresses at those apps/banks.

Ideally I would like to have a single DAP (that I control), but have it to resolve to a set of money addresses across the apps/banks that I use (based on where I want each currency/protocol to be sent).

The current specification would allow you to register the underlying money addresses in a single DAP registry, and therefore use a single DAP to receive funds across apps/banks.

But this suffers from a couple of issues

• requires resolving the DAPs to find the money addresses (which should be possible but not something most people will know how to nor want to do)
• requires maintenance to keep the DAP registry up to date with the money addresses

It may be possible to build tooling around this (periodically sync the money addresses to the registry), but I think what I'd ideally like to do is to register the DAPs from the apps/banks at the DAP registry of my choice, and have the DAP resolution process resolve the "sub-DAPs" automatically.

An alternative to registering "sub-DAPs" could be done by registering "sub-DIDs", but again this is probably not something most people will know how to or want to do, if the user experience is based around DAPs (I don't think we should expect them to DIDs even exist).

Some points that would need to be considered if this was added to the DAP resolution process:

1. This would lead to effectively a "graph" of DAPs, with the possibility of cycles (e.g. two DAPs, each registered at the other DAP registry). In general this could make DAP resolution significantly slower, and there would need to be a mechanism to avoid infinite recursion.

2. The possibility of multiple money addresses for the same currency/protocol pair once the full DAP resolution process was completed (even if a single DAP registry did not allow conflicts, you could have multiple apps that provide a DAP that resolve to a money address with the same currency/protocol).

There may be other possible considerations.

[aparkersquare]

Some (perhaps premature) thoughts on how this could be implemented.
I'm going to use the term "sub-daps" below, although I think there is almost certainly a better term for this.

The current DAP resolution process is

1. resolve the web DID (transformed from the DAP) to find the DAP registry URL
2. get the DID (for the DAP handle) from the DAP registry
3. resolve the DID and get the list of Money Addresses

My first thought for doing this would be to have a money address scheme for a DAP (i.e. hook into step 3 of the resolution process).
However these "dap money addresses" would be unlike (existing) money addresses as it is not a concrete currency/protocol. A more robust way of doing this would be to have a different type of service that was registered with the DAP registry (i.e. something other than a type: MoneyAddress service). Step 3 of the resolution process could effectively return a list of money addresses, and a list of sub-daps.

I don't think it belongs at step 1 of the process (return multiple registry URLs) as it would require the DAP handle to be the same across the registries, but users are almost certain to have different handles in DAPs across different registries (i.e. across apps/banks).

I think this idea belongs at step 2 of the DAP resolution process.
This closely matches the problem statement above, where I said I would like to register daps from apps with the DAP registry.

This step currently returns a json document with the did and the proof.
It could include a list of "sub-DAPs" in the document. It would even be possible to "filter" the money addresses resolved by the "sub-DAP" to a particular (set of) currency/protocol at this point.

e.g.
If you wanted to use @moegrammer/didpay.me as your DAP.
But delegate the btc:lnaddr and btc:addr money addresses to @moegrammer/cash.app,
and delegate all eth money addresses to @moe/somewallet.com

the result from the DAP registry might look something like this

{
  "did": "did:web:didpay.me:moegrammer",
  "proof": {...},
  "sub-daps": [
    {
      "dap": "@moegrammer/cash.app",
      "filters": [
        {
          "currency": "btc",
          "protocol": "lnaddr"
        },
        {
          "currency": "btc",
          "protocol": "addr"
        }
      ]
	},
    {
      "dap": "@moe/somewallet.com",
      "filters": [
        {
          "currency": "eth",
        }
      ]
	}

  ]
}

[decentralgabe]

requires resolving the DAPs to find the money addresses (which should be possible but not something most people will know how to nor want to do)

isn't the DAP supposed to be a jumping-off point for MA discovery?
reverse indexes could also be surfaced (i.e. query all cash tags that are 'user' and find their DAPs) - note this raises a point about provably adding MAs to DAPs but that's a larger discussion...

requires maintenance to keep the DAP registry up to date with the money addresses

it's easier to maintain a single source of truth than many

---

if the problem is "I have multiple DAPs, how do I associate them?" then you could use DID core properties like aka https://www.w3.org/TR/did-core/#also-known-as

[aparkersquare]

requires resolving the DAPs to find the money addresses (which should be possible but not
something most people will know how to nor want to do)

isn't the DAP supposed to be a jumping-off point for MA discovery?

Yes, but my 70 year old mother isn't going to know anything about Money Addresses or DIDs.

She can probably understand if the bank gives her a DAP, and her bitcoin wallet gives here a DAP, and then I can pay her with those.
It would be nice if she had some way to use a single DAP that could redirect to those though (I think that's half the point of DAPs!).

if the problem is "I have multiple DAPs, how do I associate them?" then you could use DID core properties like aka w3.org/TR/did-core#also-known-as

Yes, I probably didn't explain it very well.
The basic issue is what happens when I have multiple DAPs, one from each app or bank I use (trying to think ahead a bit here!).

e.g. Say I have the following DAPs, each resolving to a different set of money addresses.

@rabidrabbit/walletofsatoshi.com    (lightning address, bolt12)
@andrewparker/fakebank.com          (usd, btc on-chain, bolt12)
@andrewvparker/bitkey.world         (silent payment address for on-chain, bolt12)

What's the "right" way for me to have a single DAP that resolves to the set of money addresses I want to receive funds at?
e.g. I never want to send bitcoin to "fakebank.com" even if they give me a money address for it, but I do want to send fiat currency there.

I'm not really familiar with the DID standards. I had a quick look at the "also-known-as", and I wasn't sure how that would relate to resolving DAPs

e.g. if I somehow manage to set the AKA for the DID underlying @aparker/didpay.me to include the DIDs underlying the other two DAPs (and vice-versa, which is required by the spec!), how would that result in the money addresses being resolved?
The DAP spec doesn't talk about this.

Based on my understanding, at best it seems that it would resolve to the union of all the money addresses resolved from each of the DAPS (although I'm not sure how that would work).
But perhaps I'm misunderstanding how the AKA feature works?

As I tried to indicate above, ideally I'd like to control exactly which money addresses were resolved, but without having to do that manually, and it seems to me like it would be best to specify how that could work in the DAP spec.

[decentralgabe]

She can probably understand if the bank gives her a DAP, and her bitcoin wallet gives here a DAP, and then I can pay her with those.

If this is true then we've failed

It would be nice if she had some way to use a single DAP that could redirect to those though (I think that's half the point of DAPs!).

Yes she should just have a single DAP. If services want to intentionally misuse DAPs we should not bend over backwards to accommodate their mistakes.

I'm not saying "users will NEVER have more than one DAP" but really they shouldn't have many, it's supposed to be a unifying identifier.

---

With regard to AKA, yes the spec will need to be updated to add processing rules around handling linkage of identifiers. Ideally the language would talk about resolution order, conflict avoidance, etc.

So, if we feel the need to link DAPs, aka is a decent way to do that, and I'm supportive of language to address it.

[aparkersquare]

She can probably understand if the bank gives her a DAP, and her bitcoin wallet gives here a DAP, and then I can pay her with those.

If this is true then we've failed

It would be nice if she had some way to use a single DAP that could redirect to those though (I think that's half the point of DAPs!).

Yes she should just have a single DAP. If services want to intentionally misuse DAPs we should not bend over backwards to accommodate their mistakes.

I'm not saying "users will NEVER have more than one DAP" but really they shouldn't have many, it's supposed to be a unifying identifier.

With regard to AKA, yes the spec will need to be updated to add processing rules around handling linkage of identifiers. Ideally the language would talk about resolution order, conflict avoidance, etc.

So, if we feel the need to link DAPs, aka is a decent way to do that, and I'm supportive of language to address it.

From a CashApp point of view, expecting our customers to go to a third-party DAP registry, create a DAP, and then register their CashApp money addresses (on-chain address, lightning address, bolt12 offer etc) seems unrealistic. Almost no-one would do it, and out of those who do some might do so incorrectly or partially. This is a very large barrier to entry for the customers. The result would mean that sending to a @cashtag/cash.app DAP would almost never work.

Also CashApp would not be responsible for what occurs on a third-party DAP registry, so I don't think registering a third-party DAP as the one presented on behalf of our customers would ever be something that we'd want to do.

It seems to me the only way to be sure the CashApp customer experience is smooth would be to provide our customers with a DAP (e.g. @<cashtag>/cash.app), and run our own DAP registry.

Certainly we should definitely make it easy for our customers to use the money addresses associated with their CashApp account via an external DAP registry, so they could use any DAP they liked and have the funds delivered to their CashApp account. But we'd still want the CashApp provided @cashtag/cash.app DAP to work.

Updated - and vice-versa - an easy way to use the money addresses provided via the CashApp account via another DAP registry would be desirable. Interoperability should work both ways.

I would expect the same to be true of other financial institutions.

Updated
As mentioned above, the DAP spec and the use of a DAP registry would allow use of the individual money addresses manually, but this would be tedious and error-prone.
Ideally we want a way to make "chaining" DAPs easy and robust, and I think it should be part of the specification in order to make it interoperable and easy to implement.