4 ms·

It can't be quite that simple because you have a couple additional problems to solve - (effectively restating bits of the article poorly and partially) 1. You

by hirsin 7mo ago

It can't be quite that simple because you have a couple additional problems to solve - (effectively restating bits of the article poorly and partially) 1. You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else). 2. You don't want the government to know which website you're going to, nor allow the government and the website to collaborate to deanonymize you (or have the government force a website to turn over the list of tokens they got). So the government can't just hand you a uuid that the website could hand back to them to deanonymize. The SD JWT and related specs solve for these, which is how mDL and other digital IDs can preserve privacy in this situation.

Izkata 7mo ago
But one overlooked advantage of manually copying JWTs is that the user doesn't have to blindly trust they're not hiding extra information. They can be decoded by the user to see there's only what should be there.
AnthonyMouse 7mo ago
> You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else). But these are the things that make it non-anonymous, because then instead of one token that says "is over 18" that you get once and keep forever, everyone constantly has to request zillions of tokens. Which opens up a timing attack, because then the issuer and site can collude to see that every time notbob69 signs into the website, Bob Smith requested a token, and over really quite a small number of logins to the site, that correlation becomes uniquely identifying. Meanwhile we don't need to solve it this way, because the much better solution is to have the site provide a header that says "this content is only for adults" than to have the user provide the site with anything, and then let the user's device do what it will with that information, i.e. not show the content if the user is a minor.
- hirsin 7mo ago
  Which is why you separate the credential issuance from the credential use, per the standard mentioned.
  - AnthonyMouse 7mo ago
    The cryptography provides nothing to establish that this separation is actually being maintained and there is plenty of evidence (e.g. Snowden) of governments doing exactly the opposite while publicly claiming the contrary. On top of that, it's a timing attack, so all you need is the logs from both of them. Government gets breached and the logs published, all the sites learn who you are. Government becomes corrupt/authoritarian, seizes logs from sites openly or in secret (and can use the ones from e.g. Cloudflare without the site itself even knowing about it), retroactively identifies people.
    - hirsin 7mo ago
      I'd review the setup here. You're missing the critical distinction that the cryptography supports - separating entirely (in time and space) the issuance of the cred to the user and the use of that cred with a website. Unless you're getting the device logs from the users device (in which case... All of this is moot) there is no timing attack. Six months ago you got your mobile drivers license. And then today you used it to validate your age to a website anonymously. What's the timing attack there.
      - AnthonyMouse 7mo ago
        If the driver's license can generate new anonymous tokens itself then anyone can hook up a driver's license to a computer and set up a service to sign for everybody. If it can't, whenever you want to prove your age to a service you need to get a new token from a third party, and then there is a timing correlation because you're asking for the token right before you use the service. The article proposes a hypothetical solution where you get some finite number of tokens at once, but then the obvious problem is, what happens when you run out? First, it brings back the timing correlation when you ask for more just before you use one, and the number of times you have to correlate in order to be unique is so small it could still be a problem. Second, there are legitimate reasons to use an arbitrarily large number of tokens (e.g. building a search index of the web, content filters that want to scan the contents of links), but "finite number of tokens" was the thing preventing someone from setting up the service to provide tokens to anyone.
nijave 7mo ago
Imo these are nice to haves. The physical system of ID cards already has these problems but works well enough. People can loan their ID to someone else (ask college kids with an older sibling...) When you use your physical ID, the government frequently can deanonymize you either through automated databases (especially when purchasing drugs) or subpoenaing for camera footage, visitor lists, etc

by hirsin 7mo ago

Izkata 7mo ago

But one overlooked advantage of manually copying JWTs is that the user doesn't have to blindly trust they're not hiding extra information. They can be decoded by the user to see there's only what should be there.

AnthonyMouse 7mo ago

> You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else). But these are the things that make it non-anonymous, because then instead of one token that says "is over 18" that you get once and keep forever, everyone constantly has to request zillions of tokens. Which opens up a timing attack, because then the issuer and site can collude to see that every time notbob69 signs into the website, Bob Smith requested a token, and over really quite a small number of logins to the site, that correlation becomes uniquely identifying. Meanwhile we don't need to solve it this way, because the much better solution is to have the site provide a header that says "this content is only for adults" than to have the user provide the site with anything, and then let the user's device do what it will with that information, i.e. not show the content if the user is a minor.

hirsin 7mo ago
Which is why you separate the credential issuance from the credential use, per the standard mentioned.
- AnthonyMouse 7mo ago
  The cryptography provides nothing to establish that this separation is actually being maintained and there is plenty of evidence (e.g. Snowden) of governments doing exactly the opposite while publicly claiming the contrary. On top of that, it's a timing attack, so all you need is the logs from both of them. Government gets breached and the logs published, all the sites learn who you are. Government becomes corrupt/authoritarian, seizes logs from sites openly or in secret (and can use the ones from e.g. Cloudflare without the site itself even knowing about it), retroactively identifies people.
  - hirsin 7mo ago
    I'd review the setup here. You're missing the critical distinction that the cryptography supports - separating entirely (in time and space) the issuance of the cred to the user and the use of that cred with a website. Unless you're getting the device logs from the users device (in which case... All of this is moot) there is no timing attack. Six months ago you got your mobile drivers license. And then today you used it to validate your age to a website anonymously. What's the timing attack there.
    - AnthonyMouse 7mo ago
      If the driver's license can generate new anonymous tokens itself then anyone can hook up a driver's license to a computer and set up a service to sign for everybody. If it can't, whenever you want to prove your age to a service you need to get a new token from a third party, and then there is a timing correlation because you're asking for the token right before you use the service. The article proposes a hypothetical solution where you get some finite number of tokens at once, but then the obvious problem is, what happens when you run out? First, it brings back the timing correlation when you ask for more just before you use one, and the number of times you have to correlate in order to be unique is so small it could still be a problem. Second, there are legitimate reasons to use an arbitrarily large number of tokens (e.g. building a search index of the web, content filters that want to scan the contents of links), but "finite number of tokens" was the thing preventing someone from setting up the service to provide tokens to anyone.

nijave 7mo ago

Imo these are nice to haves. The physical system of ID cards already has these problems but works well enough. People can loan their ID to someone else (ask college kids with an older sibling...) When you use your physical ID, the government frequently can deanonymize you either through automated databases (especially when purchasing drugs) or subpoenaing for camera footage, visitor lists, etc