in australia, we have various credentials provided by the government to attest to a persons fitness to work with children (i’ll just refer to these in bulk from now on as WWCC: working with children checks). there are many of these - one per state for individuals, plus teacher’s accreditations per state, and a few more. they’re ongoing certifications, so can be revoked if anything happens
it’s a legal requirement for businesses who engage in activities involving kids to ensure anyone they employ - including volunteers - is appropriately vetted
needless to say, this gets quite complex for national organisations!
i was the engineering lead for a startup that organisations could add their workforce into the system, with the credentials, and the system checked periodically to check that everyone’s credentials are valid, about to expire, etc and notify people if something goes awry
of course, that doesn’t need blockchain BUT
in cases of child sexual abuse, things tend to only come out after 30+ years on average (according to the royal commission into institutional responses to child sexual abuse). organisations need to be able to prove that they were doing everything they possibly could to protect the kids under their care. 30 years on that’s no small task! our company might not even exist in 30 years!
along with our automated checks, we also published an event to the eth blockchain: a hash of the card details as an index (ie if you know the card details, you can look up all instances of validation), and a hash that proves the check took place
what’s that hash? well, i won’t get too into the weeds but essentially we push a payload to IPFS which contains:
a link to a kind of “template” of an HTTP archive for a typical request to the validation service
a diff that allows you to reconstruct the HTTP archive of this instance of the request given the original template
various pieces of the HTTPS handshake with the validation service that allow you to essentially validate after the fact that the content of the HTTP archive was exactly what the validation service sent at the time - HTTPS is essentially signed information after all, so we have a chunk of HTML attesting to the validity of a card that’s been signed by the government! cryptographic proof - not just “take my word for it”
we also published a page on IPFS that allows people to enter card details and load all this information and produce all the technical details to prove what happened (we also had plans for some kind of hardware pack with pinned versions of things because browsers and technology change)
you might be able to do this by relying on the date header that the server sends, but to be really sure, writing the hashes to the blockchain proves that the event given happened at a very specific time and date
blockchain shouldn’t be big and flashy: it’s a very niche use-case, but for those niches there’s really nothing like it
i’ll give it a crack
in australia, we have various credentials provided by the government to attest to a persons fitness to work with children (i’ll just refer to these in bulk from now on as WWCC: working with children checks). there are many of these - one per state for individuals, plus teacher’s accreditations per state, and a few more. they’re ongoing certifications, so can be revoked if anything happens
it’s a legal requirement for businesses who engage in activities involving kids to ensure anyone they employ - including volunteers - is appropriately vetted
needless to say, this gets quite complex for national organisations!
i was the engineering lead for a startup that organisations could add their workforce into the system, with the credentials, and the system checked periodically to check that everyone’s credentials are valid, about to expire, etc and notify people if something goes awry
of course, that doesn’t need blockchain BUT
in cases of child sexual abuse, things tend to only come out after 30+ years on average (according to the royal commission into institutional responses to child sexual abuse). organisations need to be able to prove that they were doing everything they possibly could to protect the kids under their care. 30 years on that’s no small task! our company might not even exist in 30 years!
along with our automated checks, we also published an event to the eth blockchain: a hash of the card details as an index (ie if you know the card details, you can look up all instances of validation), and a hash that proves the check took place
what’s that hash? well, i won’t get too into the weeds but essentially we push a payload to IPFS which contains:
we also published a page on IPFS that allows people to enter card details and load all this information and produce all the technical details to prove what happened (we also had plans for some kind of hardware pack with pinned versions of things because browsers and technology change)
you might be able to do this by relying on the date header that the server sends, but to be really sure, writing the hashes to the blockchain proves that the event given happened at a very specific time and date
blockchain shouldn’t be big and flashy: it’s a very niche use-case, but for those niches there’s really nothing like it