Implement VRP Portable Attestations

This guide describes how a host-owned domain can publish VRP Portable Attestations v0.1 without relying on HemmaBo, a central registry, a marketplace, an OTA, a booking intermediary, or a trust scoring service.

Portable attestations do not replace core VRP offer verification. A fresh signed offer is still required before an agent may quote availability, exact price, or a direct booking URL.

Minimum Publishing Profile

1. Publish a did:web DID document for the host domain.
2. Include an Ed25519 verification method for attestation JWS verification.
3. Use a kid controlled by the host-domain DID, such as did:web:example-host.invalid#attestations-ed25519-2026-05.
4. Sign credentials as compact JWS with typ: "vc+jwt" and alg: "EdDSA".
5. Include the W3C VC v2 context and the VRP context in the JWS payload.
6. Use iat for JWS signing time, and validFrom / validUntil for credential validity.
7. Do not include proof, signature, or issuedAt in the credential JSON.
8. Publish status only as VRPStatusListEntry unless a future version defines a full W3C Bitstring Status List profile.

DID Web Document

For issuer did:web:example-host.invalid, the DID document is published at:

https://example-host.invalid/.well-known/did.json

The DID document should include an attestation verification method that is controlled by the host-domain DID. The same host-domain trust root may also control a separate offer-signing key. The private keys do not need to be the same.

Example: did-web-document.v0.1.json.

Context Publishing

VRP terms are defined by the VRP context:

https://vacationrentalprotocol.com/contexts/v1

The repository copy is contexts/v1.jsonld. Deployments should serve the canonical extensionless URL above and may also serve /contexts/v1.jsonld as an equivalent copy. Both should return the same JSON-LD document.

Privacy Checklist

Do not publish guest reviews, guest outcomes, guest risk, guest scores, or guest history in v0.1.

VRPVerifiedStayCredential, if used, must stay privacy-minimized:

• use an opaque stayRef
• use verifiedOfferHash
• omit guest name, email, phone, guest DID, and payment details
• omit exact stay dates when they could identify the guest
• omit review text and guest outcome data

Guest-held credentials and reviews are deferred to a future v0.2 design with selective disclosure.