> On 21 Dec 2024, at 19:10, Watson Ladd <watsonbl...@gmail.com> wrote: > > On Sat, Dec 21, 2024, 8:26 AM Joseph Heenan <jos...@authlete.com > <mailto:jos...@authlete.com>> wrote: >> >> >> >> On 20 Dec 2024, at 18:07, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> On Fri, Dec 20, 2024 at 9:47 AM Joseph Heenan <jos...@authlete.com> wrote: >> >> >> >> >> On 19 Dec 2024, at 21:54, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> On Tue, Dec 17, 2024, 1:59 PM Joseph Heenan <jos...@authlete.com> wrote: >> >> >> Hi Watson >> >> Just to respond to the suggested text: >> >> >> "When disclosures include information easily understood to be >> identifying, users intuitive view of what they are revealing largely >> matches the underlying technical reality. In cases where the >> information being disclosed is not identifying, SD-JWT >> MUST NOT be used as this confusion leads to users making the wrong >> choices. >> >> >> This sentence is really hard to make sense of and I don’t think implementors >> will understand it. I’m not convinced I understand it even with the extra >> context from the threads. I think a MUST NOT is far too strong too, and >> saying ’SD-JWT’ in particular must not be used it too strong as an SD-JWT >> where everything is disclosed (or no selective disclosures are present in >> the issued credential in the first place) is no different to other >> credentials formats that don’t have selective disclosure. >> >> >> I think this is subsumed by the first sentence. When users are >> disclosing information that wasn't identifying, but the mechanism >> involves transmitting a unique identifier there is a problem. >> >> >> Yes, and that problem is not unique to SD-JWT. We mustn’t try to imply that >> it is specific to SD-JWT or we risk developers getting very confused. > > Why does the language here imply that?
Because it’s specifically saying not to use SD-JWT in some cases. Whereas the current language is more general, talking about, for example, "salted-hash based selective disclosure approaches” as all sharing the same flaws. > And it is unique to SD-JWT in > the sense that the disclosure opening has identifiers that a proper AC > system wouldn't. But it’s not unique to SD-JWT, that’s very much one of my points. The same applies to mdoc, and I’m very sure there are other examples too. Telling people they MUST NOT use SD-JWT is completely pointless if they just decide to use mdoc instead. To my knowledge, we don’t have any AC systems that are actually usable at scale today whilst also meeting important security/usability goals - hence why SD-JWT exists, is important and delivers useful properties even if it’s not perfect in all situations. > We're also not talking about other systems in this > document, even if they should have a similar disclaimer: it's for > those WGLCs to decide. But not all specs are IETF specs. Telling people not to use an IETF spec and by doing so causing them to use a spec from a different SDO (or not from an SDO at all) that has all the same flaws does not help anything and probably makes things worse. >> Would adding "When users disclose information that is not identifying, >> e.g. age, the fact that the mechanism in this draft exposes the unique >> signature of their credential is not obvious. Users could have made >> different decisions if they understood this. Therefore," in the middle >> help? >> >> >> I think that makes it easier to understand, but I disagree with the premise >> - I believe there are likely ways to describe this to users and this needs >> to be properly researched & tested with real people. As I said, the MUST NOT >> is too strong regardless - there are likely cases where the user recognises >> that tracking like this is possible/inevitable, and regardless it seems to >> imply that SD-JWT has worse properties than (for example) JWT based >> credentials, which is something we definitely shouldn’t do. >> >> >> Then when people have demonstrated that they can mitigate the risk, we >> can write a bis. >> >> >> That would seem like complete overkill process wise. The need is to point >> out the risk and let people assess it themselves. As soon as we try to make >> very prescriptive statements about certain cases we run the opposite risk of >> failing to predict all the bad cases and making the overall situation worse. > > Suggest text that does that: the current text does not make clear that > users do not have the right model for their decisions. It's very > prolix and I'm not sure people will realize what it implies. I'm open > to alternatives, but it seems like you disagree with the goals. SD-JWT currently says "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 user.”. You seem to be assuming some particular UX where the user is under-informed, and then adding “MUST NOT”s on the basis of that UX. It is very very easy to come up with a UX where the user is not under-informed - you simply make clear that their (say) whole driving license is being released, perhaps with a caveat that the wallet is making efforts to avoid the verifier learning the values of some fields. Probably not ideal, and it’s likely the best UX will vary for different cultures - I’m sure a bunch of clever people are researching it. >> The point is some mitigation needs to be >> demonstrated. I want to put text in that someone can show their boss >> to say "we shouldn't implement this because we don't have a >> demonstrated, working mitigation for the privacy risks that aren't >> apparent". Do you have alternate ways to document this issue that will >> do that? >> >> >> Yes, the current text in >> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-14.html#section-10.1 >> seems to get across the risk just fine and doesn’t run the risk that your >> suggested text has of developers selecting other equally bad or worse >> solutions instead. > > Its better to reveal the whole credential because that matches user > models better. No, it’s not. It might be better to tell the user they’re effectively revealing the whole credential (see above), but that is very very different from actually revealing the full credential. Unnecessarily revealing the full credential is problematic because it’s the opposite of data-minimisation. > Developers selecting solutions that match people's > models is better than spilling information users didn't realize they > were spilling. Again, you’re starting from an assumption that the user is under informed, an assumption that may well not be true. >> Applications cannot assume Verifiers behave properly (RFC >> 3514) and MUST analyze the consequences for such linkage with each >> credential that could be used." >> >> >> This ‘MUST’ is practically impossible for some implementors - for example, >> it is impractical for a wallet to make this kind of judgement for each >> issued credential. >> >> >> >> Bingo! Wallets that use SD-JWT can't give users the control over their >> data that we would expect them to have. >> >> >> I don’t think you have shown this very generalised statement is true, nor >> that if it was true that it only applies to wallets using SD-JWT. >> >> The wallet needs to be aware >> of how the requests impact user privacy. >> >> >> The wallet doesn’t need to be aware if it is clear to the user from the >> context (and perhaps there are other cases too where the wallet doesn’t need >> to be aware). The MUST NOT is too strong, and I’m not sure even a SHOULD NOT >> would be appropriate. >> >> >> Somebody has to look out for the user here. In the web its why we call >> it a User Agent. >> >> >> I’m unsure what kind of point you’re trying to make here, but the user agent >> as defined by w3c isn’t required to ‘look out’ for the user: >> https://www.w3.org/WAI/UA/work/wiki/Definition_of_User_Agent >> >> The suggested text is again overly prescriptive and that is a bad thing that >> is likely to have unintended consequences. > > What consequences do you see that are worse than people trusting this > mechanism and ending up in trouble because of it? If you add a ‘MUST NOT’ or similar there is a risk that people will implicitly assume that all cases that aren’t included in the ‘MUST NOT’ are fine. >> If the Wallet isn't going to be capable of doing >> that, what will? What is "clear to the user from the context"? In the >> case of age verification it really isn't clear what exactly is being >> revealed. >> >> >> If I’m presenting the age part of my government issued credential to a >> verifier in some countries in the world, I’m quite clear that the government >> is already fully tracking what’s going on and knows who am I, what I’m doing >> and who I’m presenting the credential too - probably particularly in the >> case I’m doing so in person. That doesn’t mean I should be forced to use >> non-SDJWT technologies that would also reveal my identity directly to the >> verifier. > > Have you ever been to a gay bar? Showing the bouncer your ID does not > mean anyone knows you've been there. Huh? The bouncer knows, and it’s certainly not unknown for the bouncer to record details of the id one way or another. In some countries the government will know, regardless of whether I present ID or not. > That's kind of important, even > today in some parts of the world and some parts of the queer world. I don’t dispute that, but it’s unrelated to the point I made. You asked when the situation might be clear to the user from context, I gave an example of that and why disclosing a full credential would still be worse. > People will try to use this technology for age verification with > predictable bad results. I think we should put in text that says this > is a bad thing, and I'm not sure if you want to put in an alternative > or think that that's an A-OK application for this. It's not about > SD-JWT or full mandatory disclosure: it's about giving people the > impression SD-JWT is more protective of privacy than it actually is so > that they accept the system vs. not. We need a clear sentence making > clear that application, among others with similar properties, is bad. The current text is clear that there are situations where issuer-verifier linkability can’t be fully prevented. Process wide, I believe if you think the text currently in the specification is inadequate, you need to make a concrete suggestion that doesn’t introduce new problems and hence can gain consensus with working group members. Thanks Joseph
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
