Monthly Archives: March 2026

March 21, 2026 · 12:06 am

PowerShell Android App (client-server)

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0 DIDLibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Features

  • Command completion (real-time)
  • PowerShell syntax highlighting (high-fidelity)
  • Fast responses
  • Runs on Android (tested on a Google Pixel 9)

Issues

  • Format verb output is not recognized properly.

Leave a comment

Filed under Uncategorized

March 17, 2026 · 1:46 pm

DID7: Authority-Scoped Decentralized Identifier Scheme

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Michael Herman
Chief Digital Officer
Web 7.0 Foundation

Abstract

This document defines the “did7” URI scheme, an authority-scoped decentralized identifier format. DID7 introduces an optional authority component and a two-stage resolution process, while remaining fully compatible with the W3C Decentralized Identifiers (DIDs) v1.0 specification (DID Core).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79 (https://datatracker.ietf.org/doc/html/draft-herman-did7-identifier-00)

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on 18 September 2026.

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.▲

Table of Contents

1. Introduction

The W3C Decentralized Identifiers (DIDs) specification [DID-CORE] defines method-based identifiers without a global namespace. DID7 introduces an optional authority layer, enabling namespace partitioning, governance domains, and scalable resolution infrastructure while remaining compatible with DID Core.

2. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

DID Document:As defined in [DID-CORE].

Authority:A namespace controller that defines resolver endpoints and governance rules for a set of DID7 identifiers.

Method:A named DID method as defined in [DID-CORE].

3. DID7 Syntax

3.1. General Form

did7:[//<authority-name>/]<method>:<method-specific-id>

3.2. ABNF

The following ABNF [RFC5234] defines the DID7 URI syntax. The unreserved and pct-encoded rules are imported from [RFC3986] Section 2.3. The ALPHA, DIGIT, and HEXDIG rules are imported from [RFC5234] Appendix B.

did7-uri       = "did7:" [ authority ] method-name ":" [ submethod-name "/" ] method-id

authority      = "//" authority-name "/"

authority-name = name
method-name    = name
submethod-name = name
name           = 1*( ALPHA / DIGIT / "." / "-" )

method-id      = 1*( unreserved / pct-encoded / "." / "-" / "_" )

pct-encoded    = "%" HEXDIG HEXDIG

Note: The colon (“:”) character is intentionally excluded from method-id to avoid ambiguity with the method delimiter. Colons within method-specific identifiers MUST be percent-encoded.

3.3. Default Authority

If the authority component is absent, it MUST be treated as equivalent to the authority “w3.org”.

3.4. Expansion Rule

A DID7 URI without an explicit authority component expands as follows:

did7:<method>:<id>  ->  did7://w3.org/<method>:<id>

4. Authority Model

Authorities define resolution namespaces for DID7 identifiers. An authority:

  • MAY define resolver endpoints, governance models, and supported methods.
  • MUST NOT alter DID Document semantics as defined in [DID-CORE].
  • Introduces an optional trust boundary for identifiers in its namespace.

5. Resolution Model

5.1. Stage 1: Authority Resolution

As a convenience, resolvers MAY perform DNS-based discovery of the resolver endpoint for an authority using a DNS TXT record of the form:

_did7.<authority-domain> IN TXT \
    "resolver=did7://example.com/resolvers:authority"

DNS responses used for authority resolution SHOULD be validated using DNSSEC.

Any verifiable data registry technology MAY be used for discovery of the resolver endpoint for an authority. Different authorities MAY have different registries.

5.2. Stage 2: Method Resolution

The method-specific identifier is resolved using the endpoint discovered in Stage 1. The resulting DID Document MUST conform to [DID-CORE].

6. Compatibility

6.1. One-Way Mapping

Any W3C DID can be mapped to a DID7 URI as follows:

did:<method>:<id>  ->  did7://w3.org/<method>:<id>

This mapping is one-way. There is no general inverse mapping from DID7 to W3C DID.

6.2. Non-Equivalence

Implementations MUST NOT assume equivalence between “did” and “did7” identifiers, even when the method and method-specific identifier components are identical.

7. Security Considerations

The following security considerations apply to implementations of this specification:

  • Authorities introduce a trust surface. The integrity of resolver endpoints MUST be verified before use. Implementations SHOULD use certificate-based authentication when contacting resolver endpoints.
  • DNS responses used for authority resolution SHOULD be validated using DNSSEC to prevent DNS spoofing attacks.
  • Resolver endpoints SHOULD use HTTPS (TLS) to protect data in transit. Endpoints using plain HTTP MUST NOT be used in production deployments.
  • Cryptographic verification of DID Documents MUST follow the procedures defined in [DID-CORE].
  • Implementations MUST NOT accept resolver endpoints that redirect to third-party domains not associated with the declared authority.

8. IANA Considerations

This document requests registration of the URI scheme “did7” in the “Uniform Resource Identifier (URI) Schemes” registry maintained by IANA, in accordance with [RFC7595].

URI scheme name: did7

Status: Provisional

URI scheme syntax: See Section 3.2 of this document.

URI scheme semantics: The “did7” URI scheme identifies authority-scoped decentralized identifiers. Resolution proceeds in two stages: authority discovery via DNS, followed by method-specific DID resolution. The resulting resource is a DID Document as defined in [DID-CORE].

Encoding considerations: The “did7” URI scheme uses only ASCII characters as defined by the ABNF in Section 3.2.

Non-ASCII characters in the method-specific identifier component MUST be percent-encoded per [RFC3986].

Applications/protocols that use this URI scheme: Applications implementing decentralized identity, verifiable credentials, or self-sovereign identity frameworks that require authority-scoped namespace governance.

Interoperability considerations:DID7 URIs are not directly interchangeable with W3C DID URIs. See Section 6 for the one-way mapping from W3C DID to DID7.

Security considerations:See Section 7 of this document.

9. Examples

The following are valid DID7 URIs:

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc
did7://acbd1234/custom:xyz_123

10. Conformance (Non-Normative)

The following URIs are valid under the syntax defined in Section 3.2:

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc.def

The following URIs are invalid and MUST be rejected by conforming implementations:

did7:///          (empty authority-name and empty method)
did7://w3.org/    (empty method and method-id)
did7:             (missing method and method-id)

11. References

11.1. Normative References

[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5234]Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC7595]Thaler, D., Ed., Hansen, T., and T. Hardie, “Guidelines and Registration Procedures for URI Schemes”, BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/rfc/rfc7595>.

[RFC8174]Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[DID-CORE]World Wide Web Consortium (W3C), “Decentralized Identifiers (DIDs) v1.0”, W3C Recommendation, July 2022, <https://www.w3.org/TR/did-core/>.

Author’s Address

Michael Herman
Chief Digital Officer
Web 7.0 Foundation
Email: mwherman@gmail.com

Leave a comment

Filed under Uncategorized

March 17, 2026 · 9:38 am

SDO: Authority-Scoped Decentralized Identifiers (DID7)

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Version: 0.1
Status: Draft
Editor: Michael Herman, Chief Digital Officer, Web 7.0 Foundation
Intended Audience: Standards bodies, implementers, protocol designers
SDO: Web 7.0 Foundation
Also Known As: did://ietf/docs:draft-herman-did7-identifier-01

Abstract

This specification defines the did7 URI scheme, an authority-scoped decentralized identifier format that extends the conceptual model of Decentralized Identifiers (DIDs). DID7 introduces an explicit authority layer above DID methods and defines a two-stage resolution process. DID7 is designed to be compatible with the DID Core data model while enabling forward-compatible namespace routing and governance flexibility.

1. Introduction

The Decentralized Identifier (DID) architecture defined by DID Core provides a method-based identifier system without a global authority namespace.

This specification introduces:

  • A new URI scheme: did7
  • An authority-scoped identifier structure
  • A two-stage resolution model
  • A forward-compatible namespace design

DID7 is intended to:

  • Enable explicit namespace partitioning
  • Support multiple governance domains
  • Provide a top-level resolution entry point

2. Conformance

The key words MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119.

This specification:

  • Normatively references DID Core for DID Document structure and semantics
  • Does not modify DID Documents
  • Overrides identifier syntax and resolution entry point only

3. DID7 Identifier Syntax

3.1 Primary Form

did7://<authority>/<method>:<method-specific-id>

3.2 Shorthand Form

did7:<method>:<method-specific-id>

3.3 Expansion Rule (Normative)

did7:<method>:<id>
→ did7://w3.org/<method>:<id>

4. ABNF Grammar

did7-uri        = "did7://" authority "/" method ":" method-id
did7-short      = "did7:" method ":" method-id
authority       = 1*( ALPHA / DIGIT / "-" )
method          = 1*( ALPHA / DIGIT )
method-id       = 1*( unreserved / ":" / "." / "-" / "_" )

5. Authority Model

5.1 Definition

An authority is a namespace identifier that scopes DID methods and resolution behavior.

Examples:

  • w3.org
  • dif
  • ietf
  • toip
  • web7
  • acbd1234

5.2 Authority Semantics

This specification defines the authority as a:

Resolution control namespace

Authorities MAY:

  • Define resolver endpoints
  • Define method availability
  • Establish governance or trust frameworks

Authorities MUST NOT:

  • Alter the internal semantics of DID Documents defined by DID Core

5.3 Default Authority

If omitted via shorthand:

did7:<method>:<id>

The authority MUST default to:

w3.org

6. Resolution Model

DID7 defines a two-stage resolution process.

6.1 Stage 1: Authority Resolution

Input:

did7://<authority>/<method>:<id>

Process:

  • Resolve <authority> to resolver metadata

Output:

  • Resolver endpoint(s)
  • Supported methods
  • Resolution policies (optional)

6.2 Stage 2: Method Resolution

Input:

<method>:<method-specific-id>

Process:

  • Invoke method-specific resolution

Output:

  • A DID Document conforming to DID Core

6.3 Resolution Flow Example

did7://w3.org/example:123
        ↓
[DID7 Resolver]
        ↓
Authority: w3.org
        ↓
Delegates to example method
        ↓
Returns DID Document

7. Compatibility with DID Core

7.1 One-Way Mapping (Normative)

Allowed:

did:<method>:<id>
→ did7://w3.org/<method>:<id>

7.2 Non-Equivalence (Normative)

did7://w3.org/<method>:<id>
≠ did:<method>:<id>

7.3 Implications

  • DID7 is a strict superset namespace
  • Not all DID7 identifiers are valid DIDs
  • Equivalence MUST NOT be assumed

8. Resolver Discovery

This specification does not mandate a single discovery mechanism.

Authorities MAY define resolver discovery via:

  • Static configuration
  • HTTPS well-known endpoints
  • DNS-based discovery (e.g., TXT or SRV records)
  • Decentralized registries

9. Security Considerations

9.1 Authority Trust

  • Authorities introduce a potential trust layer
  • Implementers MUST evaluate authority trustworthiness

9.2 Namespace Collisions

  • Authorities are not globally enforced
  • Collisions MAY occur without coordination

9.3 Resolution Integrity

  • Resolver endpoints SHOULD support secure transport (e.g., HTTPS)
  • Integrity of resolution responses MUST be verifiable via DID Document cryptography

10. IANA Considerations (Optional)

The did7 URI scheme MAY be registered with IANA.

Required fields:

  • Scheme name: did7
  • Status: provisional or permanent
  • Specification: this document

11. Design Rationale (Non-Normative)

DID Core omits a global namespace layer. DID7 introduces:

  • Explicit authority routing (similar to DNS)
  • Separation of governance domains
  • Forward-compatible extensibility

This enables:

  • Federation models
  • Multi-organization ecosystems
  • Layered trust frameworks

12. Comparison to DID Core

FeatureDID CoreDID7
Schemedid:did7:
NamespaceMethod-onlyAuthority + Method
ResolutionMethod-specificAuthority → Method
Trust LayerImplicitExplicit (optional)

13. Implementation Notes (Non-Normative)

A minimal DID7 resolver can be implemented as:

  1. Parse DID7 URI
  2. Expand shorthand
  3. Lookup authority configuration
  4. Dispatch to method resolver
  5. Return DID Document

What you now have (verification-style)

Well-supported

  • Clean separation from DID Core
  • Proper layering model
  • Spec is publishable and reviewable
  • ABNF + normative language included

New / experimental (but coherent)

  • Authority as a first-class routing layer
  • Two-stage resolution model
  • One-way compatibility rule

Open design decisions (you may want to refine next)

  • Canonical authority registry (or none)
  • Resolver discovery standard (DNS vs HTTPS)
  • Trust semantics of authority (light vs strong governance)

Leave a comment

Filed under Uncategorized

Tagged as , , , ,

March 17, 2026 · 9:26 am

SDO: Authority-Scoped Decentralized Identifiers (DID7)

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Version: 0.1
Status: W3C-style Working Draft / Informational
Editor: Michael Herman (Chief Digital Officer, Web 7.0 Foundation)
Intended Audience: Standards bodies, implementers, protocol designers
SDO: Web 7.0 Foundation
Also Known As: did://ietf/docs:draft-herman-did7-identifier-01

Abstract

This document defines the did7 URI scheme, an authority-scoped DID format. DID7 adds:

  • An optional authority component
  • Two-stage resolution (authority → method)
  • Forward-compatible namespace expansion

The specification is fully compatible with the W3C DID Core data model [DID-CORE].

NOTE: This version mirrors W3C specification formatting conventions, including:

  • Clear separation of normative vs non-normative content
  • ABNF blocks with examples
  • In-line references to DID Core
  • Sectioning like W3C DID Core Recommendation

1 Introduction

The DID Core specification [DID-CORE] defines method-based identifiers without a global namespace. DID7 introduces an optional authority layer, allowing namespace partitioning and federation while remaining compatible with DID Core.

DID7 goals:

  • Namespace partitioning
  • Governance flexibility
  • Forward-compatible routing

2 Terminology

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are interpreted as described in [RFC2119][RFC8174].

  • DID Document: As defined in [DID-CORE].
  • Authority: A namespace identifier controlling resolution behavior.

3 DID7 Syntax

3.1 URI Form

did7:[//<authority-name>/]<method>:<method-specific-id>

3.2 ABNF

did7-uri        = "did7:" [ authority ] method ":" method-id
authority       = "//" authority-name "/"
authority-name  = 1*( ALPHA / DIGIT / "-" )
method          = 1*( ALPHA / DIGIT )
method-id       = 1*( unreserved / ":" / "." / "-" / "_" )

3.3 Default Authority

If authority is absent, it MUST default to w3.org.

3.4 Expansion Rule

did7:<method>:<id> → did7://w3.org/<method>:<id>

4 Authority Model

Authorities define resolution namespaces.

  • MAY define resolver endpoints, governance, and supported methods
  • MUST NOT alter DID Document semantics [DID-CORE]

Note: Authorities introduce optional trust boundaries.

5 Resolution Model

5.1 Stage 1: Authority Resolution

  • Implementations SHOULD use DNS TXT or SRV records:
_did7.<authority-domain> TXT "resolver=https://resolver.example.com"

5.2 Stage 2: Method Resolution

  • Method resolver returns a DID Document conforming to [DID-CORE].

6 Compatibility with DID

6.1 One-Way Mapping

did:<method>:<id> → did7://w3.org/<method>:<id>

6.2 Non-Equivalence

  • did7 identifiers are not equivalent to DID Core identifiers.

7 Security Considerations

  • Authority introduces a trust surface; verify authority integrity
  • DNS responses SHOULD be validated using DNSSEC
  • Resolver endpoints SHOULD use HTTPS
  • DID Document integrity MUST follow cryptographic verification in [DID-CORE]

8 IANA Considerations

  • Register did7 URI scheme
  • Status: provisional
  • Reference: this document

9 Examples

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc
did7://acbd1234/custom:xyz_123

10 Conformance Testing (Non-Normative)

Valid

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc.def

Invalid

did7:///
did7://w3.org/
did7:

Note: Implementations MUST fail parsing invalid URIs.

11 References

Normative

[DID-CORE]
Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, 2022
https://www.w3.org/TR/did-core/

[RFC2119]
S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, 1997

[RFC8174]
B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, 2017

Non-Normative

Italicized explanations, rationale, and conformance examples are non-normative.

Leave a comment

Filed under Uncategorized

March 14, 2026 · 10:24 am

Web 7.0 DIDLibOS is a Decentralized, DID-native Polyglot Host Platform

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

A polyglot host is a software environment that can execute or embed multiple programming languages within the same process or platform.

Instead of being tied to one language runtime, the host provides infrastructure so different languages can run side-by-side and interact.

Core idea

Host Environment
     │
     ├─ Language Runtime A
     ├─ Language Runtime B
     ├─ Language Runtime C
     └─ Shared APIs / objects

The host provides:

  • memory management
  • object sharing
  • APIs
  • execution control

Each language plugs into that environment.

Example: PowerShell

PowerShell is a practical polyglot host because it can run or embed:

  • .NET languages (C#, F#)
  • JavaScript (via engines like )
  • Python (via )
  • legacy scripting via
  • external runtimes like or Python

PowerShell itself acts as the host orchestrating those runtimes.

Example: Modern polyglot notebook hosts

A well-known example is .NET Interactive which supports:

  • C#
  • F#
  • PowerShell
  • JavaScript
  • SQL

in the same notebook.

Another example is Jupyner Notebooks which runs different languages through kernels.

What makes something a polyglot host

A system qualifies if it supports at least some of these:

CapabilityDescription
Multiple runtimesDifferent languages execute in the same environment
Shared dataLanguages exchange objects or values
Embedded interpretersEngines loaded as libraries
Runtime orchestrationHost decides what runs where

Three common architectures

1. Embedded runtimes

Languages run inside the host process.

Example:

Host
 ├─ Python runtime
 ├─ JavaScript runtime
 └─ shared object model

Example platform:

2. External runtimes

Host launches interpreters as subprocesses.

Example:

Host
 ├─ node
 ├─ python
 └─ Rscript

PowerShell often uses this approach.

3. Plugin scripting engines

Languages implement a host interface.

Example:

Host
 ├─ VBScript engine
 ├─ JScript engine
 └─ PerlScript engine

This was the design of Windows Script Host.

Simple definition

A polyglot host is:

A runtime environment that allows multiple programming languages to run and interact within a single platform.

Why they exist

Polyglot hosts let developers:

  • use the best language for each task
  • reuse existing ecosystems
  • integrate tools without rewriting everything

Leave a comment

Filed under Uncategorized

Tagged as , , , ,

March 1, 2026 · 10:28 am

SDO: Web 7.0 DID Interface Definition Language (DIDIDL) 0.22 — Draft Specification

Create your own magic with Web 7.0™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Status: Draft
Version: 1.0
License: Apache 2.0
Editors: Michael Herman, Chief Digital Officer, Web 7.0 Foundation
SDO: Web 7.0 Foundation, Bindloss, Alberta, Canada

1. Abstract

DIDIDL defines a transport-neutral, message-type–centric capability description format for agents using using DIDComm.

DIDIDL enables agents to:

  • Publish typed tasks grouped under process capabilities
  • Describe request, response, and error schemas
  • Support machine-readable discovery
  • Enable client generation and validation

1.1 Key Concepts

  • APC Process Classification Framework (PCF)

  • Process Capability DID
    • did7://{authority}/{process-name}_{sedashver}:{capability-name}
  • Process Capability Task DID
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/{task-name}
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}
  • Process Capability Discovery
    • did7://{authority}/{process-name}/query-capabilities
    • did7://{authority}/{process-name}/disclose-capabilities
    • did7://{authority}/{process-name}_{semdashver}/query-capabilities
    • did7://{authority}/{process-name}_{semdashver}/disclose-capabilities
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/query-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/disclose-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/query-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/disclose-capability

2. Terminology

TermDefinition
AgentA DIDComm-enabled entity
Process Capability (Capability)A grouping of tasks representing a business or functional process
Process Capability Task (Task)A DIDComm message type representing a callable function
SchemaA JSON Schema definition conforming to JSON Schema
Process DIDIDL Document (DIDIDL Document)JSON object conforming to this specification

Normative keywords MUST, SHOULD, MAY follow RFC 2119.

3. Canonical DID Patterns

Process Capability Task DID PatternPatternExample
Process Capability DIDdid7://{authority}/{process-name}_{semdashver}/{capability-name}_{semdashver}did7://web7/user-onboarding_1-0:enrollment_1-0
Process Capability Task DIDdid7://{authority}/{process-name}_{semdashver}/{capability-name}_{semdashver}/{task-name}did7://web7/user-onboarding_1-0:enrollment_1-0/verify-email
Query/Disclose DID Messsage TypesPatternExample
Discovery Query Process Capabilitiesdid7://{authority}/{process-name}_{semdashver}/query-capabilitiesdid7://web7/user-onboarding_1-0/query-capabilities
Discovery Disclose Process Capabilitiesdid7://{authority}/{process-name}_{semdashver}/disclose-capabilitiesdid7://web7/user-onboarding_1-0/disclose-capabilities
Discovery Query Process Capability Tasksdid7://{authority}/{process-name}_{semdashver}/{capability-name}_{semdashver}/query-capabilitydid7://web7/user-onboarding_1-0/query-capability
Discovery Disclose Process Capability Tasksdid7://{authority}/{process-name}_{semdashver}/{capability-name}_{semdashver}/disclose-capabilitydid7://web7/user-onboarding_1-0:enrollment_1-0/disclose-capability

Web 7.0 DID Identifier/Message Type Syntax-Semantics Comparions

Web 7.0 Neuromorphic Agent Protocol Long-Term Memory (LTM) Model

4. DIDIDL Document Structure

4a. Process Capabilities

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [...],
  "schemas": {...}
}

All tasks MUST be nested under exactly one process capability.

4b. Process Capability Tasks

{
  "id": "did7://web7/user-onboarding_1-0:enrollment",
  "name": "User Onboarding-Enrollment",
  "version": "1.0",
  "description": "Handles user lifecycle initiation",
  "tasks": [
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
        {
      "type": "did7://web7/user-onboarding_1-0:enrollment_2-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/verify-email",
      "request": "#/schemas/VerifyEmailRequest",
      "response": "#/schemas/VerifyEmailResponse"
    }
  ]
}

Rules:

  • Process Capability DIDs MUST follow the pattern:
    • did7://{authority}/{process-name}_{semdashver}/{capability-name}
    • did7://{authority}/:{process-name}_{semdashver}/{capability-name}_{semdashver}
  • Task DIDs are capability-scoped:
    • did7://{authority}/:{process-name}_{semdashver}/{capability-name}/{task-name}
    • did7://{authority}/:{process-name}_{semdashver}/{capability-name}_{semdashver}/{task-name}
  • Each task MUST belong to exactly one capability

4c. Process Capability Task

{
  "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
  "request": "#/schemas/CreateUserRequest",
  "response": "#/schemas/UserDto",
  "errors": ["#/schemas/ValidationError"]
}

Rules:

  • Task DIDs MUST be unique within the agent
  • Versioning MUST be encoded in the DID
  • Request and response schemas MUST be referenced by JSON pointer

5. Discovery Protocol

5.1 Query Capabilities

Request

{
  "type": "did7://web7/user-onboarding_1-0/query-capabilities"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0/disclose-capabilities",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:userverification",
      "name": "User Verification",
      "version": "1.0",
      "description": "Handles user verification."
    },
    {
      "id": "did7://web7/credential-issuance_1-0/credentialissuance",
      "name": "Credential Issuance",
      "version": "1.0"
      "description": "Handles credential issuance."
    }
  ]
}

