did:web identifiers complement the existing SourcedIds by providing a verifiable, decentralized identifier that can easily encapsulate and reference upstream student IDs from systems like Student Information Systems (SIS). This ensures that while local sessions between systems may use localized IDs, the overarching identity remains consistent and verifiable across the ecosystem.

The creation of did:web identifiers utilizes an entity's domain name, offering a straightforward method to generate unique, resolvable identifiers. This process not only supports the decentralization of identity management but also enhances the ease of integration with existing web infrastructure, maintaining a clear link to the entity's control and authority over the identifier.

Accessing a did:web identifier leads to a DID document hosted on the entity's domain. This document provides detailed instructions on interacting with and verifying the DID subject, including authentication services, public keys, and service endpoints. This mechanism supports a robust framework for identity verification, essential for secure interactions within the ed-tech sector.

Incorporating did:web into 1EdTech specifications enhances the ability to maintain and verify digital identities across various applications, from learner IDs and course IDs to resource IDs. This adaptability showcases did:web's utility in supporting a wide range of educational technology scenarios, reinforcing the ecosystem's interoperability and security.

By leveraging did:web, the 1EdTech ecosystem gains enhanced interoperability, allowing for seamless data exchange and validation across different systems and platforms. The security and control over digital identities are significantly improved, providing a more reliable and user-centric approach to identity management. This shift not only supports the integrity and privacy of educational data but also fosters a more connected and efficient educational technology landscape.

In summary, the integration of did:web within the 1EdTech specifications introduces a forward-looking approach to digital identity management. By enhancing existing identifier systems with the capabilities of did:web, the ed-tech sector can achieve greater interoperability, security, and control, paving the way for more innovative and user-centric educational experiences.

The canonicalId property denotes the primary, authoritative DID for a subject when multiple DIDs refer to the same entity. This is particularly useful in scenarios where a DID subject may have different DIDs issued by various systems or for different purposes, but there is a need to establish one as the primary reference point.

The equivalentId property indicates that two or more DIDs reference the same subject. Unlike canonicalId, which establishes a hierarchy, equivalentId denotes a peer relationship among DIDs, implying that they are interchangeable in the context of the subject's identity.

The AlsoKnownAs property links a DID subject with other URIs where the subject is represented or known. This is broader than just linking different DIDs and can include various types of identifiers or profiles across different platforms.

AlsoKnownAs is especially useful for the use cases outlined for UniformIDs because application directories may create identifiers for listed applications and provide an optional capability for application vendors to associate their identifiers.

DID documents are to be treated as public resources. It is imperative that they do not contain sensitive or personally identifiable information (PII) to safeguard privacy and comply with data protection regulations.

Each DID service must have a uniquely registered name. This allows validators to selectively implement and interact with only those services that are relevant to their operational needs, enhancing system efficiency and specificity.

Any DID service associated with an identifier should be clearly listed in the returned DID document, including the service endpoint. Validators interested in a specific DID service must identify the service by its name and interact through the designated service endpoint, ensuring clarity and precision in service utilization.

The service itself can define the data structure returned by each DID service. This flexibility allows services to tailor their data formats to best suit the needs of their specific use cases within the ed-tech ecosystem.

DID services are primarily intended as discovery mechanisms within the ed-tech sector. They should be regarded as providers of public information, facilitating the easy identification and verification of educational resources, applications, and entities.

While DID services can include information relevant to the secure exchange of more sensitive data (e.g., through authenticated protocols like OIDC Discovery endpoints), such functionalities extend beyond the core use cases envisioned for UniformID. These aspects are acknowledged but considered outside the immediate scope of these guiding principles.

DID service endpoints are designed to facilitate straightforward discovery without necessitating authorization or authentication processes. This approach ensures that these endpoints serve as accessible gateways for identifying and obtaining basic information related to DID services. However, it is recognized that subsequent interactions or access to more detailed or sensitive information may require an authorized and authenticated pathway. Each DID service is, therefore, empowered to specify its own mechanisms for secure, authenticated access beyond the initial discovery phase, tailored to its specific requirements and use cases. This principle ensures the balance between the openness necessary for discovery and the security required for sensitive data exchanges.

1EdTech prefers using GET requests for DID service endpoints, emphasizing simplicity and efficiency for data retrieval. Though the DID core specification does not mandate a specific HTTP method, GET requests align with our focus on accessible discovery mechanisms within the ecosystem.

Paths and query strings for interacting with DID services are declared in each DID document, so they can be unique per Identifier if required. This enables the inclusion of unique identifiers as parameters for specific applications, enhancing precision and utility in accessing DID services.

The specification for each DID service will not mandate the path structure for each service because each implementation can define this according to their unique requirements.

HTTPS is recommended for all interactions with DID services to ensure secure data transmission. Although DID Services are public resources, it is good practice to ensure end-to-end encryption across the 1EdTech ecosystem.

Adhering to these principles allows the ed-tech community to leverage the full potential of DID services, ensuring interoperability, security, and user privacy are maintained across the ecosystem. These guidelines pave the way for a robust and user-centric approach to digital identity and resource discovery in educational technology.