Add ttl property to MoneyAddress service entry

[mistermoe]

Credit to @cwmyers and @aparkersquare for raising this!

Context

Currently there's no way to reason about whether a DAP's DID Document should be cached and if so, the appropriate duration. The decision ultimately hinges on whether a money address is expected to change and if so, how frequently.

For example, let's say [email protected] resolves to:

Note

Other fields in the DID Document have been omitted for brevity

{
  "@context": "https://www.w3.org/ns/did/v1",
  "service": [
    {
      "type": "MoneyAddress",
      "id": "#some-id",
      "serviceEndpoint": ["urn:btc:addr:1LMcKyPmwebfygoeZP8E9jAMS2BcgH3Yip"]
    }
  ]
}

It's unclear whether resolving this DID again would result in a different address. There's 3 possible outcomes:

• address changes every time
• address changes infrequently
• address never changes

which is effectively equivalent to "🤷 anything could happen".

We should consider providing some way to express a ttl. 3 Approaches come to mind:

Options

Include ttl property as part of service entry

e.g.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "service": [
    {
      "type": "MoneyAddress",
      "id": "#some-id",
      "serviceEndpoint": ["urn:btc:addr:1LMcKyPmwebfygoeZP8E9jAMS2BcgH3Yip"],
      "ttl": 30 <------------
    }
  ]
}

This is a pretty straightforward option and the DID Core specification does allow arbitrary properties to be included in service entries. However, in practice, DID resolution libraries, particulary those written in strongly typed languages, have little to no support for randy McRando properties (understandably so). Moreover, certain DID Methods may not even support yolo properties due to size constraints of wherever that method stores the actual DID Document.

If we go with approach we'll want to answer the following questions:

• optional or required
• type for value int (e.g. 30), string (e.g. '30s')?
• time unit that value is expressed in. "30 what? seconds? hours?"

---

ttl is expressed as part of the MoneyAddress

e.g. urn:btc:addr:1LMcKyPmwebfygoeZP8E9jAMS2BcgH3Yip:30

this effectively leaves if/how ttl is expressed to whatever convention is established for a given currency's Currency Specific Parts

This allows each individual currency convention to decide:

• whether supporting ttl makes sense for the currency and address kind.
• how ttl should be expressed given the currency and address kind

this approach may make it such that ttl isn't even explicitly expressed. for example, btc:addr could imply "new every time".

Downsides here are the downsides that exist whenever flexibility and optionality exist in a specification. Though, given that this spec has no intention to control or establish the conventions for all Currency Specific Parts, and instead provide a location where conventions can be registered and therefore discoverable and recognizable, we technically wouldn't be making the spec any more flexible than it already is

Would be curious to hear other peoples suggestions.

[jiyoonie9]

i think option 2 ttl expressed as part of MoneyAddress makes more sense. if it makes sense for the currency, include it, and specify ttl should be in one standard time unit (i would vote seconds). if it's infinite ttl (i.e bank account), one can just leave it out

[geehsien]

Is there an argument for this being at the response/document level, and not at the service level?

I'd agree that different endpoints could theoretically have their own TTLs, but I wonder if this level of granularity might be overkill, and not map to the requester's actual needs.

Instead, maybe an Expires header like HTTP has:

Expires: Tue, 25 Jun 2025 12:00:00 GMT

[jiyoonie9]

another idea is adding the ttl as a query parameter like

urn:btc:lnurl:whatever?ttl=30

@geehsien if there were N money addresses with a single dap, then we wouldn't be able to impose different ttl's per money address? unless I am misunderstanding what you mean by service level

[decentralgabe]

DID resolution metadata should include a TTL field if applicable with the nextUpdate field.