@nedmsmith: "verification-key-map isn't currently extensible. Extensions could break the predicate semantics of the triple. If another use case can't be supported, then a different triple should be defined or the spec should be updated to incorporate the use case requirements where interoperation, backwards compatibility and other impacts can be evaluated."
@thomas-fossati: "While I fully agree on Ned's point of not breaking the embedding triple's semantics, it seems quite plausible that one would want to add "revocation status" information (e.g., CRLs) along with cryptographic keys and certs.
We could add an optional "revo" array and then lock the type?"
Discuss extensibility of Verification-key-map
Previous discussion captured here:
@nedmsmith: "verification-key-map isn't currently extensible. Extensions could break the predicate semantics of the triple. If another use case can't be supported, then a different triple should be defined or the spec should be updated to incorporate the use case requirements where interoperation, backwards compatibility and other impacts can be evaluated."
@thomas-fossati: "While I fully agree on Ned's point of not breaking the embedding triple's semantics, it seems quite plausible that one would want to add "revocation status" information (e.g., CRLs) along with cryptographic keys and certs. We could add an optional "revo" array and then lock the type?"