Context URL doesn't resolve: https://w3id.org/identity/v1

[evanp]

You're sending objects with a context URL that doesn't resolve: https://w3id.org/identity/v1

I'm working around this by pre-caching the context. But you should make sure it resolves.

[evanp]

I reported this to perma-id/w3id.org#5918 . Let's see what we can do to get it fixed.

[davidlehn]

I see that https://w3id.org/identity/v1 shows up in a bunch of places in code here. Is that still used and needed? I'm pretty sure that hasn't resolved for maybe years? Is it worth fixing the context link? It was hosted as part of https://github.com/web-payments/web-payments.org. But most of that work evolved into newer better things. If that context is being used we could host it somewhere and update the redirect. But I suspect updating to modern VC, DI, DID, and related specs and contexts would be better.

[dahlia]

I looked into this a bit more.

https://w3id.org/identity/v1 is indeed broken on the Web right now, so I agree that emitting a dead context URL is a real interoperability problem.

At the same time, I don't think the practical answer for Fedify today is to drop Linked Data Signatures entirely. Fedify currently preloads identity/v1 internally, so its own JSON-LD processing is not what breaks here; the problem is that the dead URL is still emitted on the wire. Also, Mastodon still implements and verifies the old RsaSignature2017 Linked Data Signatures flow and, as far as I can tell, does not support FEP-8b32 (Object Integrity Proofs) yet (mastodon/mastodon#36475). So removing Linked Data Signatures outright would likely hurt compatibility with the biggest ActivityPub implementation.

So my current view is:

1. Keeping Linked Data Signatures support is still necessary for interoperability today.
2. Emitting a dead identity/v1 URL is still a bug and should be fixed.
3. The short-term fix should probably focus on reducing/removing identity/v1 from emitted payloads where possible without breaking Linked Data Signatures compatibility, or at least making this behavior configurable.
4. Longer-term, once Mastodon and other major implementations support FEP-8b32 (Object Integrity Proofs), Fedify can revisit whether Linked Data Signatures should remain a default path.

So I think this issue is valid, but the solution is probably “keep Linked Data Signatures, stop depending on a dead context URL on the wire” rather than “remove Linked Data Signatures entirely.”