digital-credentials

digital-credentials copied to clipboard

Surfaced as a core discussion topic on the first call (2023-10-04).

• Presentation exchange vs something else
• Extensibility

Not recommending any of these, just surfacing them for inspiration:

• https://www.w3.org/TR/json-ld11-framing/
• https://www.w3.org/TR/sparql11-query/
• https://www.gqlstandards.org/what-is-a-gql-standard
• https://neo4j.com/developer/cypher/
• https://datatracker.ietf.org/doc/html/rfc6901

Addition context regarding the interaction between query languages and credential formats:

• https://github.com/WICG/identity-credential/issues/12
• https://w3c-ccg.github.io/vp-request-spec/#query-by-frame

vp request spec supports multiple "query languages" including query by (JSON-LD) frame.

Finding a query language that is not overfit to the credential format might be challenging, and simple query interfaces that are triple, or tuple based, are probably going to be easier to use for some cases.

A sub question here is:

• Should Query Languages be format specific (e.g. one for VCs and one for mDocs and one for whatever comes next) or format-agnostic?

Should Query Languages be format specific (e.g. one for VCs and one for mDocs and one for whatever comes next) or format-agnostic?

Making the query language format agnostic might be difficult... picking a "winner" at this stage seems fraught as we're just entering the first iteration of production roll outs and testing, and to be frank, the all of the existing query languages will need work for at least the next couple of years.

We need to build in the ability to replace whatever v1 is entirely... or the ability to query using multiple query languages (and have the wallet match on whatever one it understands best).

Also adding VP Request spec (being incubated in CCG, 10+ implementations in latest plugfest, etc.): https://w3c-ccg.github.io/vp-request-spec/#introduction

@npdoty: I'd like to understand what kinds of abuse mitigations we'd like to have and how would that impact the query languages ...

https://github.com/WICG/identity-credential/issues/30

@npdoty: when you say:

clear indication of for what legitimate purpose a credential is being requested

how much does the user agent need to "understand" what's being requested?

From the perspective of Issuers and Verifiers of high value global credentials related to cross-border travel, employment and immigration, I've found that the scope attached to what is meant by "Query Language" to be ... not enough.

At a mechanical level, when a digital wallet shows up at our front door, we need to have an understanding of the security, privacy and interoperability capabilities of that wallet before we can make a decision to issue credentials into that wallet and verify credentials coming from that wallet.

In addition, an individual wallet holder would also want to have a clear understanding of how the counter-party they are interacting with (whether an issuer or a verifer) will use and protect the data that that is shared with them. To be blunt, any of the three parties could also lie about their capabilities and the way to mitigate such actions are not in the technical realm.

In an ideal world all of these questions and intent-signalling could in-part consist of some manner of real time query, challenge, interrogation that could give information on a certain sub-set of the capabilities of that wallet / issuer / verfier.

However, there are simply some capabilities that are not amenable to such an approach. Which means, there needs to some manner of evaluation/assessment done of that wallets / issuers / verfiers that results in some manner of trust mark provided by an acceptable entity that provides confidence to the counter party that a wallet / issuer / verifier has a specific set of capabilities and commits to specific security and privacy practices.

I tend to call this “Capability Detection” and contrast it with what is going on in the market right now which is simple “Product/Vendor Detection”.

I think it is important if you seek a future of multiple independent, interoperable and capable digital wallets, the global community (including both the public and the private sector) put energy into developing a shared definition of what capabilities the 3 parties in the model need to convey, how you can assess and evaluate the quality of those capabilities, and ultimately support mechanisms and process that use those openly developed criteria to do certifications and assessments of digital wallets / issuers / verifiers against the set that shared, open criteria.

In the absence of such investment, particularly when it comes to digital wallets, you will end up in a place where decisions regarding the acceptance of a digital wallet are based on the vendor or jurisdiction that produced it, with no understanding of how that wallet manages, uses, shares and potentially monetizes the very private and sensitive data in the wallet. And over time, the number of wallets will naturally reduce down to handful of entities who control your data within their wallet – rather than the promise of individual agency and control that many seek with the use of the 3 party identity model.

I also realize that all of this is not going to come about magically and now .. but would like to understand how the current approaches to Query Languages could be implemented in a manner to establish a sufficiently solid foundation to be able to incrementally build on to ensure capability detection instead of product detection as the default.

Making the query language format agnostic might be difficult... picking a "winner" at this stage seems fraught as we're just entering the first iteration of production roll outs and testing, and to be frank, the all of the existing query languages will need work for at least the next couple of years.

+1, Presentation Exchange essentially embarked with this goal and the main trade off I've observed which I don't think is worthwhile Is that a query syntax that is credential format agnostic becomes too abstract for relying parties meaning they struggle to create queries reliably.

R.e @aniltj commentary of which I agree with much of, does beg the question for me which is "what are the bounds of the query language we are looking to define?" For example is the purpose of the query language to just support the requesting of identity credentials? IMO yes, but I'm picking up that there might other perspectives here, for example I've seen loose proposals before from @msporny on using CHAPI before to not only request identity credentials per say, but also using it to request things like wallet attestations modelled as VC's in effect expanding the purpose of the query syntax beyond requesting identity credentials but into also requesting capability attestations from the wallet provider.

Cleaning up old issues. Query languages are part of the downstream protocol (e.g. DCQL for OID4VP).