expires header for https://www.w3.org/2018/credentials/v1 is in the past

[jeswr]

Below is a screenshot of the response headers I received when looking up https://www.w3.org/2018/credentials/v1.

The expires header is earlier than the date header which means that the document is not being cached by my browser - and hence the document is taking several hundred ms on each request rather than only the first request taking that long.

This can significantly slow down the time it takes to parse VCs as JSON-LD.

Headers:

Timing:

Since this context is presumably quite stable I would request that the document be given a fairly long expiry after the date it is requested (at minimum 1 day).

[OR13]

Suggest updating the cache time to infinity... / make it never expire, apply the same thing to v2 context.

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

2.5. expires header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: next up 1239 - expires harder for v1.1 context is in the past. would love for someone to tell me what this means.

Manu Sporny: couple of ways we can address this. ask W3C to set the expires header to a long value. 1-30 days is probably fine. could convey that the 2.0 spec says cache the context indefinitely, make sure the issue raiser is aware. assignee should be Ivan. I will comment.

Brent Zundel: happy to assign Ivan, appreciate you adding comments. believe this does not touch the data model for v2, should be fixed, but no need to continually discuss. post CR it is.

[iherman]

I am not a good apache expert. Before updating on the server, I would like to get some comments on the .htaccess file. The relevant parts would then be:

ExpiresActive On
ExpiresByType application/ld+json "access plus 1 months"

RewriteRule ^v1$ https://w3c.github.io/vc-data-model/contexts/credentials/v1 [E=json,P]
RewriteRule ^examples/v1$ https://w3c.github.io/vc-data-model/contexts/credentials/examples/v1 [E=json,P]

Header set Content-Type application/ld+json env=json

@OR13 I did not find a way to make the expiration time set to infinite. But I actually prefer to keep a regular refresh request, in the case there is a bug in the file that needs change. Even the one month access seems to be fairly large; @jeswr requested a single day...

@msporny I guess you have some experience via w3id...

[iherman]

cc @deniak your reaction is also crucial...

[msporny]

@jeswr wrote:

This can significantly slow down the time it takes to parse VCs as JSON-LD.

You should be permanently caching that context file and not loading it from the Web (unless you have a very good reason that you're not caching the file). We suggested that implementers do this in v1 and v1.1, and we are STRONGLY advising that you do this from v2 and beyond. Search for the word "cache" in the latest data model specification for more information: https://www.w3.org/TR/vc-data-model-2.0/

... or, see the next-to-last paragraph in this section for specific guidance:

https://www.w3.org/TR/vc-data-model-2.0/#json-ld

NOTE: Don't permanently cache the v2 context until the v2.0 specification becomes a global standard (expected by end of Q2 2024.

@OR13 wrote:

Suggest updating the cache time to infinity... / make it never expire, apply the same thing to v2 context.

No, we don't want to set it to infinity for the reasons Ivan stated. One accidental admin change to the file and we could permanently knock a number of implementations offline. We need to design for human error, and eventual recovery (even for systems that are implemented in ways that we don't approve of) no matter how remote the possibility. A day, week, or month seems like a reasonable expiry time (depending on how conservative we want to be).

@iherman wrote:

@msporny I guess you have some experience via w3id...

w3id.org uses a "heuristically cacheable" approach (but does not provide a "Last-Modified" header by default): https://www.rfc-editor.org/rfc/rfc9111#section-4.2.2 ... and that's not a good model here. We want to be explicit w/ the expiry time, for both the v1 and v2 context.

[OR13]

Once the TR happens, doesn't setting the cache to anything other than infinity signal we expect the context to change?

I get the argument about malicious admins... But it would seem a better defense to set the cache time to infinity when you know it's correct, than it would be to encourage clients to load a context that expired, because the latter will actually lead to broken signatures in the case of an insider threat.

[iherman]

Once the TR happens, doesn't setting the cache to anything other than infinity signal we expect the context to change?

