Some corrections and enhancements to the text based on feedback received from the community so far#295
Some corrections and enhancements to the text based on feedback received from the community so far#295bochaco wants to merge 1 commit into
Conversation
…ved from the community so far
joshuef
left a comment
joshuef
left a comment
There was a problem hiding this comment.
@bochaco "a private MutableData entry that the resolver cannot decrypt will need to be assumed as being unencrypted."
This part isn't super clear to me. Is the base point that we can't know if encrypted or no, so no effort is made to decrypt unless a private key is provided?
|
Yes, correct @joshuef , even if we had a decryption key provided with some mechanism, there is nothing we can do if it fails to decrypt. An straight answer could be, well we fail the request in such cases, but we also need to always remember that applications could corrupt data, e.g. by adding non-conformant data entries, which we should ignore if we want to be able to still read the data that is valid. So basically, it's about doing the best we can to extract the data which follows the convention/spec/format our resolver conforms to, as a way to coexist with other formats in the same data resource/object. This is how I see it at least. |
|
This is obsolete now, and all changes needed as per last research are covered with PR #337 |
2 participants
No description provided.