• JoeMontayna@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    2 days ago

    Yes but how does that prevent the authority, in this case a govenment, from being able to link the token that was used (QR code) back to what it was used for?

    • Alaknár@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 days ago

      Depends on how you create it. It could be set up that your app talks to the website, and the identity provider, but the identity provider never talks to the website. As in: you get a token from the IP, store it locally, send it out to he website, the website confirms retrieval and logs you in, and then all the logs get purged on your device so they can’t be retrieved.

      The IP side would only see that someone has requested access to some of your data (e.g. proof of age, proof of human, maybe citizenship, if the content is region-locked), and that you have agreed to share it.

      The website would only see the tokens of proof, but not who you actually are.

      Ironically, the tech behind NFTs might be super helpful with this.

      • JoeMontayna@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        2 days ago

        If I am understanding this correctly, I guess the only problem I see with that is both entities need to trust that the user is indeed being truthful and not sharing a token. I think a system with a neutral third part that takes a token from the identity provider and a token from the webite, validates them and sends a result. Or maybe that is what you said.

        • Alaknár@sopuli.xyz
          link
          fedilink
          arrow-up
          1
          ·
          2 days ago

          Yeah, that’s essentially what I meant. The validation could happen much like with PGP keys and passwords.