I'm not sure we could encrypt codes for them as we would not have their private key? I think we could provide an CLI executable that could make it really easy, though. on virtually any OS (the benefits of Go!)...
Also, I agree on the advertising but it's not a deal breaker for me if they did. I think that the ability of the manufacturer to provide additional info about that bottle, e.g., expiration date, place of manufacture, counter indicators and drug interactions, user instructions and self-help videos, etc., would be quite useful and beneficial to the end users? I'm not sure why we would need to involve distributors? Maybe you can explain that idea more? If the code is on the bottle, how would it matter what distributor delivers it, assuming it's a somewhat tamper-proof bottle? Cheers! Frank On Tuesday, December 26, 2017 at 11:03:22 AM UTC-5, matthe...@gmail.com wrote: > > For implementation I’m of the opinion that we should own everything > besides printing the labels. There is only the one path of data between the > consumer and our server+database in a cloud center. We nor the > manufacturers should be able to advertise to consumers through this, and > consumers should be able to understand the barcode no matter what chain got > it to them. We have to build consumer trust for these barcodes to matter. > > I live in the USA, but the report centers around Kenya. If we’re not > talking about one government then handling regulation is a key and large > part of this project. If we’re working in more than one country we’ll need > to have language translation done. I still think we need a connected > partner organization that's done such things before. > > Even the manufacturers and distributors may have a limited connection to > our servers. What kind of operating systems are these people using to print > labels? We can’t be a manufacturing bottleneck, so perhaps we’d need to > provide blocks of barcodes instead of individually requested ones. Perhaps > a worker goes somewhere else and walks in a drive with the barcodes. > > That barcode library seems not done - we’ll probably need to support our > own. I assume this will be open source and those using the system will want > to review the code. > > Here’s my take on the process: > > 1. Manufacturer asks us for a barcode block targeting a distributor for a > product > 2. We generate that number of PNG barcodes containing individual UUIDs > that in our database is matched to a product ID, manufacturer ID, and > distributor ID > 3. Manufacturer downloads the block and applies the images to their label > printing process > 4. Distributor scans a subset of these barcodes and for each sends us a > verification request with the scanned UUID and the three IDs independently > provided > 5. We mark each as distributor scanned in our database, and now we know a > block has at least some scanned, or we indicate to the distributor that > there’s a problem > 6. Distributor distributes product with original manufacturer’s barcode > intact, scanned or not > 7. Consumer uses our app to scan the barcode, and we then tell them if the > distributor verified part of the block, if it has been previously scanned > by a consumer, who the distributor is, what the expected product is, and > who made it, all of which can be compared to the label. > > Matt > > On Tuesday, December 26, 2017 at 9:00:17 AM UTC-6, Frank Davidson wrote: >> >> Yes, that's the Aztec library I saw for creating the codes. Looking now >> for a good OS library for reading them... >> >> I'm thinking the sequence would go something like this: >> >> >> 1. Manufacturer creates key pair >> 2. They register their public key with our central server >> 3. The public key is posted on a URL REST endpoint on their certified >> domain >> 4. They download our code/library which enables them to create unique >> Aztec codes at manufacturing speed signed with their public key >> 5. The Aztec code payload would be JSON containing the above >> mentioned URL, by default a UUID, and any other metadata they would have >> the space to include. The payload would be signed with their ECDSA >> signature. >> 6. That unique Aztec code gets, ideally, printed on an individual >> bottle but could also maybe be code for a shipment or pallet or some >> other >> grouping if individual bottles are cost prohibitive for some manufacturers >> 7. An individual or small pharmacy upon receipt of the drugs would >> scan the Aztec code in our "App" or website >> 8. If the signature checks out they are forwarded to the URL in the >> JSON payload >> 9. The cert of the domain is verified >> 10. The rest of the JSON payload is relayed to the manufacturer. >> 11. The manufacturer can then track the individual bottle and/or >> offer other info/services to the individual user. >> >> Thoughts, comments, and criticisms welcome! >> >> Frank >> >> >> On Monday, December 25, 2017 at 4:46:49 PM UTC-5, Tamás Gulácsi wrote: >>> >>> https://github.com/boombuler/barcode is a MIT licensed Aztec code >>> generator. >>> >>> You'll have to become a trusted central authority for the drug companies >>> - or at least provide the infrastructure for the government to force such a >>> central registry for uuids and public keys. >>> >>> I think here the technical solution is almost ready, you have to >>> assemble already existing components. The bigger problem is to build the >>> concept and make a lot of important people accept it. >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
