-
Notifications
You must be signed in to change notification settings - Fork 9
2023 11 15 Meeting Notes
Organizer: Tim Cappalli
Scribe: Rick Byers
Meeting thread on Slack: https://w3ccommunity.slack.com/archives/C05UG0EJUDB/p1699998782734459
- Administrivia
- Are folks around next week?
- How about 12/27?
- Intros from new folks
- Updates from Blink incubation
- Anyone prototyping with their wallet or verifier?
- Google presentation to OWF (slides)
- Tentative: feedback on the current proposal from the OpenID4VP community
- New issues:
- Do any wallets need TLS context from the browser (or app platform)?
- Older issues:
- API design should emphasize that sites should request minimal properties, not full identity documents
- Jevons Paradox
- Requests for multiple credentials
- Credential format coexistence
- Terminology doc
- AOB
- Rick Byers, Google Chrome
- Sam Goto, Google Chrome
- Kristina Yasuda, Microsoft
- Mike Jones, Independent
- Lee Campbell, Google Android
- Helen, Google / Android
- Tobias Looker, Mattr
- Marcos Caceres, Apple/Safari
- David Z, Google Android
- Tim Cappalli, Microsoft
- Heather Flanagan (Spherical Cow Consulting)
- Gareth Oliver, Google
- Nick Doty, CDT
- David Zeuthen, Google
Tobias: on Samsung, it works sometimes, is there something specific about Samsung, where there is a known issue
Helen: I’ve seen this once, but I think it started working again
Tobias:
Tim: does it require Android 14?
Helen/Lee: nope
Rick: OWF working on open source wallets
Rick: Some overlap with eidas group
Rick: Generally positive, some of the usual concerns around how much does the browser knows, a lot of people suggesting that Web wallets are critical, issuance APIs, etc. For an MVP, mobile/app only fast followed by Web wallets.
Lee: seemed to go very well, very positive so far … some of those folks may join these calls
Lee: Most people understand the restrictions of custom schemes
Rick: some people interested in understanding whether Apple is going to participate, noted that the explainer is written by an Apple engineer
https://github.com/WICG/identity-credential/issues/46
Tobias: the web works on the origin model
Tim: these restrictions don’t quite exist in the context of WebAuthn … if the law says, in order to be a wallet in the EU .. you must be a verified QWAC certificate
Nick: Lee: how are they planning to roll out QWACs?
Tim: it is like any other certificate property
Rick: there is a bunch of details here, laws that browsers would have to comply to operate in the EU
Lee: are we going to deal with multiple certs, or are these typical TLS roots?
Tim: we are asking if browsers can pass along the information … like qwac=true
Nick: hard to say, i don’t know, if that’s not something that the browser is going to present to the user and pass along to the wallet, that could be a misrepresentation risk
Lee: should we maybe just punt on this until we have folks that are more familiar with this part of the regulation so that we have more information?
API design should emphasize that sites should request minimal properties, not full identity documents
https://github.com/WICG/identity-credential/issues/43
Marcos: Nick raises a good point
Nick: we don’t want to convey the message that we are not sharing the entire identity of the user, but rather the most constrained / limited part of the user’s identity we can possibly have.
Marcos:
Tobias: the syntax must always be at a client-level, but not default to requesting more information … e.g. you can’t just ask for everything, you have to specifically name the properties that you want … every syntax they see shows a very specific set of information that is needed, rather than just asking for all
Nick: that seems like a reasonable additional way to accomplish that
Lee: we could say that in order to add your protocol to the list you have to support selective disclosure
Kristina: there are cases where you want
Nick: Kristina: a verifier can technically ask for anything they want …. Mandating selective disclosure ..
Andrew:
Lee: what’s most important to me is that android can build a meaningful credential selector … if verifier can ask for *, then it is harder to display that UI
Tobias: one counter example … so OpenID is a profile scope
Kristina: if it is still the user who makes a decision … we are not preventing verifiers from receiving more claims than that they needed to … isn’t that a legal issue rather than a technical one?
Lee: form an Android POV, I want the specific attributes to show in the UI
Tim: where should the registry be defined?
Sam: before we over-generalize, can someone give me an example of protocols other than OpenID4VP?
Tobias: CCG community has some, not the CHAPI part. Where does a query language stop and protocol begin or are they the same?
Sam: I think the query language is a subset of the whole protocol. Protocol also contains a nonce etc.
Kristina: I agree with what Lee. I'm concerned about people putting query languages just in a http request without a nonce etc. Martijn and Hicham have been asking in ISO group about this. Query should definitely be part of the bigger protocol to enable those protections.
Tim: Is VP request just a "raw" VP request/response?
Tobias: Query by frame in CHAPI. Will add example to terminology doc.
Tim: What is the protocol name for just simple mdoc?
Lee: doesn't exist yet. Mdoc is a format. Maybe the rest protocol?
Sam: I don't know enough about mdocs, but is -7 annex b the equivalent to OpenID4VP?
David: Hard to compare. I guess the rest API is some kind of presentation protocol.I wouldn't even say mdoc is a credential format, we've only defined how to convey it (just transmit, not receive/store).
Gareth: REST API is definitely a protocol, mdoc specific, currently only formatted to work via custom schemes
Tobias: My understanding is wouldn't be REST API or OpenID4VP. Create parts of session layer and session transport to get response back. I just wouldn't call them any of those names to avoid confusion. Could apply the principles to the browser API but should get a new name.
Kristina: We're talking about -7, not -5. Contains REST API, wouldn't want to try to map that to browser API - unclear how. 2nd protocol in -7 is OpenID4VP profile for mdocs. So what exists is OpenID4VP but it's being profiled to be used for different credential formats.
Sam: The reason I'm asking is from an API design perspective we have a registry of protocols. But if it's just containing one thing then it's not a registry. Level of indirection but we expect just one to exist. Or maybe there's a second one? What do we gain with this level of indirection
David: Yeah kind of weird to do it just for one protocol, but it highlights the profile of that protocol - which parts of it apply.
Sam: We're asking ourselves what principles / common things we'd put in the registry. But really hard to come up with principles when we have only one example.
Kristina: 3 things being discussed Using OpenID4VP directly in browser API Designing from scratch API request structure - forget about PE, OpenID4VP etc. Credential Implementation by reference - wallet endpoint? .. Can we reduce
Lee: What's the alternative? If we don't have a registry than W3C needs to define a full protocol. If there's only one today, maybe there will another tomorrow or in 3 years. It unblocks us.
Tobias: When it comes to protocol and query languages - more work to be done to separate them out. I do question what the different layer of abstraction is buying us. If we could resolve them in a browser context it would let us remove an entire layer of abstraction. But it might complicate the API and make it further difficulty to maintain.
Marcos: It would be a worthwhile exercise for us to figure out what are the overlaps. Map them out in parallel. A concern I'm personally hitting on with OpenID4VP, it seems like it's very open to accepting new protocols. What is the value add of having this thing that sits between mdoc and what we're calling protocols. I understand the query language is one thing, but shouldn't mdoc itself define it's own query language?
Kristina: I agree with Tobias. We should be package query language as part of transport protocol. We should treat it as part of OpenID4VP for our purposes here. Marcos, mdocs don't really have a query language. The layer separation here … means OpenID4VP as a transfer protocol that enables different credential formats.
Marcos: I'm worried that by supporting OpenID4VP we'd have to support n number of credential formats, which we don't want to do on the Apple side because it would be a lot of work. We only want to support, hypothetically, one or maybe two maximum. We don't want to be supporting a thing that's open to supporting even 3 or 4 different things
Michael: when you say protocol you mean data format?
Marcos: Yes
Kristina: OpenID4VP defines profiles - mdoc is one, jwot is another
Michael: Agree, we're not going to have 5 viable credential formats.
Marcos: If we can do one, that would be ideal in my world.
Kristina: But as browser API why do you care about this? As long as wallet supports credential format verifier is requesting, as an API you don't really care, do you?
Marcos: Yes because we still need to parse it
Kristina: But that belongs to the transport layer. Your code doesn't change in the browser part.
Marcos: right, but the wallet cares. In the Apple ecosystem it's all the same stack. What format does the wallet itself support. There may be a wallet that supports many, but in an an ideal world there will be only 2 supported formats. That may or may not be realistic.
Kristina: Trust me, we've all tried to convert data formats into one and we've all failed.
Marcos: But we could force that in some way by saying we only support these 2
Kristina: personally I may fully agree, but from a technical level you can still do this with OpenID4VP. You can still limit only to mdocs only for OpenID4VP.
Marcos: Yes but then some jurisdiction decides they want to mandate by law W3C VC. So I'm trying to understand what will be mandated in practice and can we just restrict to that. What is the actual things we need to support in practice?
Tim: Need to get that terminology doc filled out, lots of these things are questions in Sam's doc. Next pacific call we'll spend time on that discussion.
Tim: Will put an update on slack for monday call