3 ms·

presumably you'd just use unique one time codes derived from the eID

by taminka 8mo ago

voxic11 8mo ago
I fail to see how that solves the problem? That's what I'm saying my service would provide. Unless the eID has some kind of client side rate limiting built in I can generate as many of them as I want. And assuming they are completely privacy preserving no one can tell they were all generated by the same ID.
- ongy 8mo ago
  You could do some scheme that hashes a site specific identifier with an identifier on the smart element of the id. If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.
  - hparadiz 8mo ago
    People do, in fact, have multiple profiles. For very valid reasons.
    - voxic11 8mo ago
      the solution to this seems to be to issue multiple "IDs". So essentially the government mints you a batch of like 30 "IDs" and you can use each of those once per service to verify an account (30 verified accounts per service). That allows for the use case of needing to verify multiple accounts without allowing you to verify unlimited accounts (and therefor run into the large scale misuse issue I pointed out). If you need to verify even more accounts the government can have some annoying process for you to request another batch of IDs.
      - hparadiz 8mo ago
        This is a solved problem in the authentication space. Short lived tokens backed by short lived keys. A token is generated that has a timestamp and is signed by a private key with payload. The public key is available through a public api. You throw out any token older than 30 seconds. Unlimited IDs. That's basically what you want.
        ongy 8mo ago
        Which either allows to use a fingerprint of the signing key to be used for the same. Or would open the system up to the originally posted attack of providing ~an open relay.
- petu 8mo ago
  https://github.com/eu-digital-identity-wallet/av-doc-technical-specification/blob/main/docs/architecture-and-technical-specifications.md https://github.com/eu-digital-identity-wallet/av-doc-technic... > Since Proof of Age Attestations are designed for single use, the system must support the issuance of attestations in batches. It is recommended that each batch consist of thirty (30) attestations. It sounds like application would request batch of time-limited proofs from government server. Proofs gets burned after single use. Whether or not you've used any, app just requests another batch at a set interval (e.g. 30 once a month). So you're rate limited on the backend. Edit: seems like issuing proofs is not limited to the government, e.g. banks you're client of also can supply you with proofs? (if they want to partake for some reason). I guess that would multiply numbers of proof available to you.
  - deleted 8mo ago
    [deleted]
  - voxic11 8mo ago
    Ok I have been convinced this is a technically feasible solution that could preserve privacy while reasonably limiting misuse. That said I'm worried that the document you linked does not require relying parties implement the zero knowledge proof approach. It only requires that they implement the attestation bearer token approach which is much weaker and allows the government to unmask an account by simply asking the relying party which attestation token was submitted to verify the account. > Relying Party SHALL implement the protocols specified in Annex A for Proof of Age attestation presentation. > A Relying Party SHOULD implement the Zero-Knowledge Proof verification mechanism specified in Annex A

presumably you'd just use unique one time codes derived from the eID

by taminka 8mo ago

presumably you'd just use unique one time codes derived from the eID

I fail to see how that solves the problem? That's what I'm saying my service would provide. Unless the eID has some kind of client side rate limiting built in I can generate as many of them as I want. And assuming they are completely privacy preserving no one can tell they were all generated by the same ID.

ongy 8mo ago
You could do some scheme that hashes a site specific identifier with an identifier on the smart element of the id. If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.
- hparadiz 8mo ago
  People do, in fact, have multiple profiles. For very valid reasons.
  - voxic11 8mo ago
    the solution to this seems to be to issue multiple "IDs". So essentially the government mints you a batch of like 30 "IDs" and you can use each of those once per service to verify an account (30 verified accounts per service). That allows for the use case of needing to verify multiple accounts without allowing you to verify unlimited accounts (and therefor run into the large scale misuse issue I pointed out). If you need to verify even more accounts the government can have some annoying process for you to request another batch of IDs.
    - hparadiz 8mo ago
      This is a solved problem in the authentication space. Short lived tokens backed by short lived keys. A token is generated that has a timestamp and is signed by a private key with payload. The public key is available through a public api. You throw out any token older than 30 seconds. Unlimited IDs. That's basically what you want.
      - ongy 8mo ago
        Which either allows to use a fingerprint of the signing key to be used for the same. Or would open the system up to the originally posted attack of providing ~an open relay.
petu 8mo ago
https://github.com/eu-digital-identity-wallet/av-doc-technical-specification/blob/main/docs/architecture-and-technical-specifications.md https://github.com/eu-digital-identity-wallet/av-doc-technic... > Since Proof of Age Attestations are designed for single use, the system must support the issuance of attestations in batches. It is recommended that each batch consist of thirty (30) attestations. It sounds like application would request batch of time-limited proofs from government server. Proofs gets burned after single use. Whether or not you've used any, app just requests another batch at a set interval (e.g. 30 once a month). So you're rate limited on the backend. Edit: seems like issuing proofs is not limited to the government, e.g. banks you're client of also can supply you with proofs? (if they want to partake for some reason). I guess that would multiply numbers of proof available to you.
- deleted 8mo ago
  [deleted]
- voxic11 8mo ago
  Ok I have been convinced this is a technically feasible solution that could preserve privacy while reasonably limiting misuse. That said I'm worried that the document you linked does not require relying parties implement the zero knowledge proof approach. It only requires that they implement the attestation bearer token approach which is much weaker and allows the government to unmask an account by simply asking the relying party which attestation token was submitted to verify the account. > Relying Party SHALL implement the protocols specified in Annex A for Proof of Age attestation presentation. > A Relying Party SHOULD implement the Zero-Knowledge Proof verification mechanism specified in Annex A