GET endpoints for more details

[entin-hun]

Background:
While DIDs provide a mechanism for uniquely identifying a subject, there is often a need for applications to retrieve more detailed information about the subject. This is especially relevant for systems that need to interact with external services or data repositories to obtain additional context or attributes related to the DID subject.

Proposal:
I propose extending the DID specification to include GET API endpoint fields. These fields will allow for the specification of API endpoints that can be queried to retrieve additional information about the subject. The fields should include details such as the URL of the endpoint, resource IDs, required authentication methods, and credentials (decrypted only for the privileged), similar to how integrations usually store connections.

Specific Changes:

•	Introduce a new getEndpoints field in the DID document, structured as an array to allow for multiple endpoints.
•	Each endpoint object should include:
•	url: The URL of the API endpoint.
•	resource_Id: The (required) field key where the resource (D)identifier should be passed.
•	authentication: Details on the required authentication method (e.g., API key, OAuth).
•	credentials: Information about the credentials needed to access the endpoint.
•	Example of how the DID document might look with GET API endpoint fields:

{ "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", "getEndpoints": [ { "url": "https://api.example.com/resource", "resource_Id": "id", "authentication": "OAuth2", "credentials": "Bearer token" } ] }

Use Cases:

•	Enabling systems to dynamically retrieve additional information about a DID subject, such as current status, attributes, or related entities.
•	Facilitating the integration of DIDs with external data services, enhancing interoperability.
•	Supporting advanced use cases in sectors like IoT, supply chain management, and digital identity verification.

Impact:

•	This extension will make DIDs more versatile and applicable in environments where additional context about the subject is necessary.
•	By aligning with existing standards like OSLC and hypermedia, this proposal ensures compatibility with widely adopted practices in lifecycle management and service orchestration.