Email not validated in DevCon flow
jot2re opened this issue · 8 comments
The user's email is not validated by attestation.id when issuing attestations based on a magic link. I.e. the ticket issuer is trusted to implicitly do the validation through the secret in the magic link.
See section 2.2.5 in the Token-negotiator report.
See (Jira issue 291)[https://smarttokenlabs.atlassian.net/browse/PR-291].
@weiwu-zhang as far as I have understood from you, this issues goes against both the scope of what we want of attestation.id, but it also goes against the threat model.
However, this greatly increases usability and I think it might be "won't fix" issue. Can you confirm if this is the case or not?
@jot2re , we dont use attestation by magic link nomore, because it generate valid emailAttestation and user can use this emailAttestation for other projects and it means that one-time magicLink lead leads to forever emailAttestation compromise.
in case if we need emailAttestation based on magicLink then we need to limit emailAttestation per token and this need to share tokens schema/keys with attestation.id, but attestation.id should stay separate independent project.
@weiwu-zhang , am I right?
Won't fix until DevCon is over.
@weiwu-zhang as far as I have understood from you, this issues goes against both the scope of what we want of attestation.id, but it also goes against the threat model. However, this greatly increases usability and I think it might be "won't fix" issue. Can you confirm if this is the case or not?
Wont' fix till DevCon is over.
@weiwu-zhang , devcon confirmet to use OTP email confrmation, so we dont use magicLink attestation in our projects at the moment. Is it OK?
cc @AW-STJ
@jot2re , we dont use attestation by magic link nomore, because it generate valid emailAttestation and user can use this emailAttestation for other projects and it means that one-time magicLink lead leads to forever emailAttestation compromise.
@oleggrib my understanding was that the attestation validity was still time restricted to 1 hour or 1 day (at least it was the case the last time I went through the attestation.id flows). Is that not the case anymore? Or do you simply mean that because the user has access to the magic link, they can always construct a new email attestation?
@oleggrib my understanding was that the attestation validity was still time restricted to 1 hour or 1 day (at least it was the case the last time I went through the attestation.id flows). Is that not the case anymore?
current emailAttestations with Auth0 flow has TTL 1 month,
Or do you simply mean that because the user has access to the magic link, they can always construct a new email attestation?
yes, exactly, this is why we dont use it. @jot2re
No longer relevant; has been fixed. Closing the issue.