Timeout resolving did:web

[clehner]

The did:web issuer of VC case 5 sometimes responds slowly, causing the test to fail due to timeout.

Here is an example of the timeout happening when running the tests in GitHub Actions:
https://github.com/spruceid/didkit/runs/2187670579?check_suite_focus=true#step:14:53

Test timeouts are set to 20 seconds:
https://github.com/w3c-ccg/vc-http-api/blob/b4df10dfdce98b453a2333e7ec1728a10bcc54d1/packages/vc-http-api-test-server/services/jest/cli.js#L4

Timing fetching the DID document with curl shows it taking up to 40 seconds:

Timed DID resolution

$ time curl -svo did.json https://vc.transmute.world/.well-known/did.json
*   Trying 2607:f8b0:4006:815::2013:443...
*   Trying 172.217.7.19:443...
* Connected to vc.transmute.world (172.217.7.19) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2486 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=vc.transmute.world
*  start date: Feb 17 16:59:27 2021 GMT
*  expire date: May 18 16:59:27 2021 GMT
*  subjectAltName: host "vc.transmute.world" matched cert's "vc.transmute.world"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1D2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x55c4acd2ea60)
} [5 bytes data]
> GET /.well-known/did.json HTTP/2
> Host: vc.transmute.world
> user-agent: curl/7.74.0
> accept: */*
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
} [5 bytes data]
< HTTP/2 200
< vary: Origin
< access-control-allow-origin: *
< content-type: application/json; charset=utf-8
< x-cloud-trace-context: e3159fa7f1c3c4d74c6b4c63a2a59d9c;o=1
< date: Thu, 25 Mar 2021 12:46:20 GMT
< server: Google Frontend
< content-length: 5066
<
{ [5 bytes data]
* Connection #0 to host vc.transmute.world left intact

real    0m28.975s
user    0m0.011s
sys     0m0.014s
$ jq .id did.json
"did:web:vc.transmute.world"

Some time later...

$ time curl -I https://vc.transmute.world/.well-known/did.json
HTTP/2 404
vary: Origin
access-control-allow-origin: *
content-type: application/json; charset=utf-8
x-cloud-trace-context: 8b460a2fbbca1ecbb9007453ae7e5cb2;o=1
content-length: 93
date: Thu, 25 Mar 2021 13:02:28 GMT
server: Google Frontend


real    0m40.265s
user    0m0.037s
sys     0m0.011s
$ time curl -I https://vc.transmute.world/.well-known/did.json
HTTP/2 404
vary: Origin
access-control-allow-origin: *
content-type: application/json; charset=utf-8
x-cloud-trace-context: b536ab1fb35d3b28df28b4316d97eb9c;o=1
content-length: 93
date: Thu, 25 Mar 2021 13:02:37 GMT
server: Google Frontend


real    0m0.389s
user    0m0.033s
sys     0m0.008s
$ time curl -i https://vc.transmute.world/.well-known/did.json | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
HTTP/2 200   0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
vary: Origin
access-control-allow-origin: *
content-type: application/json; charset=utf-8
x-cloud-trace-context: 3062a3c24f2e4685bb158f85a9433f37;o=1
date: Thu, 25 Mar 2021 13:02:53 GMT
server: Google Frontend
content-length: 5066

{"@context":"https://w3id.org/did/v0.11","id":"did:web:vc.transmute.world","publicKey":[{
[...]

It looks like the web server may be spinning up on demand, since subsequent requests respond faster.

Is vc-http-api meant to test verifying a VC where resolving the issuer's DID may have high latency? Or should the issuer have high availability, like the vc-http-api endpoints themselves?

Are implementations encouraged to locally cache DID documents rather than resolve them dynamically, to prevent such timeouts or other issues - similar to how JSON-LD context files are treated?

[bumblefudge]

Was 20 a conscious choice, or an offhand assumption ("SURELY resolving a webpage won't take more than 20 seconds on a properly-configured web server")? Offhandedly, my first instinct is to set it to 60 and mention it (and other adjustable timeouts) in the troubleshooting section...