Charles E. Lehner
Charles E. Lehner
If `/.well-known/did.json` usage is to be kept (contrary to #50, but following https://github.com/w3c-ccg/did-method-web/pull/50#pullrequestreview-834762306), shall we register it with IANA/IETF? - https://www.rfc-editor.org/rfc/rfc8615.html#section-5.2 "The Well-Known URI Registry" - https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml - https://github.com/protocol-registries/well-known-uris -...
When a DID is [resolved](https://www.w3.org/TR/did-core/#did-resolution) to a DID document using the abstract `resolveRepresentation` function, the resolution result is supposed to include [DID Resolution Metadata](https://www.w3.org/TR/did-core/#did-resolution-metadata) that includes a `contentType` for the...
For use in web browsers, `did:web` providers may need to set headers in the HTTP response for the DID document, for [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). To enable any web origin...
https://w3c-ccg.github.io/ldp-bbs2020/ ### Proof types - [ ] [BbsBlsSignature2020](https://w3c-ccg.github.io/ldp-bbs2020/#the-bbs-signature-suite-2020) - [ ] [BbsSignatureProof2020](https://w3c-ccg.github.io/ldp-bbs2020/#the-bbs-signature-proof-suite-2020) - [ ] [BbsBlsBoundSignature2020](https://w3c-ccg.github.io/ldp-bbs2020/#the-bbs-bound-signature-suite-2020) - [ ] [BbsBoundSignatureProof2020](https://w3c-ccg.github.io/ldp-bbs2020/#the-bbs-bound-signature-proof-suite-2020) ### VC Operations - [ ] [deriveCredential](https://w3c-ccg.github.io/vc-http-api/holder.html#operation/deriveCredential) ### Verification method...
As discussed in https://github.com/w3c-ccg/vc-api/issues/284 > VP verification will verify each VC in the VP Checking that the VerifiableCredential credentialSubject id equals the VerifiablePresentation holder would still be the caller's responsibility...
~~A verification error was observed in verification compatibility between the ring Ed25519 and ed25519-dalek implementations.~~ This issue is to track how this is happening and adding tests to **ensure compatibility...
Importing code and test vectors from https://github.com/spruceid/cacao-zcap-rs. To have ssi depend on the cacao-zcap crate as it is now would create a circular dependency, since cacao-zcap already depends on ssi....
The `verify_proof_consistency` function (added in #241) calls [match_list_property](https://docs.rs/ssi/0.4.0/ssi/rdf/struct.GraphRef.html#method.match_list_property) to check that a proof object's JSON(-LD) corresponds to its RDF data: https://github.com/spruceid/ssi/blob/3fc36d8ca412135a0664ac39b78003868ba54850/src/vc.rs#L2269-L2276 But this expects that the `capabilityChain` proof property if...
- [ ] https://github.com/w3c-ccg/status-list-2021-test-suite - [ ] https://github.com/w3c-ccg/di-ed25519-test-suite - [ ] https://github.com/w3c-ccg/vc-api-verifier-test-suite - [ ] https://github.com/w3c-ccg/vc-api-issuer-test-suite
Currently, when verifying a VC or VP, the issuer/holder id is usually resolved twice: once to verify that the proof's verification method has the appropriate verification relationship with the issuer...