Resolution Steps
The user or an API sends a GET request or inserts a W3C did:web address in the input field and the API resolves the did:web accordingly.
Example Request Pipeline
To initiate the resolution pipeline, you can either pass the string via the interface or call the gateway directly via HTTP GET:
The resolver targets the host domain over safe HTTPS, requesting the standardized root W3C DID asset definition. Following the W3C did:web specification, the API targets either the .well-known path or a subfolder path determined by the DID structure. This step is successful if the API receives a valid JSON file.
Example valid JSON file
The core backend verifies the document structure and checks for the requested service condition flags. Depending on the parameters, different execution paths are pursued: If service=did-only is provided, the API returns the raw JSON payload immediately - see Step 2. For other conditions, the engine proceeds to the next step.
The engine queries the decentralized storage endpoints for secondary payloads. If the parameter service=com-reg is used, the system directly extracts and returns the matching commercial register service endpoint; otherwise, the workflow is aborted at this stage if no valid sub-resource endpoint can be routed.
Example valid service enpoint
For parameters such as none, service=dpp, or service=dpp-ui, the system evaluates the payload metadata (like the renderMethod) and returns an HTTP redirect response, passing the data markers to the client application for structured visual rendering.