Service providers should generate a WebID profile for the pod server [Implementation Guidance]

Proposal: Pod server implementors (and hosting providers) should be encouraged to have the server itself generate a WebID profile, with key material, during server setup.

Server key generation is already required by the WebID-OIDC authentication spec (identity providers use those keys to sign tokens and credentials). (Example: https://solid.community/jwks)

This issue proposes to specify what a WebID Profile would look like for a Solid pod server instance (such as solid.community). The profile can include things like:

• The server's WebID
• Server name, description, version and other metadata
• Links to Terms of Service
• Cryptographic key material (such as that currently contained in the /jwks document), for signing and encryption
• A list of WebIDs of persons or organizations acting as controllers/administrators of the server

This would enable:

• The use of cryptographic signatures to support Server-protected metadata. (Once the server has its own WebID and signing keys, it can digitally sign/integrity protect arbitrary RDF documents, such as server-side .meta resources).
• Server-to-server authentication (for when pods need to formally communicate with each other)
• Bringing of the OIDC-dictated public keys into the Linked Data realm (for the purposes of querying / reasoning etc).

Review the WebID-OIDC authentication spec and the current /jwks document first, then compare the linked server-protected metadata and cryptography issues. Define the server WebID profile’s metadata, key material, controller relationships, and relevant links; done means the profile structure and its intended uses are specified clearly.