All recommendations, or adjacent files like the context file, may have errata, and W3C does republish recommendations with such errata handling time-to-time, when needed. The same is true for a context file.

[iherman]

The issue was discussed in a meeting on 2024-01-24

• no resolutions were taken

View the transcript

2.8. expires header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: Expires header for HTTPS credentials v1 is in the past.
… Something about caching ... I don't know what this means exactly.

Manu Sporny: I think this person is saying that the HTTP headers for the credentials/v1 context are wrong. Because of the way it's set, it always expires which forces implementations to always go to the Web.
… They can't cache -- and they shouldn't be going out to the Web at all for that context or the v2 one -- but we should make it do the right thing.

Brent Zundel: Assigned to Ivan.

Ivan Herman: I was assigned because all this is happening via http access files which only I can change. But I have no idea what to change it to, so I need input.

Brent Zundel: If folks have clear and concise inputs?

Manu Sporny: Cache time should be set to three months.

Ivan Herman: How do I do that in htaccess?

Manu Sporny: Ping me and we'll figure it out together.

Ivan Herman: Ok.

Brent Zundel: And we are done with the call today.
… The editors and chair and team contact have explored the possibility of a F2F meeting this spring and we're not feeling it necessary, but if you feel differently, please contact us.
… There will be other VC-related conversations at other conferences as well. Thanks for scribing, Dave!

Dave Longley: welcome!

---

[iherman]

Based on the Apache expire module settings, what seems doable is to add the following statement into the .htaccess file:

ExpiresByType application/ld+json "access plus 1 month"

(There is no statement to set the expiration for a specific file. Alas!)

However, the same .htaccess file controls other redirections, namely those that access the vocabulary files, currently redirected to https://w3c.github.io/vc-data-model/vocab/credentials/v2/vocabulary.jsonld. On long term, that is all right, but I do not know whether this expiration would create problems while the vocabulary is still in development. Also, if we put this expiration date of a month against the jsonld, we should also do the same for the other vocabulary files (html, ttl, svg). Finally, we should also do the same for /ns/credential/.htaccess which controls the v2 version of the context file and (still to be done) the vocabulary for the bitstrings. I am not sure if this is fine at this point when we are still under development of all these.

Proposal: postpone this change until we publish our Recs. At that point the vocabulary files will have to be collected on W3C date space for finalization, and we can look at the policy altogether instead of making such punctual changes.

@msporny @davidlehn @brentzundel @TallTed WDYT?

[iherman]

The issue was discussed in a meeting on 2024-02-28

• no resolutions were taken

View the transcript

3.3. expires header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: Expires header for HTTP is in the past...

Ivan Herman: I looked at that. And I made a relatively longer comment on Jan 25.

Brent Zundel: See ivan's comment.

Ivan Herman: Essentially what happens is that, if we solve it now to change the .htaccess the way it should be, it would put the same expires settings to our context files as well. Simply because, the way I found it, you can't put these access things on an individual file, just different types.
… I can't put it on a single file.
… This change can be done, but my proposal is to not do it now during development but we should flag to do it when we go to PR or REC when freezing the content isn't a problem anymore.

Brent Zundel: So we can label this as before PR.

Ivan Herman: Or before REC even.
… There will be a point, actually, and we'll have to come back to this, where some of the files, which are currently on github should be moved to W3C space to be secure by all the backup features, etc.
… That has to be done at some point in the future, that's also related, so for the time being we should not touch all this in my view.

Brent Zundel: Proposal is not to do anything, sounds like Ivan has a good view for the path forward.
… Any comments?

[iherman]

The issue was discussed in a meeting on 2024-03-06

• no resolutions were taken

View the transcript

2.6. expires header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: 1239...did we decide about this one? ivan ?

Ivan Herman: I proposed we delay this one.
… the transcript of the meeting is inconclusive.

Brent Zundel: I think this one's OK to ignore for now.
… anyone object?