identity.org.au

Illustrative integration · not a production API

From request to useful answer

Agree the claim and trust model first. Choose and test the production protocol before depending on an integration.

Example messages, not an available API

The JSON below is a discussion fixture, not an OpenID4VP or VEID wire format. It has no signature and cannot verify a person. The demo makes no network requests and does not implement credential issuance.

Where information moves

  1. Issuer → wallet. The issuer checks membership using its existing process, then issues a holder-bound credential. Source evidence follows the issuer's agreed retention policy.
  2. Service → wallet. An authenticated request names the service, purpose, requested claim, fresh challenge and retention notice.
  3. User → wallet. The user reviews and approves or declines. Different services require distinct decisions.
  4. Wallet → service. An approved presentation contains the necessary claim and verification material. Names, member numbers and source documents are excluded from this proposed workflow.
  5. Service → receipt. After validating issuer, holder, freshness and status, the service stores the agreed minimum result and request receipt.

The educational demo keeps its fictional credential and history in browser memory. It has no issuer connection, chain transaction or status service. Production placement of records, including any on-chain metadata, is a design decision requiring privacy review.

Illustrative request

{
  "demo_only": true,
  "profile": "illustrative-membership-v0.1",
  "request_id": "demo-request-1",
  "verifier": "example-workspace",
  "purpose": "Check eligibility for a member desk booking",
  "claim": "membership_active",
  "accepted_issuer": "example-membership-association",
  "fresh_challenge": "GENERATE_AND_BIND_IN_PRODUCTION",
  "retention": "AGREE_BEFORE_REAL_PILOT"
}

Illustrative accepted response

{
  "demo_only": true,
  "request_id": "demo-request-1",
  "outcome": "accepted",
  "disclosed": {
    "membership_active": true
  },
  "verification": "SIMULATED_NOT_CRYPTOGRAPHICALLY_VERIFIED"
}

A production verifier must never accept the demo_only fixture. “Accepted” in the demo is an educational outcome, not a signed verification result.

Normal outcomes your service needs to handle

  • Declined: no membership claim; provide a non-wallet route.
  • Expired or revoked: reject the credential and explain the issuer's renewal or correction route.
  • Unaccepted issuer: reject even if the signature is mathematically valid.
  • Missing credential: explain accepted issuers and alternatives.
  • Lost device: authenticate recovery and reissue where necessary; never skip holder checks.
  • Interrupted or replayed request: create a fresh request and bind it to the current session.
  • Withdrawn consent: block new sharing until a new decision; apply agreed retention to past receipts.

The production integration gate

Select a concrete credential format, issuer trust mechanism and status method. Evaluate OpenID4VCI for issuance and OpenID4VP for presentation against the target ecosystem. Test between independent implementations and review replay prevention, key rotation, compromise and recovery.

Selective disclosure and verifier-to-verifier unlinkability are different properties. Public identifiers, timestamps, receipts and status lookups can still create correlation. A production privacy review must trace them.

No interoperability, accredited service or production endpoint is claimed here. Try the local demo or discuss a pilot.