Remove "Updated" property section.

[msporny]

This PR removes the updated property from the DID Document as I don't think anyone is using the property, and it almost certainly belongs in a DID Resolver response rather than a DID Document.

---

Preview | Diff

[dmitrizagidulin]

👍, agreed that it belongs in the Resolver metadata.

[TallTed]

Why should updated belong in Resolver response, if it's about the DID Document?

Being optional, nobody is required to include it, but I can think of many scenarios where it would be useful, regardless of whether anyone is using it today, so I don't understand the motivation to remove it.

[TallTed]

Further, there must have been reasons that the property was added in the first place.

It follows that all of these should be shown to no longer be relevant, before the property should be removed. "I don't think anyone is using it" does not seem sufficient, even if we cannot easily identify any such user.

[msporny]

Why should updated belong in Resolver response, if it's about the DID Document?

... because the resolver response is information /about/ the DID Document, not the DID Document itself. Think of it like a DNS lookup... the DNS lookup response will give you information about the record you looked up, along with a bunch of metadata about the record:

$ dig google.com

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63594
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		96	IN	A	172.217.15.78

;; Query time: 66 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Mon Oct 07 18:39:21 EDT 2019
;; MSG SIZE  rcvd: 55

The Updated field is something the resolver more than likely extracts from the ledger, not the DID Document. To put it another way, just because you put updated in a DID Document doesn't mean that's when it was actually updated. It's metadata about the DID Document, not content that should go in the DID Document itself.

Being optional, nobody is required to include it, but I can think of many scenarios where it would be useful, regardless of whether anyone is using it today, so I don't understand the motivation to remove it.

It is useful, as metadata about the DID Document. Placing it directly in the DID Document itself opens up an attack vector where people might trust the information because it's there, which is absolutely the wrong thing to do (because the entity in control of the DID can set it to any value they want to).

Further, there must have been reasons that the property was added in the first place.

It was to track information related to when the document was updated... but the place where that information belongs is in the resolver response (because that's harder to attack), not the document itself (which would confuse some developers and make them check the wrong thing).

It follows that all of these should be shown to no longer be relevant, before the property should be removed. "I don't think anyone is using it" does not seem sufficient, even if we cannot easily identify any such user.

The purpose for removing it is both 1) don't think anyone is using it, and 2) it's an attack vector.

[TallTed]

Your "DNS lookup" example is actually a "dig lookup" example. host --

$ host google.com
google.com has address 172.217.10.142
google.com has IPv6 address 2607:f8b0:4006:812::200e
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.

-- or nslookup --

$ nslookup google.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	google.com
Address: 172.217.10.142

-- might be more appropriate.

---

Note that neither gives the sort of metadata you're talking about. The metadata in the nslookup output just tells you what DNS server nslookup went to to get the answer it gave you, nothing else.

---

the place where that information belongs is in the resolver response (because that's harder to attack), not the document itself (which would confuse some developers and make them check the wrong thing)

There are plenty of places where metadata such as Updated is correct within the document, and totally incorrect in the externally tracked filesystem data. You want to talk about "confused developers"? Check out "last accessed", "last modified", and "created", among other Unix-y timestamps attached to documents in Unix-y filesystems. "Created" means "when it arrived here" -- which may have been the nth copy from older media to newer. "Last modified" (usually) means "last written", which doesn't necessarily mean that any content was actually changed. "Last accessed" is at least usually reliable as a "last read".

As far as "attack vector" -- A useful test for someone looking at such documents might be to compare the internally held Updated to the externally reported timestamp. If they differ substantially (which definition may itself vary with the application, security level, etc.), that may be a red flag. If they're exact to the millisecond, that's probably also a red flag.

These are worthwhile things to talk about and consider in where and whether these properties belong. Lacking a way to usefully poll the ecosystem, "I don't think anyone is using this" continues to trouble me.

[dmitrizagidulin]

(Discussion continued in separate issue, #65 )

[msporny]

Waiting on resolution to #65.

[msporny]

Closing based on discussion at DID F2F meeting: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-01-29-did#section11

I'll open a new PR eventually to address this metadata issue.