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