Closed dbluhm closed 1 week ago
Could you provide more specifics or links to the encoding/hashing approach?
My biggest concern would be verifiability. To verify the SCID you would have to update the log entry text to put in the placeholder where it is needed, encode, take the hash/encode/etc. and then compare to the SCID. Is the technique sound enough to allow for that manipulation? I’m not saying it isn’t — just making sure that kind of manipulation is possible.
Readability has been one of the goals with this format, and encoding the payloads with base64 JOSE-style definitely wouldn't help with that. I imagine we'd just use CSV at that point?
That's fair, if readability is a goal, base64 encoded blobs would not help at all.
Thanks for the prompt replies! I think I'll conclude that it is possible to achieve the same properties cryptographically (with some rearranging of operations) but would lose the aspect of readability. I don't have a challenge to having that property as a goal so I'll close.
In a similar line of thought to #61 (simplifying), is it possible to achieve the same properties in SCID generation without using JCS?
To vaguely outline an alternative process similar to the one used by JOSE, inputs to hashes and signatures could be encoded and then the encoding itself could be included in the did log entry. Then operations would be performed over the already encoded value.
This would change up the algorithm for generating and verifying the SCID and log entries but I think this would mostly constitute a slight change in the order of operations as opposed to a true fundamental difference.
I'm curious to hear thoughts and any background on the decision to use JCS.