jeroenlicht
commented
8 years ago Now I thought about it some more, a 'verify_url' would also implicitly allow changing email address at the issuer, and assigning multiple email addresses to one badge, since the issuer can simply reply "1" to any of a number of email addresses. But furthermore, it doesn't have to be limited to email only. It could also be other data that can be confirmed with a direct channel to the recipient, such as: 1) A phone number (using text/phone verification by the displayer). This can be useful for recruiters who prefer to contact a candidate by phone 2) A home address (having a badge displayer send a verification code through the post once). This can be useful for job applications where correspondence is done by post (though the recruiter would need to send some verifiable data to the participant by post, so I'm not sure how practical this would be in a real recruiting scenario). 3) A bank account (having a badge displayer deposit a tiny random amount once, for verification). This may be useful for job promotions, where the employer already knows the bank account of the badge recipient, since they are paying them already.
When uploading a new badge to the displayer, the displayer can then check all the different verified data they have of the participant, and show next to each badge which type of verification is available. And possibly allow a recruiter to verify this him-/herself by entering the data they have of the job participant into a form field on the badge collection page.
timothyfcook
Currently, the only possible IdentityType is "email", which can be hashed for protecting the identity of the recipient and the abuse of their email address. I see two problems with this: 1) With the hash+salt publicly available, an attacker can easily do a brute force attack. 2) Even with a long salt, the security of the hash depends on the length of a person's email. The effective entropy of the hash for a person with an email like 'joe92@gmail.com' is 36^5 (less than 61 million). This is very easily broken.
Since the issuer's server already has to be contacted to verify a digital badge anyway, we could also let the issuer's server verify the email address. So there could be an identity type "email_verify_url", on a secure server, to which the email is submitted as a get request, and then returns 1 if the email is correct, 0 if the email is incorrect, or a HTTP status '503 Service Unavailable' when an attack is suspected. The issuer can then put extra security measures on this, such as limiting the amount of requests that can be made for the same badge, per hour.