Currently, we use Agent's HTTP subjects as identifiers, instead of their public key.
This approach has some issues:
Relies on uptime of subject server. The HTTP URL must resolve. That means it becomes unusable when the server goes offline, which is a major dependency.
Up-front authentication check cost: This fetching mentioned above takes some time, which slows down the first interaction. The next ones will be cached, although...
Key changes are complicated. If an agent changes their keypair, external stores may have an outdated version, which will (currently) result in errors. We could implement some cache-invalidation logic here, but it's not elegant.
We could instead use the public key (and not the HTTP address) as the primary identifier of Agents:
Commits and HTTP request will no longer require the Agent's HTTP subject, only the public key
The signer field will now no longer be an HTTP identifier. To help clients find out information about a Signer, we can create an endpoint for the Server that allows people to find the profile of a user, e.g. /agents?pubkey={key}.
It might be a good idea to use a did identifier as the subject #59.
When we reference to agents (e.g. in a Rights array), should we reference by these keys / dids? If that's the case, these keys may become outdated, as keys can rotate. If we use an HTTP identifier which includes the public key (e.g. example.com/agents/{pubkey}, the user can later change their used key by modifying the resource at the mentioned URL. But we re-introduce the original issue: the HTTP identifier may go offline.
Currently, we use Agent's HTTP subjects as identifiers, instead of their public key.
This approach has some issues:
We could instead use the public key (and not the HTTP address) as the primary identifier of Agents:
signerfield will now no longer be an HTTP identifier. To help clients find out information about a Signer, we can create an endpoint for the Server that allows people to find the profile of a user, e.g./agents?pubkey={key}.dididentifier as the subject #59.example.com/agents/{pubkey}, the user can later change their used key by modifying the resource at the mentioned URL. But we re-introduce the original issue: the HTTP identifier may go offline.