5.2 Query a Specific Capability

Request

{
"type": "did7://web7/user-onboarding_1-0:userverification/query-capability"
}
{
  "type": "did7://web7/user-onboarding_1-0:userverification_1-0/query-capability"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0:userverification/disclose-capability",
  "capability": {
    "id": "did7://web7/user-onboarding_1-0:userverification_1-0",
    "name": "User Verification",
    "version": "1.0",
    "tasks": [
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/create-user",
        "request": "#/schemas/CreateUserRequest",
        "response": "#/schemas/UserDto"
      },
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/verify-email",
        "request": "#/schemas/VerifyEmailRequest",
        "response": "#/schemas/VerifyEmailResponse"
      }
    ],
    "schemas": {...}
  }
}

6. Normative Requirements

  1. Each task MUST appear in exactly one process capability.
  2. Process Capability DIDs MUST be unique within the agent.
  3. Task DIDs are capability-scoped and MUST be unique.
  4. Union of all process capabilities MUST form a disjoint partition of tasks.
  5. Schemas included in capability disclosure MUST only include referenced schemas.
  6. DIDComm authentication MUST protect all DIDIDL exchanges.
  7. Version changes that introduce breaking schema modifications MUST increment the major version in the DID.

7. Example Complete DIDIDL Document

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:useronboarding",
      "name": "User Onboarding",
      "version": "1.0",
      "tasks": [
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_2-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/verify-email",
          "request": "#/schemas/VerifyEmailRequest",
          "response": "#/schemas/VerifyEmailResponse"
        }
      ]
    }
  ],
  "schemas": {
    "CreateUserRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "email": { "type": "string" }
      },
      "required": ["email"]
    },
    "VerifyEmailRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "token": { "type": "string" }
      },
      "required": ["token"]
    },
    "VerifyEmailResponse": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "success": { "type": "boolean" }
      },
      "required": ["success"]
    },
    "UserDto": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "email": { "type": "string" }
      },
      "required": ["id", "email"]
    }
  }
}

Appendix B – APQC Taxonomies

Process Categories and Individual Processes

Appendix C – PowerShell Cmdlet Naming Specifications

Appendix D – Web 7.0™ DID-based, Decentralized Library Operating System (DIDLibOS)

Leave a comment

Filed under Uncategorized

Tagged as , , , ,