You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current internal representation VerificationMethod maps 1:1 with how Verification Method object is described. This makes it de/serialization simple, given that it default serde de/serialization is sufficient. However, it's not data model one would naturally come up if this was designed if de/serialization wasn't concern, for following reasons:
it's doesn't follow Law of Demeter - encoded representation is concern of de/serialization, in-memory encoding serves here no purpose
it's not efficient - whenever we want to read raw key value from a Verification Method, we need to re-decode they key value
deserialization of VerificationMethod does not provide guarantee as to whether the key is correctly encoded - it only guarantees the value is a String. Decoding is indirectly verifier upon upon an attempt to read raw key value from public_key
That being said, we likely want to keep attached information about "how should the raw key be encoded" upon serialization. Upon deserialization, we can set the value based on key encoding in the input.
Addressing this will be mainly matter of changes to VerificationMethod struct:
getting rid of PublicKeyField struct in favor of storing raw bytes
introducing flag signalling encoding to be used upon serialization
customizing process of serde de/serialization
The text was updated successfully, but these errors were encountered:
The current implementation of
VerificationMethod
looks as follow:and
The current internal representation
VerificationMethod
maps 1:1 with how Verification Method object is described. This makes it de/serialization simple, given that it default serde de/serialization is sufficient. However, it's not data model one would naturally come up if this was designed if de/serialization wasn't concern, for following reasons:VerificationMethod
does not provide guarantee as to whether the key is correctly encoded - it only guarantees the value is a String. Decoding is indirectly verifier upon upon an attempt to read raw key value frompublic_key
That being said, we likely want to keep attached information about "how should the raw key be encoded" upon serialization. Upon deserialization, we can set the value based on key encoding in the input.
Addressing this will be mainly matter of changes to
VerificationMethod
struct:PublicKeyField
struct in favor of storing raw bytesThe text was updated successfully, but these errors were encountered: