Orie Steele

regarding "audit trails".... I think this is a waste of time... did web is not meant to be like other did methods, and leaving some obvious reasons to upgrade for...

@dmitrizagidulin I prefer to pull caching / expiration / headers from the resource and simply reflect them in the did doc meta data.

`proof` was removed from did core, and IMO, it's best not to use it at all on did documents.... trust in a did document should come from the DID Method...

@dmitrizagidulin JSON-LD Proofs __do not help__ increase trust with did:web. IMO, did:web should not have any normative requirements on JSON-LD Proofs. did:web trust flows from web server control, and `proof`...

Yes, the DID WG has decided specifically to not put meta data in the did document, and the did spec registries has a separate section to make this even clearer:...

https://github.com/transmute-industries/did-key.js/blob/master/packages/did-key-common/src/getResolver.ts#L113 https://w3c-ccg.github.io/did-resolution/#output-resolutionmetadata https://w3c-ccg.github.io/did-resolution/#output-documentmetadata ^ all of these are places that are fine to put metadata imo...

I assume we are talking about the normative requirements did:web has on "resolution metadata" and "document metadata" This issue is not very specific, and appears to be addressing both proof...

To be crystal clear: 1. There should be no meta data in a did:web [did document](https://w3c-ccg.github.io/did-resolution/#output-diddocument) (no `proof`, `updated` or `created`). 2. I am ok with `updated` and `created` in...

@dmitrizagidulin yes, imo, it should be possible for the web server operator to control all 3 sections via vanilla JSON. I would not be opposed to fancy HTTP Header based...

did:web resolvers should implement: ``` resolveRepresentation ( did, did-resolution-input-metadata ) -> ( did-resolution-metadata, did-document-stream, did-document-metadata ) ``` over http... they should support representations other than JSON, such as CBOR. I...