ECZ-ID · Reciprocal Trust Infrastructure for the Machine Economy
ECZ-ID API Passport AWS Marketplace Getting Started and Technical Guide
From AWS Marketplace subscription to a canonical API ECZ-ID with independent Resolver proof.
Release 2026.10 · 16 October 2026
API Passport documents
In this document
- The whole journey in one view
- 1. Subscribe → 2. Set up your account → 3. registration-token handoff
- 4. identify the AWS customer → 5. activate the ECZ-ID acquisition flow
- 6. reuse or create account + Parent → 7. map ProductCode → 8. issue or reuse Passport
- 9. continue to Dashboard
- 10. re-check the API Passport
- Use Passport proof before connection or invocation
- What must never enter public proof or support channels
- Diagnose the failed stage before taking action
- Know when you are done
About this document
- Primary reader
- AWS Marketplace subscriber, cloud administrator, developer and customer administrator.
- Secondary reader
- Procurement, platform engineering, security operations and API owners.
- When to read this
- You have subscribed - or are about to subscribe - and want a working API Passport with minimal friction.
- Release
- 2026.10 · 16 October 2026
- What you will know after reading
- You can move from AWS acquisition through TrustOps to one canonical API Passport, Dashboard control and Resolver verification.
- What this document does not establish
- This guide does not make AWS identity the ECZ-ID authority root or replace API authentication, authorization or runtime controls.
NextComplete the acquisition, then use the API Technical Reference to integrate Passport proof into your API/service workflow.
START HERE
The whole journey in one view
The API Passport is permanently free. Subscribe in AWS, complete the account handoff, then verify the canonical API ECZ-ID in Resolver.
AWS MARKETPLACE ACQUISITION
Activate an API Passport through AWS Marketplace
Provider acquisition is separated from the canonical ECZ-ID identity, control and proof system.
AWS Marketplace
provider acquisition layer
- then
ECZ-ID canonical system
acquisition → activation → control → proof
- then
Dashboard
authenticated control
- then
Resolver
public read-only proof
Step 1: Subscribe at $0
API Passport permanently free
Step 2: Set up your account
continue to ECZ-ID
Step 3: Registration token
sensitive handoff never share
Step 4: AWS-native adapter
ResolveCustomer AWS customer
Step 5: TrustOps
acquisition + activation
Step 6: Account + Parent
reuse where appropriate
Step 7: ProductCode mapping
maps to API family
Step 8: Issue / reuse API Passport
canonical identity
SUCCESS CONDITION The intended API/service interface has one canonical API ECZ-ID, visible in Dashboard and independently re-checkable in Resolver.
AWS ROLE
Acquisition/provider context and customer handoff.
ECZ-ID ROLE
Canonical identity, activation, control and proof.
STEP-BY-STEP ACQUISITION
1. Subscribe → 2. Set up your account → 3. registration-token handoff
AWS Marketplace provides the acquisition context. The registration token is sensitive and must never be copied into public documentation, screenshots or support channels.
1 · SUBSCRIBE AT $0
Select the ECZ-ID API Passport listing and subscribe. There is no ECZ-ID software charge for the Passport.
2 · SET UP YOUR ACCOUNT
Use the Marketplace setup action to continue into the ECZ-ID fulfillment path.
3 · AWS REGISTRATION TOKEN AWS passes a registration token to the fulfillment endpoint. Treat it as sensitive operational input: do not paste it into chat, email, tickets, screenshots or public documentation.
EXPECTED RESULT
The customer handoff reaches the ECZ-ID AWS-native adapter.
IF IT FAILS
Record the visible error and occurrence time. Do not expose the token.
RESOLVECUSTOMER AND TRUSTOPS
4. identify the AWS customer → 5. activate the ECZ-ID acquisition flow
The AWS-native adapter resolves the Marketplace customer and hands acquisition into TrustOps.
AWS-NATIVE ADAPTER
Uses the appropriate Marketplace integration to ResolveCustomer and associate the acquisition with the ECZ-ID flow.
TRUSTOPS
Processes acquisition, applies the supported entitlement/activation logic and orchestrates the lifecycle handoff.
ARCHITECTURE LAW AWS customer identity is acquisition/provider context. It does not become the canonical ECZ-ID identity authority.
Fulfillment endpoint
https://trustops.ecocitizenz.com/aws/marketplace/fulfillDO NOT RETRY BY CREATING NEW IDENTITIES If acquisition fails, diagnose the failed stage. Repeated retries should not be used as a workaround for account, Parent or Passport issues.
ACCOUNT, PARENT AND PASSPORT REUSE
6. reuse or create account + Parent → 7. map ProductCode → 8. issue or reuse Passport
The target outcome is one canonical identity for the intended API/service interface, not a new Passport for every subscription click.
AWS MARKETPLACE ACQUISITION
Activate an API Passport through AWS Marketplace
Provider acquisition is separated from the canonical ECZ-ID identity, control and proof system.
AWS Marketplace
provider acquisition layer
- then
ECZ-ID canonical system
acquisition → activation → control → proof
- then
Dashboard
authenticated control
- then
Resolver
public read-only proof
Step 1: Subscribe at $0
API Passport permanently free
Step 2: Set up your account
continue to ECZ-ID
Step 3: Registration token
sensitive handoff never share
Step 4: AWS-native adapter
ResolveCustomer AWS customer
Step 5: TrustOps
acquisition + activation
Step 6: Account + Parent
reuse where appropriate
Step 7: ProductCode mapping
maps to API family
Step 8: Issue / reuse API Passport
canonical identity
REUSE FIRST
Where supported, reuse the existing EcoCitizenz account and Parent relationship.
ISSUE OR REUSE
Map the AWS ProductCode to the API Passport family and issue a new API ECZ-ID only when the logical object legitimately needs one.
DUPLICATE PREVENTION A new AWS subscription event is not, by itself, a reason to mint another canonical API identity.
FIRST CUSTOMER CONTROL
9. continue to Dashboard
Dashboard is the authenticated customer control plane. Resolver is the public proof surface.
DASHBOARD
Use the authenticated control plane to inspect permitted estate actions, the API Passport, relationships, products/entitlements, evidence and sharing surfaces available to your account.
RESOLVER
Use the public, read-only proof surface to inspect what a counterparty can independently re-check.
DO NOT CONFUSE THE TWO Dashboard can change permitted customer state; Resolver cannot. Resolver proves what is published; it is not the control plane.
FIRST CHECK IN DASHBOARD
Confirm the intended API Passport exists and corresponds to the correct logical interface.
THEN VERIFY PUBLICLY
Resolve the ECZ-ID and confirm the family/object, organisation context, state and supported bindings/evidence.
FIRST RESOLVER VERIFICATION
10. re-check the API Passport
A successful AWS acquisition is not complete from the customer perspective until the API ECZ-ID can be independently resolved and interpreted correctly.
RESOLVER RE-CHECK
Turn a presented ECZ-ID into a bounded decision input
Resolve the current public record, inspect only what is present, and fail safely when required proof is missing.
Consumer
receives or discovers an API ECZ-ID
- then
ECZ-ID Resolver
public · read-only · re-checkable GET /api/p/{ecz_id}.json
- then
Identity + family
Is this the API object expected?
- then
Organisation
Who claims responsibility?
- then
Bindings
Endpoint / description / service refs
- then
State
Environment / version / lifecycle
- then
Evidence
What source, scope and freshness?
- then
Authority context
What is supported for this decision?
If required proof is present and fresh → evaluate policy / proceed
If absent, stale or mismatched → challenge, deny or re-resolve
HUMAN VERIFICATION
Open the official Resolver and inspect the API ECZ-ID, family/object, organisation, state, bindings and evidence actually present.
MACHINE VERIFICATION
Use the machine-readable Resolver route and fail safely when required fields or evidence are absent.
GET https://api.ecocitizenz.com/api/p/{ecz_id}.jsonCALL SAFELY
Use Passport proof before connection or invocation
The Passport helps answer “is this the API/service interface I intended, and what current context supports that identity?” It does not answer every security question by itself.
PRE-CALL VERIFICATION
Verify identity and context before an API call
Use Passport proof as one input; keep API authentication and runtime authorization separate.
Step 1: Obtain API ECZ-ID
from documentation, integration or counterpart
Step 2: Resolve
confirm family/object and organisation context
Step 3: Inspect bindings
base URL, gateway, OpenAPI / description
Step 4: Check freshness
state, version, evidence and lifecycle
Step 5: Evaluate action policy
what authority/context does this action require?
Step 6: Authenticate separately
API key, OAuth, mTLS or supported method
Step 7: Call or fail safely
proceed only when policy is satisfied
Boundary: API identity and proof do not replace API authentication or authorization. If required proof is absent, stale or mismatched, challenge, deny or re-resolve according to policy.
SEPARATE CONTROL Authenticate to the API using its supported credential/runtime mechanism. Evaluate authorization for the specific operation separately from Passport identity.
PASSPORT INPUT
Identity · responsibility · endpoint/description bindings · state · evidence.
RUNTIME CONTROL
Authentication · authorization · gateway policy · application security.
SECURITY AND SECRET HANDLING
What must never enter public proof or support channels
AWS registration tokens and API credentials are operational secrets. The Passport is designed to publish bounded proof, not secrets.
NEVER SEND OR PUBLISH
- AWS Marketplace registration tokens
- passwords
- API keys / OAuth tokens
- private keys or certificates
- secrets from gateway/runtime configuration
SAFE SUPPORT CONTEXT
- AWS account context
- ECZ-ID / Passport ID if available
- failed stage
- visible error
- occurrence time
PUBLIC PROOF RULE Resolver should expose only the bounded public record. Never use evidence fields, support tickets or screenshots as a place to store credentials.
TROUBLESHOOTING
Diagnose the failed stage before taking action
The fastest recovery path is to identify where the journey stopped, preserve the canonical identity and avoid retries that create ambiguity.
SUBSCRIBE UNAVAILABLE
Confirm you can see the Limited product during testing, or that the listing is Public for general buyers.
SET UP YOUR ACCOUNT FAILS
Record visible error + time. Do not expose the registration token.
RESOLVECUSTOMER / ACTIVATION FAILS
Contact support with AWS context and failed stage; do not create duplicate identities.
EXISTING ACCOUNT NOT RECOGNISED
Use the supported existing-account path rather than intentionally creating another account/Parent.
RESOLVER MISSING EXPECTED PASSPORT
Confirm acquisition completed, then verify the ECZ-ID and distinguish issuance delay/failure from a copied-ID error.
ENDPOINT / API MISMATCH
Do not “fix” by minting another identity; verify bindings and the intended logical API first.
60-SECOND COMPLETION CHECK
Know when you are done
Use this checklist before treating the AWS acquisition as complete.
Subscribed at $0
Set up your account completed
AWS handoff reached TrustOps
Existing account/Parent reused or correctly created
ProductCode mapped to API Passport family
Canonical API Passport issued or reused
Dashboard shows the intended API identity
Resolver independently returns the Passport
No secrets were copied into public/support channels
NEXT Use the API Passport Technical Reference to integrate Resolver proof into your API/service workflow.
Download and support
This page is the HTML edition of ECZ-ID API Passport - AWS Marketplace Getting Started and Technical Guide, release 2026.10. The PDF is the designed offline copy.
Permanent route: https://developers.ecocitizenz.com/passports/api/aws-getting-started/