My thought is we'd just be a source of UUIDs. The request for a barcode block would be verified with keys, but the barcodes have no cryptography besides us solely holding what is associated with the UUID. The manufacturer would have the ability to track that information too if they chose to though.
That additional metadata does take bandwidth, and not all consumers have excess bandwidth available. The absolute minimum amount of data may be helpful for some people. Perhaps we can provide manufacturer-specific links to their product information in the success request, but we control that just being a URL instead of a pre-loading auto-playing flash video player or large images or other such data. According to the report the distributors sometimes do chemical tests on incoming medication. Some products may be individually packaged, others may be in a large bottle for the pharmacy to individually distribute which is a case I didn’t consider. But the distributor seems to be a key point of trust in the chain that does what they will with the medication packaging, so providing distributor information to a consumer may help them pick pharmacies that use trusted distributors. Perhaps we could provide pharmacies with barcodes for when they repackage medication. Porting zxing to Go seems like a fun and good project for us to do together. Like the Google CLA with the Go source we’d need an agreement for contributors - perhaps we retain our copyright but allow licensing only under the Apache 2.0 license? Matt On Tuesday, December 26, 2017 at 10:42:34 AM UTC-6, Frank Davidson wrote: > > Might make sense to port https://github.com/zxing to Go? Seems a popular > library and I think it was created by Google folks. > > On Tuesday, December 26, 2017 at 11:29:44 AM UTC-5, Frank Davidson wrote: >> >> 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.
