Clarify key ownership verification for HTTP scheme issuer identifiers

[ottonomy]

If an issuer uses a HTTP identifier like https://example.com/issuers/abc123 and then a Data Integrity proof, how does a verifier confirm that the key identifier in the proof like https://example.com/issuers/abc123/key is actually a key owned by the issuer?

{
  "type": ["VerifiableCredential", "OpenBadgeCredential"], ...
  "issuer": "https://example.com/issuers/abc123",
  "proof": {
      "type": "DataIntegrityProof",
      "created": "2025-09-01T20:35:20Z",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z5tgU95feKnX9ezpD622pjGedtTS7hPp28nyPxDD2xg9aQhesna5zdR3HQXJ2sarC8o1tAcq5Nm2gN5EV7fTPPR5o",
      "verificationMethod": "https://example.com/issuers/abc123/key"
    }
}

The spec doesn't require a specific piece of data be returned from the issuer.id URL if it's an HTTPS URL. Do verifiers need to get key association information from an external source?

Some related reading:

• https://identity.foundation/well-known-did-configuration/ (spec link seems broken at the moment), but this is something some people do to link https IDs to DIDs. -- The verifier might just guess that there is a document posted at https://example.com/issuers/abc123/.well-known/did-configuration
• Controlled identifiers spec: https://w3c.github.io/cid/#data-model

[a-c-brown]

If an issuer uses a HTTP identifier like https://example.com/issuers/abc123 and then a Data Integrity proof, how does a verifier confirm that the key identifier in the proof like https://example.com/issuers/abc123/key is actually a key owned by the issuer?

{
  "type": ["VerifiableCredential", "OpenBadgeCredential"], ...
  "issuer": "https://example.com/issuers/abc123",
  "proof": {
      "type": "DataIntegrityProof",
      "created": "2025-09-01T20:35:20Z",
      "cryptosuite": "eddsa-rdfc-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "z5tgU95feKnX9ezpD622pjGedtTS7hPp28nyPxDD2xg9aQhesna5zdR3HQXJ2sarC8o1tAcq5Nm2gN5EV7fTPPR5o",
      "verificationMethod": "https://example.com/issuers/abc123/key"
    }
}

The spec doesn't require a specific piece of data be returned from the issuer.id URL if it's an HTTPS URL. Do verifiers need to get key association information from an external source?

Some related reading:

• https://identity.foundation/well-known-did-configuration/ (spec link seems broken at the moment), but this is something some people do to link https IDs to DIDs. -- The verifier might just guess that there is a document posted at https://example.com/issuers/abc123/.well-known/did-configuration
• Controlled identifiers spec: https://w3c.github.io/cid/#data-model

Are we taking Key Provenance here?

#548

https://docs.google.com/presentation/d/11JM0rNFA5Q2C36cS9_kWWuOlUQbrXCwot0V0Hsn9mog/edit?slide=id.g123ec04fd24_0_6#slide=id.g123ec04fd24_0_6

[ottonomy]

@a-c-brown yes, we're talking about key provenance. The original solution for linked data proof securing mechanisms assumed use of a DID rather than an HTTP identifier, and so there is a gap in the resolution process if HTTP is used directly.