On Mon, Dec 23, 2024 at 6:17 AM Joseph Heenan <jos...@authlete.com> wrote:
> Hi > > On 22 Dec 2024, at 20:35, Watson Ladd <watsonbl...@gmail.com> wrote: > > The fact that you and everyone else feels content to shoot down text > rather than try to meet me halfway shows that this isn't an honest > attempt to achieve rough consensus or conversely say my views are in > the rough because of actually thinking through the issue. I've been > consistent in raising this issue for over a year: to pretend that the > WGLC is at all relevant to where we are is a ridiculous excuse made > possible only by your own inaction on this issue. I've tried to tweak > the text to make it work better, at length, but it's very hard when > people say they have concerns without being clear or suggesting > alternatives. I'd appreciate you doing me the same courtesy, rather > than sitting back and saying "nah, no one agrees enough for us to > handle it". I agree that my text may be too limiting or overly > prescriptive, but the people closer to the problem need to provide > input if there is going to be a text we can live with. > > > I believe much of this goes back to something you said earlier - that you > believe (based on your suggested normative text and your explanation > thereof) it should be mandated to use less privacy preserving technologies > instead of SD-JWT in some cases. You are of course welcome to hold that > opinion, but it seems it is not reflected in the working group consensus. > That's the conclusion. The argument that leads to that is that 1) users need to be aware of the consequences of sending data, and that 2) if it isn't actually as anonymous as they expect they might send it and wish they hadn't. 3) We should not do this, 4) therefore SD-JWT shouldn't be used in those cases. I think we have agreement on 1: it's present in the current text but not very explicit. I don't think we really disagree on 2. 3 is probably the point of contention. I'm happy to avoid getting into point 3, but we definitely need to clearly address 1 and 2. Do we all agree on those? And right now we don't have a clear statement. > I don’t think it is helpful to repeatedly make very similar proposals > whilst ignoring the feedback on why that proposal is inappropriate, nor > does it look like trying to meet halfway - this current proposal and > discussion is very similar to, for example, > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448/files > The objection Brian made to the PR was that it deleted text, not that the recommendation was too strong. > Whilst I am not saying this is what is deliberately happening here, > suggesting text that is overly strict in the hopes of ‘meeting halfway’ is > not usually an appropriate strategy in standards development. In my view > the general expectation is that text proposed should be a genuine attempt > to document the consensus of the working group. > > The authors appear to have tried to address your concerns, > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/451 was a > response to try and address the underlying issue the above PR was trying to > address. > > Secondly the verifier-verifier unlinkability > really doesn't have much in the way of actual mitigations: it says you > can use one-use credentials, etc. but doesn't mandate, provide > designs, explain how to issue based on a previous credential etc. It > at least has that material. > > > Issuing credentials (including how to do batches and re-issuance) is out > of scope for the SD-JWT specification itself (in the same way issuing a JWT > is out of scope for the JWT specifications) and already dealt with in, for > example, https://github.com/openid/OpenID4VCI > > To be absolutely clear, this is what the current text says in its most > relevant section "In considering Issuer/Verifier unlinkability, it is > important to note the potential for an asymmetric power dynamic > between Issuers and Verifiers. This dynamic can compel an otherwise > honest Verifier into collusion. For example, a governmental Issuer > might have the authority to mandate that a Verifier report back > information about the credentials presented to it. Legal requirements > could further enforce this, explicitly undermining Issuer/Verifier > unlinkability. Similarly, a large service provider issuing credentials > might implicitly pressure Verifiers into collusion by incentivizing > participation in their larger ecosystem. Deployers of SD-JWT must be > aware of these potential power dynamics, mitigate them as much as > possible, and/or make the risks transparent to the End-User." > > That text has a lot of problems: > > - It presents the issue as one of coercion or malfeasance, rather than > e.g. excessive logging, or some other information leak letting the > issuer see what the verifier knows. > > > I think this is covered by > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-14.html#section-10.2 > ? > If not “leaking SD-JWTs to anyone is problematic for privacy" seems like a > specific thing that can be addressed. > Ok, I think what we need then (for this particular one) is a sentence reiterating that 10.2 applies and says relevant things. That's much more editorial than a substantive change IMHO, but I think would help. I still have concerns with the way this paragraph approaches the thinking satirized in 3514. > > - It says deployers must mitigate the power dynamics, rather than use > technical means, with no real guidance as to what that mitigation > looks like > > > I don’t think there have been any proposals of technical means that can > prevent this today? > I'm not really sure what "this" is. If it's power dynamics, then that's all the more reason not to frame the problem that way if there isn't a way to do it. Alternatively one could interpret this as a call to world revolution. I'm not sure that was quite what was meant. I think we all agree that BBS would solve the underlying disclosure issue, in which case I'm not sure how you can say it's not been proposed. > - It doesn't say what the risks are that must be made transparent > > > Various risks are explained in the prior 4 paragraphs. Does changing > “risks” to “risks as describe above” help? > Somewhat. But it isn't clear to me what transparent is supposed to mean, or how making a risk transparent mitigates it. I think what was intended was something similar to what I am proposing we add: that the user act in such a way that they are making the choice they would make if they thoroughly understood the risk. To the extent that's the case, I do still think we need to make changes to make that clearer. > > It's not something that someone can use to say "no, we shouldn't do X" > for any X. > > All I've been asking to add now is a specific example of what a user > might need to know and that if this can't be achieved, don't use > SD-JWT. I'm surprised by the enormous pushback to this. All I want to > know is is there some form of this we could live with, or what are the > concrete issues people have with the proposal. So far I've gotten that > actually naming mitigations is a problem. How on earth do I work with > that? > > > Naming possible mitigations is fine as far as I know - naming a single > possible mitigation (which is impractical in some cases) with a ‘MUST’ is > however problematic. (e.g. "MUST analyze the consequences for such linkage > with each > credential that could be used” as per your first email in this thread.) > I don't understand how you can complain about that sentence and then say we need additional mitigations added. To add them requires choosing which one, which depends a lot on the credentials and usecase. So that analysis is always going to be required. It can't really be a blanket one because it depends on the fields and what's revealed. I'm happy to change the to MUST NOT to a SHOULD and add in additional mitigations: do you have any in mind as particular ones to add? > > Conversely, if you think age verification with SD-JWT is fine, save me > the time and let me know. > > > I believe I've said that, including in your PR I linked above: there are > situations where SD-JWT is the best currently available deployable > technology for a user disclosing their age to a verifier, and yes, it is > absolutely appropriate to use the best currently available deployable > technology to solve a real world problem. Yes, in some situations it can’t > achieve issuer-verifier unlinkability, but in those situations it can still > achieve better data minimisation than alternative technologies. Maybe in > the future we will have better solutions available and at that point it > might be appropriate to start adding stronger text. > It took me 3 days to write a (partial, not terribly flexible) BBS implementation. What's your excuse for saying it isn't "available"? And procedurally we can't really go back and add stronger text here: this will become an RFC that doesn't change. We need to document the shortcomings of the solution we have today, even if they are not solvable. The absence of alternatives doesn't change what the issues are. To the extent this standard is in a bigger ecosystem we need to say what the rest of that ecosystem has to do in this one. > A presentation where only a date of birth is disclosed is an example > explicitly mentioned in the specification too. > > I’m deliberately avoiding the term ‘age verification’ there as I think > you’re trying to use it to describe some fairly specific situation that > hasn’t been defined - I’m not sure whether a stronger statement is possible > about the specific case of age verification you seem to be thinking of, as > I’m not clear on what that case is, and as I said in my 1st August comment > “age verification” is an overly generic term that incorporates a large > number of very disparate use cases. > The usecase I think is most problematic is when people are asked to demonstrate they are over a certain age to access a website that otherwise is anonymous. One of the particularly problematic parts is that the privacy we're assuming would enable this actually creates another persistent tracking vector. To the extent this is going to be an issue for W3C, we need verbiage here flagging that issue for there, particularly for people who aren't intimately familiar with the tech. Sincerely, Watson > > Joseph > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > -- Astra mortemque praestare gradatim
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
