Implement default verification method #253
Conversation
clehner
force-pushed
the
feat/issue-verify
branch
3 times, most recently
from
8af4891 to
2c0ca44
Compare
| @@ -184,6 +184,12 @@ pub fn now_ms() -> DateTime<Utc> { | |||
| pub trait LinkedDataDocument { | |||
| fn get_contexts(&self) -> Result<Option<String>, Error>; | |||
| fn to_value(&self) -> Result<Value, Error>; | |||
| fn get_default_proof_purpose(&self) -> Option<ProofPurpose> { | |||
| None | |||
There was a problem hiding this comment.
Are those defaults for ZCAPs? Should it be implemented directly for ZCAPs directly, to make it obvious that it needs to be implemented for other LD docs?
There was a problem hiding this comment.
Added initial implementation of get_issuer in 1d9e838.
For ZCAP-LD invocation and delegation documents, there isn't the same concept of "issuer" as in VCs and VPs. So the code added in this PR is not used in ZCAP-LD. I started changing the get_issuer function to get_verification_methods, to generalize it for VC/VP and ZCAP-LD, but it's too much for this PR currently.
| @@ -1096,6 +1100,84 @@ impl<'a> DIDResolver for SeriesResolver<'a> { | |||
| } | |||
| } | |||
|
|
|||
| pub(crate) async fn easy_resolve(did: &str, resolver: &dyn DIDResolver) -> Result<Document, Error> { | |||
There was a problem hiding this comment.
I guess this would be replaced by an implementation of the Try trait, once it's stabilised. Maybe put a TODO?
There was a problem hiding this comment.
Added TODO: 0bae94b
clehner
force-pushed
the
feat/issue-verify
branch
from
1e67c6e to
0bae94b
Compare
|
Discussed on call- since only remaining tasks are on the DIDKit side, will try to include in imminent SSI release |
When issuing/generating a proof: - If VM option is not provided, pick a default VM for the issuer. - If VM option is provided, verify its verification relationship with the issuer.
clehner
force-pushed
the
feat/issue-verify
branch
from
5a57264 to
cb0509d
Compare
Fix #144
This adds checking or selecting the verification relationship during issuance. When issuing a VC or VP, the verification method option may now be omitted and a valid one will be chosen automatically. If the verification method option is provided, it will be validated; an error will be thrown if the given verification method is not valid for the VC issuer (or VP holder).
Verifying a VC or VP is unaffected by these changes, as the verification relationship is already checked when the verification method verify option is omitted. However, these changes do change the code that enumerates the verification methods of an issuer.
To make these changes generic across VC/VP and JWT/LDP, two new trait method is added to LinkedDataDocument,
get_issuerto get the document's issuer URI, andget_default_proof_purposeto get the document's "default proof purpose". These have known implementations for VCs and VPs: A VC's default proof purpose is assertionMethod, while for VP it is authentication. A VC's issuer is referenced in the issuer property - which may be an id string or an object-with-id-property, while in a VP it is in the holder property - which is expected to be an id string. However, these concepts do not apply so well to ZCaps - instead of an issuer with a set of verification methods, ZCaps have a chain of capability delegation documents and target capability document, and a set of allowed "invoker" verification methods. The changes in this PR thus do not solve the ZCap use case: ZCap invocations and delegations must still be made with manually selecting the verification method and verifying it at issuance time. To generalize these changes to support ZCaps, a trait method for getting a document's allowed verification methods (instead of just getting the "issuer" id) - and probably a document loader for dereferencing capability documents would be needed too.The other use case that is not supported by these changes are non-DID issuers. Issuing using these is disallowed now, except for a special case for an issuer URL used in VC Test Suite - which is allowed without checking the verification relationship, since we don't know the contents of that example issuer. To support non-DID issuers, we could try to generalize the concept of DIDs and DID documents to other URI schemes, possibly applying different resolution strategies analogous to DID methods. For example, in Smart Health Cards, the issuer id is a HTTPS URL but requires additional processing, while for the VC Test Suite example issuer we might be able to implement it as resolving to something that looks like a DID document.
Cache/memoize/coalesce DID resolution (VM DID URL dereferencing). This would be a more complex change. But this PR has been updated to require only one DID resolution request during issuance (in the best case). During verification requires two - same as before.