While just an example (and perhaps not the focus of the example), I thought it was important to note that the proofPurpose used in your example is assertionMethod but the "verification relationship" used in the DID Document to express the verificationMethod is authentication. This is a mismatch that would cause a properly implemented verifier to reject the proof.

The way that "verification relationships" work is that they link a DID subject to a verification method that is authorized for a specific purpose. So, if a proof expresses that it was created for the purpose of "assertionMethod", then a verifier knows to look for the verificationMethod expressed in the proof under the "assertionMethod" property in the DID Document. If the verification method cannot be found under that property, then it is not considered authorized to verify the proof and the verifier must emit an error indicating this.

This mechanism allows verifiers to help provide additional security protections for users -- whereby, for example, if the user has signed a message by attaching a proof with a proofPurpose of assertionMethod, it cannot be misused by an attacker to try and authenticate as the user instead. There's a critical difference between signing a message to "merely make an assertion" and signing a message as a means to authenticate to a service to, for example, establish a session to perform actions you're authorized to do. Ideally, messages themselves help make this distinction, but it is not always the case -- and sometimes encodings can be abused to misrepresent different semantics for the same message payload.