Readonly
masterGet the master key of the identity.
Readonly
selfGet the self-signing key of the identity.
Was this identity verified since initial observation and is not anymore?
Such a violation should be reported to the local user by the application, and resolved by
Has the identity changed in a way that requires approval from the user?
A user identity needs approval if it changed after the crypto machine has already observed ("pinned") a different identity for that user, unless it is an explicitly verified identity (using for example interactive verification).
This situation can be resolved by:
Create a VerificationRequest
object after the verification
request content has been sent out.
Send a verification request to the given user.
The returned content needs to be sent out into a DM room with the given user.
After the content has been sent out a VerificationRequest can be started
with the request_verification
method.
Optional
methods: any[]Manually verify this user.
This method will attempt to sign the user identity using our private cross signing key.
This method fails if we don't have the private part of our user-signing key.
Returns a request that needs to be sent out for the user to be marked as verified.
True if we verified this identity (with any own identity, at any point).
To set this latch back to false, call withdrawVerification.
Remove the requirement for this identity to be verified.
If an identity was previously verified and is not anymore it will be reported to the user. In order to remove this notice users have to verify again or to withdraw the verification requirement.
Struct representing a cross signing identity of a user.
This is the user identity of a user that isn't our own. Other users will only contain a master key and a self signing key, meaning that only device signatures can be checked with this identity.
This struct wraps a read-only version of the struct and allows verifications to be requested to verify our own device with the user identity.