+1 to the goals of this split and quick side note. It would be ideal if we
could treat the DIF SSI stack post as a working document, revising as we
go.
https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45
Even if someone doesn't like the structure of it, it's a great
vendor-neutral start we can build on.
On Thu, Jul 16, 2020 at 2:06 PM Wayne Chang <wyc@fastmail.fm> wrote:
> Splitting off into a new thread to focus the discussion on the interplay
> of these specs.
>
> I think this is a good point. One big challenge around asking for claims
> is that we have several layers crossing wires in ad-hoc ways across these
> different specs. For example, we might try to separate these layers of
> asking for claims in ascending order from machine-only to human-readable:
>
> 1. Pipe: TLS, CHAPI, DIDComm
> <https://iiw.idcommons.net/101_Session:_Verifiable_Credential_Handler_(CHAPI)_and_DIDComm>
> 2. Formats: JSON-LD, CBOR <https://tools.ietf.org/html/rfc7049>, JWT,
> XMLDSig <https://en.wikipedia.org/wiki/XML_Signature>, PDF/XML-Signature
> 3. Document shape: JSON-LD Framing
> <https://json-ld.org/spec/latest/json-ld-framing/>, JSON Schema
> <https://json-schema.org/>, JSON Path <https://jsonpath.com/>-based
> Validators, MongoDB Query
> <https://docs.mongodb.com/manual/tutorial/query-documents/>
> 4. Value data type-based comparison: JSON Schema, MongoDB Query, JSON
> Logic <http://jsonlogic.com/>, OPA
> <https://github.com/open-policy-agent/opa> (?)
> 5. Semantic comparison: Trust Frameworks (?), Presentation Exchange
> (?), Digital Trust Protocol (?), business logic
>
> As you can see it's already messy trying to fit these specs into
> buckets...
>
> On Thu, Jul 16, 2020, at 2:54 PM, Orie Steele wrote:
>
> I'd love to see something that did not mix Transport, Data Model, and Data
> Selection concerns all into 1 spec... not saying anyone is doing this, it's
> just a concern.
>
> DIF is trying our best to tackle just Data Selection here:
> https://github.com/decentralized-identity/presentation-exchange
> W3C CCG has a request specification that works with a browser polyfill
> here:
> https://w3c-ccg.github.io/vp-request-spec/#example-5-a-zcap-request-query
> Mattr has this OIDC proposal for client bound assertions here:
> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>
> The problem is that legacy systems have formats that are not supported
> well by some of the new specs... for example, the support for JWT in VC
> Data Model is poor, and without the support from well known open id
> configuration / other OIDF tweaks that make OIDC work... VC JWT as a format
> is poorly documented and hard to use by itself... (JOSE/OIDC are fine, I am
> not talking about them here). This leads to a dependency on existing
> software solutions for moving JWTs around, and some real trouble with
> working with decentralized identifiers.
>
> Regardless of the "Credential / Claim / CryptoAssertion" format... we all
> need to transport them from A to B, and that means we all need a way of B
> describing to A what a "well formed request" should look like, and A needs
> construct that request in a way that B can understand.
>
> If your transport only supports 1 of the 3+ assertions formats out
> there... you are obviously not going to receive credentials from people who
> don't use that format.
>
> That's why the Presentation Exchange spec is so hard... we are trying to
> solve the problem:
>
> Create a verifiable presentation of the credentials needed to open a bank
> account... without telling people which credential format or transports
> they MUST use....
>
> Which obviously means, as a spec, it MUST work for all formats and
> transports :)
>
> OS
>
>
>