-
Notifications
You must be signed in to change notification settings - Fork 9
2024 03 06 Meeting Notes
Organizer: Tim Cappalli
Scribe: Mike Jones
- Query language / syntax
- Introduction (Tobias Looker)
- Open Discussion
- Next steps
Related issues:
- Tim Cappalli (Okta)
- Mike Jones
- Lee Campbell(Google/Android)
- Gareth Oliver(Google)
- Loffie Jordaan (AAMVA)
- Sam Goto (Google Chrome)
- Orie Steele (Transmute)
- Kyle Den Hartog (Brave)
- Nick Doty (CDT, listening mode)
- Joseph Heenan (Authlete)
- Heather Flanagan (Spherical Cow Consulting)˙
- Martijn Haring (Apple)
- Hicham Lozi (Apple)
- Tobias Looker (MATTR)
Mike Jones agreed to take notes, with Tim back-stopping him
Tim: The only topic on the agenda is query language syntax ... This conversation has been a long time coming
Tim: There have been some questions about the Fed ID WG and adding the Digital Credentials API work to be in scope. That will be discussed on the next few calls, as well as the Fed ID CG, and anyone can comment on the charter process GH issue
Kristina: I made a comment on one of the call threads asking to revisit the call time since
Kristina: Is this conversation about requirements?
Tim: Kick it off Tobias, and we'll find out
Tobias: This is about summarizing learnings and possible solutions
Kristina: Is this about a query language for OpenID4VP? ... This is a query language proposal for the discussion here
Kristina: Then this is purely about the browser API
Tobias: The query language syntax proposal is at https://docs.google.com/document/d/10JT--pXWsfwC4QVu3XJpXGwcO08M6tnpkZ4PKdtCEWo/edit
This incorporates learnings that I've learned from other query languages, including Presentation Exchange
It is front-and-center in people's minds given its use in OpenID4VP
We've created a query language that is format-specific, rather than format-agnostic
We expect that people will embrace different parts at different points in time, building support for different formats when they need it
We've considered things like optionality
This is a strawman that is an attempt to put something on the table to throw rocks at
So we can decide which parts we like and what we don't
There are circumstances in the browser API where we anticipate requesting one presentation at a time
First example for an ISO mdoc query
Rest of structure informed by that
For instance, including namespaces is mdoc specific
You have data element identifiers and properties of those identifiers, such as whether they're required
Has intentToRetain, requiredIfPresent
Martijn Haring: Yesterday & today in the ISO meeting we spent time discussing how “required” should work. And optionality.
We should find a way to align with that
Tobias: Absolutely
Lee: I like this direction. I'm no fan of PI. It's big and complex.
It's moving away from having a query language that is intended to work across all formats
That's what Sam and I were thinking about
But your insight is that that doesn't scale very well
Tobias: You need to be able to ask for things that are specific to the format ... Trying to be format-agnostic causes more problems Lee: I expect that the queries will be mostly machine generated
Manu: +1 to the design direction
This is the same conclusion that we came to in the Presentation Request request - https://w3c-ccg.github.io/vp-request-spec/
The foundational approach to your proposal is that there will be different credential formats and that it's OK for the queries to e format-specific
Is there a need for introspection into the query formats
Sam: If there's a place that we shift pain to, it's better to shift to the browser to offload work from other parts of the ecosystem
I'm concerned with premature generalization. That leads to things like PE.
We should nonetheless look for ways to enhance interoperation
Marcos: My intuition is the same. I'm not concerned about having different data structures.
The proof will be in the pudding
This feels like a good direction to go in
Kyle: I recognize that we're walking down the scopes problem that OpenID faced
The claims will have to be defined. I accept that.
We need to be careful from a privacy perspective not to create a privacy fingerprinting problem
Tobias: The queries would use strings not standardized by the query language. They would be standardized by particular specs using the credential formats.
Kyle: With scopes, you individually identify claims but here we're identifying profiles
John: I'm OK with this general direction
At the highest level, you're thinking of this as an exclusive or array, where you get one response determined by the wallet
Are you imagining any order of preference or is it entirely up to the wallet?
Claim names across an SD-JWT may not be the same as an mDoc
I don't think this increases fingerprinting
I guess this allows for more precision
I'm against the browser meddling with the flow between the endpoints and wallet selection
Kristina: I want to respond to Sam's comment about the browser absorbing complexity. The wallet needs to receive it and understand it.
I think it would useful on a next call to continue the architecture discussion
I know that in Android, there's a wallet selector. I don't know what Apple is thinking
Nick Doty: Different credential-format query syntaxes could result in different user experiences, which isn't good
I'm not sure that developers should have to learn that either.
Sam: Will be multiply issuing credentials in different formats? Such as mDoc and SD-JWT?
What is the UX that the selector will show. Maybe there's a de-duplication aspect of this.
Tobias: It's somewhat undecided in different ecosystems whether issuers will dual issue.
We can't assume that the developer has no familiarity with the credential formats. It has to be able to consume an mDoc, for instance.
You can't engineer out that you need to have familiarity with the data structure
Marcos: It won't be a dumb pipe. We will be restructuring the data for wallets. We can't pass raw data without vetting for security reasons.
Kyle: At a claims level, we have to understand all the claims. The browser could verify consent. The wallet is handling more of the authorization model.
I don't see that the browser is going to not be able to participate at the claims level.
Mike Jones: in reaction to previous comments, originally thought making things format specific would cause more problems than it would solve. After looking at examples, I realized I was wrong. Looking at mDoc, much is not applicable to other formats. There's going to be binary CBOR formats, where parts are UTF-8 strings but some are numbers.
dominant use of the browser API will be for a single response, so some of the PE complexity isn't needed. Could add ways to request multiple credentials. Could imagine notations in the list. This is a thought experiment to start the discussion.
Manu: The California DMV has multiple credential formats. Multiple ones are returned.
If we map that use case to what's being proposed here, I think that works.
You could, for instance, as for an “age over” claim first and an “age” claim as a fallback
That's a good fit to the use case
Having the queries match the formats is better than trying to boil the ocean by creating a format-agnostic query language
Lee: We have to credential selection anyway
There's an explicit user action before we go to the wallet
The wallet has to perform the ultimate user consent
As platforms, we don't want to be responsible for that.
As for garbage-in-garbage-out, we're currently not validating much
We'll probably take whatever you put in the request and pass it on to the wallets
That decision could evolve over time
Kristina: We do need implementation experience at the wallet and the verifier label
It's not sufficient to just say that it's simpler
To Kyle's point, under EU regulations, the Wallet is the ultimate authority
There are specific legal requirements behind it that should be taken in account
If the Wallet just becomes a place to store the data provided to the browser, I don't think implementer's will be happy
Kyle: I think you understood my point. There's a conflict of interest about ultimate agency.
Wallets are going to be regulated. Browsers not so much. Browsers as based on the W3C.
Verifiers may want to understand how trusted browser/wallets are but in revealing this information we can end up with second order effects like these credentials being used to attest integrity of software running without regards for the claims actually being shared.
John: I agree with Lee that if the browser intends to understand the semantics of every single credential, that won't scale. That's insanity.
I could see verifying that the JSON is well-formed and maybe understanding what the doc format is.
But going into the individual claims won't work.
Will you have support for eduPerson? There are many use cases and schemas.
The browsers won't have any possibility of keeping up.
If the browsers try to do that, we'll just go around them.
The API needs to pass in trust information, such as trust marks, in the request, so as to not offer credentials that won't be served by the wallet. We need to catch this early in the process.
Need to understand the trust relationship with the verifier
To Manu's point about having ZKP formats versus less privacy-preserving claims, who decides?
If they're both in the same wallet, it's up to the wallet to do the right thing. If not, we need to think about it at the credential selection or platform layer.
Tim: How do we want to handle asynchronous work on this?
As just a Google doc or something in the WICG repot. We need to figure that out.
Tobias: There's a parallel conversation in the OpenID community
Tobias: It's up to the WICG what to do
Kristina: If it starts here then wants to move to OpenID there could be problems
Tobias: We're still having architecture discussions about how things interrelate
This document was just about trying to have a conversation on the query topic
Then we identify the blocks and decide how to assemble
Kristina: Please consider IPR implications of where to do the work
Tim: I'm going to propose that this starts as an explainer
We'll follow up on these things in a subsequent call