Should we have a common and interoperable definition of request types and their privacy properties?

[samuelgoto]

We discussed in the last CG call how to handle registries, and I think we realized as a group that there are two layers here: the protocol layer (e.g. OpenID4VP) and the request type layer (e.g. Presentation Exchange).

We understand the former layer better than the latter, so we were discussing whether we should have a common definition of request types.

Chrome currently accepts two types of requests:

• hardcoded requests for age brackets, with a light privacy threat model.
• anything else, with a heavier threat model.

The benefit of the former is that it allows well-understood and anticipated use cases to have a user experience that is meaningful and comparable to the privacy risks that are involved. The drawback is that they have to be well-understood and anticipated.

The benefit of the latter is that it allows verifiers and holders to request/respond anything without asking for the browser's permission. The drawback is that the browser falls back to the worse case scenario in its privacy threat model, and imposes a higher friction UI for users.

We expect the former group to grow over time, from use cases from the latter: innovation happens with the latter, and when things settle and they are both (a) well understood and (b) in high demand, they move to the former group.

The open question is whether (a) it is possible or (b) desirable to have a common and interoperable registry of these request types that browser vendors agree on.

[samuelgoto]

Ah, I realize that this may be a duplicate of #85. Feel free to close as a duplicate if you believe so too.

[jogu]

I don't think it's a complete duplicate of #85 - 85 appears to be about credential types, whereas this issue appears to be about request types (there's definitely some overlap though, as I think you need the credential types to be able to cover this issue).

Is at least a sub-part of the problem the question "Could Chrome hardcode requests for age brackets via a registry?".

If it is, then I'm struggling to really see how that's possible/easy, at least for cases where the user's age is legally required.

For example a UK based verifier needing to verify a user's age will accept at least:

1. Passport (UK or International)
2. Photo Driving Licence (UK or European)
3. European National ID Card

which is probably at least 2 different credential formats, 30+ accepted issuers. Assuming we wouldn't want to hardcode these requirements (but instead give verifiers a sensible set of queries they can compose) and that those requirements (which are for photographed physical documents) would be the same in a digital credentials world, then I think Chrome would then need hardcoded queries for:

1. Age over X from any passport
2. Age over X from UK driving license
3. Age over X from EU driving license
4. Age over X from EU National ID card

Is that the direction we're talking about going?

Where it gets particularly fun is that there's a whole second set of documents that can be used if the user doesn't have one from the above four:

1. Adoption certificate
2. Biometric Home Office photo ID
3. Birth certificate
4. Disclosure and Barring Service certificate (DBS)
5. Global or European Health Insurance Card
6. Gender Recognition Certificate
7. Ministry of Defence Form 90 (Defence Identity Card)
8. NHS Medical Card
9. Proof of Age Standards Scheme card
10. UK Marriage certificate which states applicant's date of birth
11. UK Naturalisation Certificate
12. Biometric Home Office photo ID
13. Ministry of Defence Form 90 (Defence Identity Card)
14. Proof of Age Standards Scheme card

If we assume all those things eventually become digital credentials, then we're looking at 18 request types just to cover the UK over 18 use case. Or potentially (if it turns out there's some standardised list of documents usually used for this in the UK) 1 huge query that could return any of those things but potentially places a burden on all verifiers to support all 18 credential types. Or maybe there's some "covers 90% of verifiers & users" cases to try and keep things simple.

[simoneonofri]

I was thinking about that this morning, since I was also reading that in some states to verify age it's permissible to use even expired documents. Wouldn't it also make sense to include like student IDs from recognized universities?

Other than that, @npdoty what do you think about privacy/discrimination side?

[timcappalli]

Discussed at the 2024-06-21 hybrid meeting (raw notes).

AI Generated Summary (Google Gemini)

This discussion is about how to handle different types of credential requests and how much information to show users about those requests. There are a few key points:

• Balancing Risk and Friction: Finding the right balance between informing users about potential privacy risks and making the credential selection process smooth is a challenge.
• Standardization vs Flexibility: There is debate about how much to standardize how credential requests are presented to users. Some argue for a common approach, while others believe browsers should be able to innovate in their UIs.
• Context Matters: The appropriate way to handle credential requests depends on the specific context, such as the regulatory environment and the type of credential being requested.
• Role of Wallets: Wallets are expected to play a role in protecting user privacy by potentially filtering requests or providing additional information to the user.

Next Steps: The group will continue this discussion to figure out how to move forward.

[Sakurann]

I think, currently, the request type layer (e.g. Presentation Exchange) is de facto part of the protocol layer (e.g. OpenID4VP) and at least in openid4vp, it is totally possible to define a static presentation_definition (or equivalent of such in a new query language) that stands for "requesting age attestation [in any format/in credential format A]" and can be passed using a static scope value. could that be a solution to this issue?

[timcappalli]

@samuelgoto how did you want to proceed with this one?