Add initial privacy considerations section for protocol requirements#260
Conversation
There was a problem hiding this comment.
Great work @johannhof , thank you.
I added a requirement and a comment on the unlinkability part.
| </p> | ||
| <p class="issue" data-number="255"> | ||
| Actually write these in the protocol requirements | ||
| </p> |
There was a problem hiding this comment.
| </p> | |
| </p> | |
| <h5> | |
| Sign presentation requests | |
| </h5> | |
| <p> | |
| To ensure the integrity of the submission request and prevent it from | |
| being modified in transit, protocols are required to support and | |
| mandate encrypted requests in a credential exchange. | |
| </p> |
On the one hand, it's a safety issue, but I think it's fine here for now.
There was a problem hiding this comment.
You mean "signed requests" not "encrypted requests", right? Requiring it to be supported makes sense to me, but I don't think it can reasonably be mandated as always required.
There was a problem hiding this comment.
I'm going to punt this on a follow-up issue in the interest of iterating quickly :)
There was a problem hiding this comment.
Actually I guess we have several issues for signed requests, most recently #281
RByers
left a comment
There was a problem hiding this comment.
This seems like a great start to me. I'd be supportive of landing this and iterating.
| </p> | ||
| <p class="issue" data-number="255"> | ||
| Actually write these in the protocol requirements | ||
| </p> |
There was a problem hiding this comment.
You mean "signed requests" not "encrypted requests", right? Requiring it to be supported makes sense to me, but I don't think it can reasonably be mandated as always required.
martinthomson
left a comment
There was a problem hiding this comment.
Thanks for starting here. Looking at this, I'm further convinced of a few high-level points.
Overall, I have a preference for an API that only claims to provide identifiable information. That is, we do not seek to solve trait-based authorization flows, such as age verification, with this API. That is because the set of requirements that apply to those cases are fundamentally different to those that involve identification.
Attempting to address both makes the set of privacy considerations here conflicted. We have unlinkability requirements and revocation requirements that conflict. Of course, none of that nuance can be reflected in this text: it blithely lists unattainable requirements right alongside each other, or elides inconvenient considerations (like issuer-verifier linkability).
The other thing here is that this does nothing to constrain the set of protocols that might be involved. There's a bigger discussion about the relative importance of verifier accountability that this brushes aside, effectively deferring to protocols.
I would be happier with this if there was a clear articulation of the requirement to be able to trace the authorization by which a verifier makes the request for a credential. I realize that this might not be achievable under the current suite of protocols and whatnot, but that's no reason to let this slide.
| track the user. | ||
| </p> | ||
| <h5> | ||
| No dependence on "phone home" mechanisms |
There was a problem hiding this comment.
I wouldn't use the "phone home" colloquialism here, but instead focus on eliminating active involvement by issuers in the creation or validation of presentations.
There are cases where active involvement is acceptable, in particular, where there is necessarily linkability (because the information in the presentation is identifying, usually). That just highlights the conflicted nature of this API.
There was a problem hiding this comment.
Hmm, I don't think this can be a requirement for now then, and we should probably discuss this as part of the unlinkability discussion.
One thing that's important here is that we can't actually enforce unlinkability, in the same way that we can't assume that verifiers and issuers will necessarily collude. My goal was to ensure that protocols offer particularly issuers that want to restrict verifier linkability, and reduce their own exposure to information, the means to do so, but I probably should discuss this more with the group.
| any of the information that is vital for informed permission or | ||
| consent. In particular, this involves granting verifiers the ability | ||
| to pass pertinent information along to the user agent or the wallet | ||
| in an unencrypted, structured text format. |
There was a problem hiding this comment.
I don't think that this is anywhere near sufficient. Let's trace the requirements:
- "European Digital Identity Wallets shall, in particular: (a) support common protocols and interfaces:
[...] (vii) for authenticating and identifying relying parties by implementing authentication mechanisms in accordance with Article 5b;" --> "Member States shall make the information referred to in paragraph 2 publicly available online in electronically signed or sealed form suitable for automated processing." -- https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32024R1183 - The EUDI ARF https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/#6632-wallet-unit-authenticates-the-relying-party-instance shows more phoning home than ET
- openid4vp is better, but its connection to the EUDI ARF is pretty tenuous: "The Verifier Info parameter is optional. Wallets MAY use them to make authorization decisions or to enhance the user experience, but they SHOULD ignore any unrecognized or unsupported Verifier Info types." -- https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-verifier-info
- This document.
The net effect of this is that this is a lack of a clear path for satisfying the requirements, or even for ensuring that the requirements are met. It is my view that verifier validation and authorization is not optional, even if various upstream documents make it optional. This system cannot achieve any reasonable set of accountability goals if random actors can ask for credentials without there being some sort of non-repudiable log that records the fact that they request that information.
"Granting verifiers the ability to pass [..] information [..] unencrypted, structured text format" doesn't cut it. Not even close.
There was a problem hiding this comment.
The view in today's WG call was that the group believed that likely no states, even European member states, would actually require that requesting government-issued credentials be verified in advance or that that information would be available to the user (either via the user agent or the wallet). Although @marcoscaceres in #262 argues that the privacy threats are limited because issuers would enforce pre-registration/verification requirements.
There was a problem hiding this comment.
Yeah I think the best we can do for now is, to Martin's point, mandate that verifier validation and authorization must be readable by the user agent, in case they want to restrict (either entirely disallow or add friction) instances where no or invalid authorization is present.
mohamedamir
left a comment
There was a problem hiding this comment.
Happy to merge this and iterate!
Looks like a great start for me!
Co-authored-by: Mohamed Amir Yosef <mohamed.amir@gmail.com>
44d4346 to
b30743b
Compare
I think I'm with you on not claiming that this API can provide any particular guarantees in terms of unlinkability, and that we should probably declare that all requests through the API are to be considered identifiable by our threat model. With that said, I do believe there are practical implementation differences (it's theoretically possible to do ZKPs even if we can't verify it), that will be relevant for users. I tried to express these things in the considerations but it's a thin line to walk and I'm happy to keep iterating (but would prefer to do that in a follow-up PR).
I filed #281 and also added some text specifically for verifier authorization. It's probably a bit more vague than you'd want it to be, but it's early days for verifier auth systems and we can iterate from the discussion in that issue. |
|
@mohamedamir can you take a quick look and confirm that you're still happy to merge and iterate based on this? Thanks! |
I took another look. (and added some minor comments) |
Co-authored-by: Mohamed Amir Yosef <mohamed.amir@gmail.com>
Co-authored-by: Mohamed Amir Yosef <mohamed.amir@gmail.com>
Co-authored-by: Mohamed Amir Yosef <mohamed.amir@gmail.com>
These have been incorporated into other sections: - Regulation / consent in w3c-fedid#253 and w3c-fedid#260 - Data retention is touched on in w3c-fedid#260 when we talk about encryption, otherwise is, in my opinion, not something we should cover as it is out of scope of the DC API and even protocols. - Selective disclosure / unlinkability are covered in w3c-fedid#260 - Phoning home is covered in w3c-fedid#260
These have been incorporated into other sections: - Regulation / consent in #253 and #260 - Data retention is touched on in #260 when we talk about encryption, otherwise is, in my opinion, not something we should cover as it is out of scope of the DC API and even protocols. - Selective disclosure / unlinkability are covered in #260 - Phoning home is covered in #260 Co-authored-by: Marcos Cáceres <marcosc@apple.com>
I added some descriptions of privacy requirements we probably want normatively listed in the protocol review requirements. @martinthomson @npdoty @simoneonofri - would like to get your eyes on this
I think this is a good way to cover topics like selective disclosure, unlinkability, etc. while making it clear that they're not directly under the control of the DC API. WDYT @npdoty?
Preview | Diff