Add a well-known endpoint for catalog requests

[jimmarino]

A participant catalog may contain protected Datasets that require some proof to access. The mechanism for preseting a proof during a catalog request is outside the scope of the DSP Catalog Specification and should be detailed in a separate trust specification. For example, a trust specification may rely on W3C Verifiable Credentials and Verifiable Presentations as proof.

However, all trust specifications will require a mechanism for a client to discover which proof mechanisms are required to access protected catalog Datasets. The format of this metadata is specific to the trust specification, but the endpoint should be defined using a Well-Known Uniform Resource Identifiers.

The proposal is to add the following endpoint to the catalog specification:

/.well-known/dspace-trust

The contents of the response is a JSON object defined by individual trust specifications.

[sebbader-sap]

Task 1:

• [ ]  Verify whether https://example.com/path-to-my-connector/.well-known/ is explicitly prohibited by the RFC.

Task 2: Decide on pattern for catalog vs. general trust information: https://example.com/.well-known/dspace-catalog-trust https://example.com/.well-known/dspace-trust --> Decision: This is the pattern we want to use.

[ssteinbuss]

@sebbader-sap means RFC 8615

It stated there in section 3 that:

Well-known URIs are rooted in the top of the path's hierarchy; they are not well-known by definition in other parts of the path. For example, "/.well-known/example" is a well-known URI, whereas "/foo/.well-known/example" is not.

[ssteinbuss]

We might want to add a note on multiple connectors under the same URI:

• Connectors could use different sub-domains, but if they are not using sub-domains, then
• probably the well-known endpoint cannot be used

[jimmarino]

We might want to add a note on multiple connectors under the same URI:

• Connectors could use different sub-domains, but if they are not using sub-domains, then
• probably the well-known endpoint cannot be used

They could append a path segment to the base well-known URL. Section 3 states:

Registrations MAY also contain additional information, such as the syntax of additional path components, query strings, and/or fragment identifiers to be appended to the well-known URI, or protocol- specific details (e.g., HTTP [RFC7231] method handling).

So, for example, a connector URL of https://example.com/connector1 could use:

https://example.com/.well-known/dspace-trust/connector1