Selective Disclosure ZKPs for Supply Chain

[OR13]

We added support for https://github.com/w3c-ccg/ldp-bbs2020

to the vc-http-api here: https://vc.transmute.world/api/docs

We should come up with some exemplar credentials that would be good to provide examples of using this proof suite.

An almost complete working PoC here: http://didme.me/

[mprorock]

Awesome. This kind of thing is something we deal with regularly, where an Inspector gets a VC with full details on the inspection, but some of those items may not be shared with 3rd parties, just the status, inspector name, etc. Happy to put an example up somewhere. Mike Prorock CTO, Founder https://mesur.io/

…

On Tue, Feb 23, 2021 at 12:05 PM Orie Steele ***@***.***> wrote: We added support for https://github.com/w3c-ccg/ldp-bbs2020 to the vc-http-api here: https://vc.transmute.world/api/docs We should come up with some exemplar credentials that would be good to provide examples of using this proof suite. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/w3c-ccg/traceability-vocab/issues/120>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2VJZB236D2WZJKEXXARTLTAPN5DANCNFSM4YC3J4UQ> .

[OR13]

Discussed on call. Proposal is move this to the interop repo when it exists.

[OR13]

@mprorock can you add a flow chart / example covering multiple parties.

[OR13]

2 actions remain on this issue:

• example flow (real world use case)
• update vc-http-api tests to cover deriveCredential

[OR13]

Proposal: we should make deriveCredential a MUST for trace-interop

[TallTed]

This was the nearest issue to the discussion in IRC, but I'm not sure it's actually what we were talking about, where I said mock PROPOSAL: trace-interop implementations MUST negotiate encryption mechanisms by requesting ____ and replying ____

Candidate response header, available in HTTP/1.x and HTTP/2; will presumably persist to HTTP/3 --

Pragma
Pragma: no-cache
Implementation-specific fields that may have various effects anywhere along the request-response chain.

Could also dive much deeper and go with 5.5. Extending HTTP/2.

Neither of these is quite what I was thinking of, so I'll be digging a bit more, too.

[TallTed]

Issuing HEAD against specific URIs can get returned Link: headers which have complex values, such as --

Link: <{ URI of encryption endpoint }>; rel="{ plain-literal as registered with IANA (registration recommended but not absolutely required), or URI as defined by this spec; e.g., "BBS+" or "https://github.com/w3c-ccg/ldp-bbs2020" }"; anchor="#if_needed"

The rel value may be open-ended, allowing for extension as required by deployments, without requiring that they go through a registry -- allowing high-speed evolution when necessary, as well as private extensions that may not be understood by those not directly involved.

[OR13]

On the call today, we discussed the need to support discovery of both "issuer" ids and "credential suites".

We discussed the proposal to use the Link header, and .well-known resources.

[OR13]

We agreed, to open an issue on the vc-http-api to tackle these issues.

[mprorock]

big fan of http accept headers for http calls, as well as use of .well-known for capabilities discovery

[brianorwhatever]

We could also include this within a did:web document on the issuer .well-known/did.json endpoint. For example this did could include a service block that contains the endpoint and what crypto suites it uses and issuer ids managed at that endpoint

[OR13]

I opened this issue: w3c-ccg/vc-api#218

[mkhraisha]

Discussed on call waiting on vc-http-api group action

[nissimsan]

Keep open, blocked by VC-API

[OR13]

There are known issues with BBS+, we should close this issue until its possible to use any LD Proof format that supports derivation.

See w3c/vc-di-bbs#62

[brianorwhatever]

This issue is closed because the upstream problem needs to be resolved. We will open a new issue once that has been resolved.

[TallTed]

My concern is "What triggers a new issue creation, upon resolution of the blocker?" which flows to "Who or what is watching for resolution of that blocker?"

[brianorwhatever]

@TallTed I definitely see where you're coming from and have opened a new issue. I will continue to monitor this issue