[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

“The Food and Drug Administration Safety and Innovation Act (FDASIA), 
signed into law on July 9, 2012, expands the FDA’s authorities and 
strengthens the agency's ability to safeguard and advance public health…”

The FDASIA doesn’t seem to have a direct effect on this project, although 
they do define a UFI (unique facility identifier) managed by Dun & 
Bradstreet which may be a useful resource for us.

“The Drug Quality and Security Act (DQSA), was enacted by Congress on 
November 27, 2013. Title II of DQSA, the Drug Supply Chain Security Act 
(DSCSA), outlines steps to build an electronic, interoperable system to 
identify and trace certain prescription drugs as they are distributed in 
the United States. This will enhance FDA’s ability to help protect 
consumers from exposure to drugs that may be counterfeit, stolen, 
contaminated, or otherwise harmful. The system will also improve detection 
and removal of potentially dangerous drugs from the drug supply chain to 
protect U.S. consumers.”

“The following are the major provisions of the Drug Supply Chain Security 
Act (DCSA). These provisions apply to manufacturers, repackagers, wholesale 
distributors, dispensers, and third-party logistics providers as noted 
below:

- Product identification: Manufacturers and repackagers to put a unique 
product identifier on certain prescription drug packages, for example, 
using a bar code that can be easily read electronically.

- Product tracing: Manufacturers, wholesaler drug distributors, 
repackagers, and many dispensers (primarily pharmacies) in the drug supply 
chain to provide information about a drug and who handled it each time it 
is sold in the U.S. market.

- Product verification: Manufacturers, wholesaler drug distributors, 
repackagers, and many dispensers (primarily pharmacies) to establish 
systems and processes to be able to verify the product identifier on 
certain prescription drug packages.

- Detection and response: Manufacturers, wholesaler drug distributors, 
repackagers, and many dispensers (primarily pharmacies) to quarantine and 
promptly investigate a drug that has been identified as suspect, meaning 
that it may be counterfeit, unapproved, or potentially dangerous.

- Notification: Manufacturers, wholesaler drug distributors, repackagers, 
and many dispensers (primarily pharmacies) to establish systems and 
processes to notify FDA and other stakeholders if an illegitimate drug is 
found.

- Wholesaler licensing: Wholesale drug distributors to report their 
licensing status and contact information to FDA. This information will then 
be made available in a public database.

-Third-party logistics provider licensing: Third-party logistics providers, 
those who provide storage and logistical operations related to drug 
distribution, to obtain a state or federal license.”

The product verification provision points to a similar system to what we’re 
discussing.

The HP paper claims that these product verification technologies must be a 
“moving target” that stays ahead of counterfeiters, and that these 
organizations of counterfeiters and diverters are causing a revenue loss in 
the tens of billions of dollars. There’s some insight into the methods of 
counterfeiting that may be worth a read. Europe is the largest market for 
drug diversion. I’m inferring that in the USA the drug diversion activity 
is key in the opioid epidemic; buyers know they are getting goods outside 
of the regulated supply chain. This paper discusses 2D barcodes and RFID in 
terms of “track-and-trace”. The Global Data Synchronization Network (GDSN) 
and EPCglobal Network are mentioned as supply chain database providers. 
Security printing is discussed.

This paper is to sell HP’s solution to the problem. It looks like we’d be 
competing with them, although their website link is gone. I suggest reading 
this paper.

The FedEx paper didn’t have anything obviously interesting for us.

The web article is much more recent than these other sources. They claim 
that USA packages were required to have the unique serial number by 
November 27 2017. 40 other countries have pharmaceutical tracing efforts in 
flight. In Europe there’s the Falsified Medicines Directive (FMD) with a 
February 2019 labeling deadline. There are “vendors of serialization 
equipment” out there. There’s a machine type to check barcode quality after 
printing. This is another article worth reading in addition to the HP paper.

While our labeling approach may have unique characteristics, I don’t think 
we’re going to compete with commercial companies already tied into 
regulation in these many countries with recent legislation. What do you 
think? How do we add value?

Matt

On Friday, January 5, 2018 at 6:45:04 PM UTC-6, matthe...@gmail.com wrote:
>
> From 
> https://www.pharmamanufacturing.com/experts/contract-manufacturing-management-supply-chain-management-/show/71/
>
> In the US: Food and Drug Administration Safety and Innovation Act 
> (FDASIA), 

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

From 
https://www.pharmamanufacturing.com/experts/contract-manufacturing-management-supply-chain-management-/show/71/

In the US: Food and Drug Administration Safety and Innovation Act (FDASIA), 
Drug Supply Chain Security Act (DSCSA)

Don mentions the term "end-to-end security program".

Here's a paper on pharmaceutical product tracking and 
authentication: 
ftp://ftp.hp.com/pub/services/manufacturing/info/pta_59830764en.pdf

A paper from 
FedEx: 
http://images.fedex.com/us/supply-chain/services/healthcare-shared-network/HSN-End-to-End-security.pdf

An article on the state of these activities in 
2017: 
http://pharmaceuticalcommerce.com/supply-chain-logistics/2017-product-security-report/

I'll read these in detail and report any significant information.

Matt

On Friday, December 29, 2017 at 4:27:52 PM UTC-6, KLR wrote:
>
>
> EU has also been at it 
> https://ec.europa.eu/health/sites/health/files/files/counterf_par_trade/doc_publ_consult_200803/114_b_efpia_en.pdf
>
> El domingo, 24 de diciembre de 2017, 17:38:57 (UTC+1), Frank Davidson 
> escribió:
>>
>> A few weeks ago, I saw this report on the PBS NewsHour:
>>
>>
>> https://www.pbs.org/newshour/show/fighting-the-public-health-threat-of-counterfeit-drugs
>>  
>> 
>>
>> I have just (as in haven't even started putting code in GitHub yet) 
>> started to work on an app which I was thinking might help deal with this 
>> and truly help folks out, worldwide. It also could help with drugs bought 
>> over the internet as well, I would think.
>>
>> The idea is to use aztec bar codes to encode a manufacturer's ECDSA 
>> signature and a UUID and possible some other metadata on the label of a 
>> bottle of pharmaceuticals.
>>
>> An Android and iOS app would then allow an individual or small pharmacy 
>> to scan that bottle, verifying the signature against a manufacturer's 
>> website, where there would be verification against their public key and 
>> also their cert with their cert authority. Smartphones and the Internet are 
>> fast becoming ubiquitous even in the developing world.
>>
>> I'm working on the code right now and I'll post things as I progress.
>>
>> I'm not looking for any money at all because I think the programming task 
>> isn't really too hard, but, I was thinking that the greater Go community 
>> might also have an interest.
>>
>> I'm not sure if there's a charitable team or group or anything, but I 
>> thought I'd check it out. I'd like to make this totally OSS with a 
>> non-profit backing it (if it gets to that state eventually). I've 
>> registered verx.codes as a domain.
>>
>> I'm not totally sure yet if this is feasible in the real world or if the 
>> pharmaceutical companies could be persuaded to buy in, but I would think it 
>> could also be good for their brands and give them a way to track individual 
>> bottles and provide authenticated info to users like expiration dates and 
>> extensive use instructions once a person successfully scans and verifies a 
>> code and then gets passed to the company's website.
>>
>> Anyway, totally just beginning and I'd welcome any thoughts, comments, 
>> and/or critisms!
>>
>> Merry Christmas and Happy Holidays to all the Go community!
>>
>> Frank
>>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[KLR]

EU has also been at it 
https://ec.europa.eu/health/sites/health/files/files/counterf_par_trade/doc_publ_consult_200803/114_b_efpia_en.pdf

El domingo, 24 de diciembre de 2017, 17:38:57 (UTC+1), Frank Davidson 
escribió:
>
> A few weeks ago, I saw this report on the PBS NewsHour:
>
>
> https://www.pbs.org/newshour/show/fighting-the-public-health-threat-of-counterfeit-drugs
>  
> 
>
> I have just (as in haven't even started putting code in GitHub yet) 
> started to work on an app which I was thinking might help deal with this 
> and truly help folks out, worldwide. It also could help with drugs bought 
> over the internet as well, I would think.
>
> The idea is to use aztec bar codes to encode a manufacturer's ECDSA 
> signature and a UUID and possible some other metadata on the label of a 
> bottle of pharmaceuticals.
>
> An Android and iOS app would then allow an individual or small pharmacy to 
> scan that bottle, verifying the signature against a manufacturer's website, 
> where there would be verification against their public key and also their 
> cert with their cert authority. Smartphones and the Internet are fast 
> becoming ubiquitous even in the developing world.
>
> I'm working on the code right now and I'll post things as I progress.
>
> I'm not looking for any money at all because I think the programming task 
> isn't really too hard, but, I was thinking that the greater Go community 
> might also have an interest.
>
> I'm not sure if there's a charitable team or group or anything, but I 
> thought I'd check it out. I'd like to make this totally OSS with a 
> non-profit backing it (if it gets to that state eventually). I've 
> registered verx.codes as a domain.
>
> I'm not totally sure yet if this is feasible in the real world or if the 
> pharmaceutical companies could be persuaded to buy in, but I would think it 
> could also be good for their brands and give them a way to track individual 
> bottles and provide authenticated info to users like expiration dates and 
> extensive use instructions once a person successfully scans and verifies a 
> code and then gets passed to the company's website.
>
> Anyway, totally just beginning and I'd welcome any thoughts, comments, 
> and/or critisms!
>
> Merry Christmas and Happy Holidays to all the Go community!
>
> Frank
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

Some research:

Here's an FDA document on pharmacuetical 
barcodes: 
https://www.fda.gov/downloads/BiologicsBloodVaccines/GuidanceComplianceRegulatoryInformation/Guidances/UCM267392.pdf

In the USA a barcode with the NDC (National Drug Code) is required. A13 
explains the barcode:

Under 21 CFR 207.35(b)(2), the Agency uses the National Drug Code (NDC)
> numbering system in assigning an NDC number. The number is a 10-character
> code that uses only numerals.
> The NDC number is divided into three segments. The first segment, the 
> labeler
> code, identifies the manufacturer or distributor and is four or five 
> characters long.
> The second segment, the product code, identifies the drug product and is 
> three or
> four characters long. The third segment, the package code, identifies the 
> trade
> package size and type and is one or two characters long. The 10-character 
> NDC
> number can be in the following three configurations of labeler code–product
> code–package code: 4–4–2, 5–4–1, or 5–3–2. 


Here's a wikipedia page that lists some private databases and other 
codes: https://en.wikipedia.org/wiki/Pharmaceutical_code

I wouldn't want to write an original cryptographic implementation for an 
industry where lives are at risk and large amounts of money could be lost 
from a mistake. Is there a similar mechanism to ECDSA in the Go crypto 
packages?

Thanks,
Matt

On Friday, December 29, 2017 at 1:51:37 PM UTC-6, Frank Davidson wrote:
>
> I've started on the code to generate the barcodes:
>
> https://github.com/verxcodes/codegen
>
> It's totally just a start, but I wanted to get it out so everyone could 
> check it out and provide input, etc.
>
> Please take a careful look at the ECDSA encryption and whether or not I'm 
> doing it right...
>
> Comments, criticisms, edits, and pull requests welcome!
>
> I envision three repos - codegen, website, server - or something like 
> that. What does everyone think?
>
> I totally agree we should get input from the manufacturers, but I don't 
> want to stop work before hearing from them as I think that will be a long 
> time coming... Part of this will be convincing them to change anyway.
>
> Cheers and Happy New Year!
>
> Frank
>
> On Friday, December 29, 2017 at 2:03:18 PM UTC-5, matthe...@gmail.com 
> wrote:
>>
>> Well all we really have for a specification is that the problem is 
>> counterfeit medication from unknown sources at untrustworthy pharmacies in 
>> Kenya and we assume around the world, and we have a few possible 
>> Internet-based labeling solutions without manufacturer input. We would like 
>> to use Go as a way to contribute back to the Go community and technology.
>>
>> Reading about the many barcode types shows that there are printing 
>> tradeoffs that may make both QR and Aztec unusable for some or all of the 
>> manufacturers we’ll ask to change. Distribution to pharmacies or consumers 
>> may completely remove the original packaging. Additionally the 
>> pharmaceutical industry may partially or completely already be doing 
>> manufacturer-verifying barcodes.
>>
>> We need input from industry experts before proceeding.
>>
>> Matt
>>
>> On Thursday, December 28, 2017 at 12:34:08 PM UTC-6, Frank Davidson wrote:
>>>
>>> I saw this which seems to say using a QR code is freely allowed: 
>>> http://www.qrcode.com/en/faq.html
>>>
>>> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
>>> wrote:

 Here's the aztec patent that's in the public domain: 
 http://www.adams1.com/patents/US5591956.pdf

 For QR it seems that the "patent is not exercised": 
 https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere

 So I suggest we do use the aztec code. I've started a github project 
 with the Apache 2.0 license where I'll add an initial API soon: 
 https://github.com/pciet/aztec

 Perhaps the central authority could be a blacklist instead of a 
 whitelist? While the report indicates Kenya has no law against drug 
 counterfeiting we could aid in notifying authorities and providing 
 evidence 
 in places that do have these laws.

 I'd assume most CA's would remove organizations misrepresenting 
 themselves. But is that the case for all of them?

 Matt

 On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi 
 wrote:
>
> Yes, exactly.
> That's why I think this needs some central authority - maybe 
> cross-signing the manufacturer's public key is enough.



-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I've started on the code to generate the barcodes:

https://github.com/verxcodes/codegen

It's totally just a start, but I wanted to get it out so everyone could 
check it out and provide input, etc.

Please take a careful look at the ECDSA encryption and whether or not I'm 
doing it right...

Comments, criticisms, edits, and pull requests welcome!

I envision three repos - codegen, website, server - or something like that. 
What does everyone think?

I totally agree we should get input from the manufacturers, but I don't 
want to stop work before hearing from them as I think that will be a long 
time coming... Part of this will be convincing them to change anyway.

Cheers and Happy New Year!

Frank

On Friday, December 29, 2017 at 2:03:18 PM UTC-5, matthe...@gmail.com wrote:
>
> Well all we really have for a specification is that the problem is 
> counterfeit medication from unknown sources at untrustworthy pharmacies in 
> Kenya and we assume around the world, and we have a few possible 
> Internet-based labeling solutions without manufacturer input. We would like 
> to use Go as a way to contribute back to the Go community and technology.
>
> Reading about the many barcode types shows that there are printing 
> tradeoffs that may make both QR and Aztec unusable for some or all of the 
> manufacturers we’ll ask to change. Distribution to pharmacies or consumers 
> may completely remove the original packaging. Additionally the 
> pharmaceutical industry may partially or completely already be doing 
> manufacturer-verifying barcodes.
>
> We need input from industry experts before proceeding.
>
> Matt
>
> On Thursday, December 28, 2017 at 12:34:08 PM UTC-6, Frank Davidson wrote:
>>
>> I saw this which seems to say using a QR code is freely allowed: 
>> http://www.qrcode.com/en/faq.html
>>
>> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
>> wrote:
>>>
>>> Here's the aztec patent that's in the public domain: 
>>> http://www.adams1.com/patents/US5591956.pdf
>>>
>>> For QR it seems that the "patent is not exercised": 
>>> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>>>
>>> So I suggest we do use the aztec code. I've started a github project 
>>> with the Apache 2.0 license where I'll add an initial API soon: 
>>> https://github.com/pciet/aztec
>>>
>>> Perhaps the central authority could be a blacklist instead of a 
>>> whitelist? While the report indicates Kenya has no law against drug 
>>> counterfeiting we could aid in notifying authorities and providing evidence 
>>> in places that do have these laws.
>>>
>>> I'd assume most CA's would remove organizations misrepresenting 
>>> themselves. But is that the case for all of them?
>>>
>>> Matt
>>>
>>> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi 
>>> wrote:

 Yes, exactly.
 That's why I think this needs some central authority - maybe 
 cross-signing the manufacturer's public key is enough.
>>>
>>>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

Well all we really have for a specification is that the problem is 
counterfeit medication from unknown sources at untrustworthy pharmacies in 
Kenya and we assume around the world, and we have a few possible 
Internet-based labeling solutions without manufacturer input. We would like 
to use Go as a way to contribute back to the Go community and technology.

Reading about the many barcode types shows that there are printing 
tradeoffs that may make both QR and Aztec unusable for some or all of the 
manufacturers we’ll ask to change. Distribution to pharmacies or consumers 
may completely remove the original packaging. Additionally the 
pharmaceutical industry may partially or completely already be doing 
manufacturer-verifying barcodes.

We need input from industry experts before proceeding.

Matt

On Thursday, December 28, 2017 at 12:34:08 PM UTC-6, Frank Davidson wrote:
>
> I saw this which seems to say using a QR code is freely allowed: 
> http://www.qrcode.com/en/faq.html
>
> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
> wrote:
>>
>> Here's the aztec patent that's in the public domain: 
>> http://www.adams1.com/patents/US5591956.pdf
>>
>> For QR it seems that the "patent is not exercised": 
>> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>>
>> So I suggest we do use the aztec code. I've started a github project with 
>> the Apache 2.0 license where I'll add an initial API soon: 
>> https://github.com/pciet/aztec
>>
>> Perhaps the central authority could be a blacklist instead of a 
>> whitelist? While the report indicates Kenya has no law against drug 
>> counterfeiting we could aid in notifying authorities and providing evidence 
>> in places that do have these laws.
>>
>> I'd assume most CA's would remove organizations misrepresenting 
>> themselves. But is that the case for all of them?
>>
>> Matt
>>
>> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi wrote:
>>>
>>> Yes, exactly.
>>> That's why I think this needs some central authority - maybe 
>>> cross-signing the manufacturer's public key is enough.
>>
>>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I saw this which seems to say using a QR code is freely allowed: 
http://www.qrcode.com/en/faq.html

On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
wrote:
>
> Here's the aztec patent that's in the public domain: 
> http://www.adams1.com/patents/US5591956.pdf
>
> For QR it seems that the "patent is not exercised": 
> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>
> So I suggest we do use the aztec code. I've started a github project with 
> the Apache 2.0 license where I'll add an initial API soon: 
> https://github.com/pciet/aztec
>
> Perhaps the central authority could be a blacklist instead of a whitelist? 
> While the report indicates Kenya has no law against drug counterfeiting we 
> could aid in notifying authorities and providing evidence in places that do 
> have these laws.
>
> I'd assume most CA's would remove organizations misrepresenting 
> themselves. But is that the case for all of them?
>
> Matt
>
> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi wrote:
>>
>> Yes, exactly.
>> That's why I think this needs some central authority - maybe 
>> cross-signing the manufacturer's public key is enough.
>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I was thinking https://github.com/boombuler/barcode for the creating of the 
QR or Aztec code and https://github.com/LazarSoft/jsqrcode for the 
decoding? I was assuming that JS would be best for decoding in a PSA 
website?

But I'm totally open to other ideas!

What do you think the specification should look like? I'm not great with 
documentation...

Cheers!

Frank

On Thursday, December 28, 2017 at 12:22:01 PM UTC-5, matthe...@gmail.com 
wrote:
>
> Yes, but the godoc seems incomplete (
> https://godoc.org/github.com/boombuler/barcode/aztec) so I figured we 
> could do a better job. Perhaps we only need encoding, but this lib doesn't 
> provide decoding. Given the MIT license we could use it as an 
> implementation source. The primary author doesn't provide an email address (
> https://github.com/boombuler) but there does seem to be recent activity.
>
> Using github.com/boombuler/barcode may be the right choice. I wanted to 
> get something down, but we do still need a specification for this project.
>
> Matt
>
> On Thursday, December 28, 2017 at 10:50:41 AM UTC-6, Frank Davidson wrote:
>>
>> Matt - You saw this library, correct? 
>> https://github.com/boombuler/barcode
>>
>> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
>> wrote:
>>>
>>> Here's the aztec patent that's in the public domain: 
>>> http://www.adams1.com/patents/US5591956.pdf
>>>
>>> For QR it seems that the "patent is not exercised": 
>>> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>>>
>>> So I suggest we do use the aztec code. I've started a github project 
>>> with the Apache 2.0 license where I'll add an initial API soon: 
>>> https://github.com/pciet/aztec
>>>
>>> Perhaps the central authority could be a blacklist instead of a 
>>> whitelist? While the report indicates Kenya has no law against drug 
>>> counterfeiting we could aid in notifying authorities and providing evidence 
>>> in places that do have these laws.
>>>
>>> I'd assume most CA's would remove organizations misrepresenting 
>>> themselves. But is that the case for all of them?
>>>
>>> Matt
>>>
>>> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi 
>>> wrote:

 Yes, exactly.
 That's why I think this needs some central authority - maybe 
 cross-signing the manufacturer's public key is enough.
>>>
>>>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I created this true quantum random number generator, perhaps excessive, for 
the random vector in the ECDSA algorithm.

https://github.com/davidsonff/qrand

Check it out and feel free to criticize! I'm sure it's overly paranoid, but 
I figure it's probably as truly random as can be... It falls back to 
math/rand if there's no internet.

Cheers!

Frank

On Thursday, December 28, 2017 at 12:22:01 PM UTC-5, matthe...@gmail.com 
wrote:
>
> Yes, but the godoc seems incomplete (
> https://godoc.org/github.com/boombuler/barcode/aztec) so I figured we 
> could do a better job. Perhaps we only need encoding, but this lib doesn't 
> provide decoding. Given the MIT license we could use it as an 
> implementation source. The primary author doesn't provide an email address (
> https://github.com/boombuler) but there does seem to be recent activity.
>
> Using github.com/boombuler/barcode may be the right choice. I wanted to 
> get something down, but we do still need a specification for this project.
>
> Matt
>
> On Thursday, December 28, 2017 at 10:50:41 AM UTC-6, Frank Davidson wrote:
>>
>> Matt - You saw this library, correct? 
>> https://github.com/boombuler/barcode
>>
>> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
>> wrote:
>>>
>>> Here's the aztec patent that's in the public domain: 
>>> http://www.adams1.com/patents/US5591956.pdf
>>>
>>> For QR it seems that the "patent is not exercised": 
>>> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>>>
>>> So I suggest we do use the aztec code. I've started a github project 
>>> with the Apache 2.0 license where I'll add an initial API soon: 
>>> https://github.com/pciet/aztec
>>>
>>> Perhaps the central authority could be a blacklist instead of a 
>>> whitelist? While the report indicates Kenya has no law against drug 
>>> counterfeiting we could aid in notifying authorities and providing evidence 
>>> in places that do have these laws.
>>>
>>> I'd assume most CA's would remove organizations misrepresenting 
>>> themselves. But is that the case for all of them?
>>>
>>> Matt
>>>
>>> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi 
>>> wrote:

 Yes, exactly.
 That's why I think this needs some central authority - maybe 
 cross-signing the manufacturer's public key is enough.
>>>
>>>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

Yes, but the godoc seems incomplete 
(https://godoc.org/github.com/boombuler/barcode/aztec) so I figured we 
could do a better job. Perhaps we only need encoding, but this lib doesn't 
provide decoding. Given the MIT license we could use it as an 
implementation source. The primary author doesn't provide an email address 
(https://github.com/boombuler) but there does seem to be recent activity.

Using github.com/boombuler/barcode may be the right choice. I wanted to get 
something down, but we do still need a specification for this project.

Matt

On Thursday, December 28, 2017 at 10:50:41 AM UTC-6, Frank Davidson wrote:
>
> Matt - You saw this library, correct? https://github.com/boombuler/barcode
>
> On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
> wrote:
>>
>> Here's the aztec patent that's in the public domain: 
>> http://www.adams1.com/patents/US5591956.pdf
>>
>> For QR it seems that the "patent is not exercised": 
>> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>>
>> So I suggest we do use the aztec code. I've started a github project with 
>> the Apache 2.0 license where I'll add an initial API soon: 
>> https://github.com/pciet/aztec
>>
>> Perhaps the central authority could be a blacklist instead of a 
>> whitelist? While the report indicates Kenya has no law against drug 
>> counterfeiting we could aid in notifying authorities and providing evidence 
>> in places that do have these laws.
>>
>> I'd assume most CA's would remove organizations misrepresenting 
>> themselves. But is that the case for all of them?
>>
>> Matt
>>
>> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi wrote:
>>>
>>> Yes, exactly.
>>> That's why I think this needs some central authority - maybe 
>>> cross-signing the manufacturer's public key is enough.
>>
>>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

Matt - You saw this library, correct? https://github.com/boombuler/barcode

On Thursday, December 28, 2017 at 11:19:27 AM UTC-5, matthe...@gmail.com 
wrote:
>
> Here's the aztec patent that's in the public domain: 
> http://www.adams1.com/patents/US5591956.pdf
>
> For QR it seems that the "patent is not exercised": 
> https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere
>
> So I suggest we do use the aztec code. I've started a github project with 
> the Apache 2.0 license where I'll add an initial API soon: 
> https://github.com/pciet/aztec
>
> Perhaps the central authority could be a blacklist instead of a whitelist? 
> While the report indicates Kenya has no law against drug counterfeiting we 
> could aid in notifying authorities and providing evidence in places that do 
> have these laws.
>
> I'd assume most CA's would remove organizations misrepresenting 
> themselves. But is that the case for all of them?
>
> Matt
>
> On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi wrote:
>>
>> Yes, exactly.
>> That's why I think this needs some central authority - maybe 
>> cross-signing the manufacturer's public key is enough.
>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

Here's the aztec patent that's in the public 
domain: http://www.adams1.com/patents/US5591956.pdf

For QR it seems that the "patent is not 
exercised": 
https://stackoverflow.com/questions/3710937/what-is-the-spec-for-formatting-data-in-qr-codes-i-can-not-find-it-anywhere

So I suggest we do use the aztec code. I've started a github project with 
the Apache 2.0 license where I'll add an initial API 
soon: https://github.com/pciet/aztec

Perhaps the central authority could be a blacklist instead of a whitelist? 
While the report indicates Kenya has no law against drug counterfeiting we 
could aid in notifying authorities and providing evidence in places that do 
have these laws.

I'd assume most CA's would remove organizations misrepresenting themselves. 
But is that the case for all of them?

Matt

On Wednesday, December 27, 2017 at 10:25:07 AM UTC-6, Tamás Gulácsi wrote:
>
> Yes, exactly.
> That's why I think this needs some central authority - maybe cross-signing 
> the manufacturer's public key is enough.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

Sure it's enough. But how do you fight against Bauer (instead of Bayer), or do 
I know the proper spelling of GSK?

Like Adidas vs. Adios...

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

Let's use QR codes then!

Do we have to have a central registry/key server if we verify a domain's 
certificate? Isn't that enough to tell us that that domain and, hence, that 
public key is owned by that manufacturer? Or am I getting something wrong? 
How does Chrome know that a site's cert is good and valid? How are 
certificate authorities (CAs) overseen?

On Wednesday, December 27, 2017 at 1:10:50 AM UTC-5, Tamás Gulácsi wrote:
>
> We have to enforce some kind of central registry for the manufacturers, to 
> avoid that anybody can create a key pair, use our software, and have vald 
> unique verifiable codes, but be a drug counterteiter.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

We have to enforce some kind of central registry for the manufacturers, to 
avoid that anybody can create a key pair, use our software, and have vald 
unique verifiable codes, but be a drug counterteiter.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

So the manufacturer provides a number on a label that can be verified to 
have been written by them that is unique and unguessable for each label 
printing.

We provide a program to generate these labels and a PWA to verify the 
labels. We’d need to serve the PWA on the Internet, and the label generator 
source code. A Go program can host the PWA and Go can be the language for 
the label generator. We’d need to localize/translate the PWA and maybe the 
label generator.

I’m not familiar with non-english processors and operating systems around 
the world. I’m concerned that Go is supported only for the big server ones 
for english speakers which may be different than at printing stations, but 
maybe we are just dealing with Windows and Linux on x86 processors 
generally.

By having the URL for the manufacturer’s public key in the label we don’t 
have to track a list of manufacturers. The manufacturer follows our 
specification for a verification server and label inputs. They track their 
UUIDs and keys and we handle the ECDSA decryption logic and let them say 
yes/no to the decrypted UUID. I may be misunderstanding how ECDSA would be 
used.

My previous train of thought was based on wanting to have complete control 
over the consumer experience. By relying on manufacturers’ servers the same 
implementation is repeated and could be done incorrectly, and there could 
be downtime. Distributors are an important part of the supply chain and 
they do open medication packaging necessarily. Pharmacies often repackage 
medication. Untrustworthy pharmacies could get trusted packaging, and 
untrustworthy pharmacies seem to be the biggest problem stated by the 
report.

Matt

On Tuesday, December 26, 2017 at 4:36:25 PM UTC-6, Tamás Gulácsi wrote:
>
>
>
> 2017. december 26., kedd 21:59:17 UTC+1 időpontban Frank Davidson a 
> következőt írta:
>>
>> I was thinking a Progressive Web App (PWA) to avoid writing multiple 
>> Android, Web, iOS apps... I know QR codes are more broadly used but I'm not 
>> sure if they can store the amount of info we would need? I think you need 
>> 384 bits plus the data we need to encode for secure ECDSA? Aztec codes seem 
>> to be used somewhat ubiquitously and seem also to be able to store a good 
>> amount more data than QR. Building a PWA using Aztec codes for end users, 
>> we might be able to use the JS port of Zxing: 
>> https://github.com/LazarSoft/jsqrcode
>>
>>
>
> http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx
>
> QR code: 4296 alpha, 7089 numeric characters
> Aztec: 3067 alphanumeric, 3832 numeric, 1914 Bytes
>
> so no real limitations here.
>
> If the URL in the Aztec code designates a landing page on the 
>> manufacturer's certified domain, that end point can deliver up the correct 
>> public key, and since that is used to verify the signature, and a man in 
>> the middle attack is prevented by the manufacturer's domain's cert, I think 
>> we'd be done. I'm thinking we may not even need a server as the domain's 
>> certificate from a valid CA would serve this purpose.
>>
>> Thoughts?
>>
>
>  Yes, the app could download the public key from the _central authority_ - 
> you have to provide a certificate authority which signs the private keys, 
> to forbid
> anybody to serve  its own Aztec codes with a a vanilla public key.
>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

2017. december 26., kedd 21:59:17 UTC+1 időpontban Frank Davidson a 
következőt írta:
>
> I was thinking a Progressive Web App (PWA) to avoid writing multiple 
> Android, Web, iOS apps... I know QR codes are more broadly used but I'm not 
> sure if they can store the amount of info we would need? I think you need 
> 384 bits plus the data we need to encode for secure ECDSA? Aztec codes seem 
> to be used somewhat ubiquitously and seem also to be able to store a good 
> amount more data than QR. Building a PWA using Aztec codes for end users, 
> we might be able to use the JS port of Zxing: 
> https://github.com/LazarSoft/jsqrcode
>
>
http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx

QR code: 4296 alpha, 7089 numeric characters
Aztec: 3067 alphanumeric, 3832 numeric, 1914 Bytes

so no real limitations here.

If the URL in the Aztec code designates a landing page on the 
> manufacturer's certified domain, that end point can deliver up the correct 
> public key, and since that is used to verify the signature, and a man in 
> the middle attack is prevented by the manufacturer's domain's cert, I think 
> we'd be done. I'm thinking we may not even need a server as the domain's 
> certificate from a valid CA would serve this purpose.
>
> Thoughts?
>

 Yes, the app could download the public key from the _central authority_ - 
you have to provide a certificate authority which signs the private keys, 
to forbid
anybody to serve  its own Aztec codes with a a vanilla public key.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I was thinking a Progressive Web App (PWA) to avoid writing multiple 
Android, Web, iOS apps... I know QR codes are more broadly used but I'm not 
sure if they can store the amount of info we would need? I think you need 
384 bits plus the data we need to encode for secure ECDSA? Aztec codes seem 
to be used somewhat ubiquitously and seem also to be able to store a good 
amount more data than QR. Building a PWA using Aztec codes for end users, 
we might be able to use the JS port of Zxing: 
https://github.com/LazarSoft/jsqrcode

If the URL in the Aztec code designates a landing page on the 
manufacturer's certified domain, that end point can deliver up the correct 
public key, and since that is used to verify the signature, and a man in 
the middle attack is prevented by the manufacturer's domain's cert, I think 
we'd be done. I'm thinking we may not even need a server as the domain's 
certificate from a valid CA would serve this purpose.

Thoughts?

Cheers!

Frank

On Tuesday, December 26, 2017 at 2:37:44 PM UTC-5, Tamás Gulácsi wrote:
>
> 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
>>>
>>
>
> Android already provides AZTEC reader:
>
> https://developers.google.com/android/reference/com/google/android/gms/vision/barcode/BarcodeDetector.Builder
>
> But Aztec format seems better for me in theory than QR-code, but QR-code 
> is wy better supported everywhere.
> I still think that the previous opinions show that the biggest obstacle is 
> to synthesize the big picture: who will own the private key, what 
> participant will do what.
>
> I think we should clarify all the steps, generate all the possible 
> scenarios (what step can/should/must be done by which participant),
> and provide the needed software libraries with clear, documented 
> interfaces.
>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

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
>>
>

Android already provides AZTEC reader:
https://developers.google.com/android/reference/com/google/android/gms/vision/barcode/BarcodeDetector.Builder

But Aztec format seems better for me in theory than QR-code, but QR-code is 
wy better supported everywhere.
I still think that the previous opinions show that the biggest obstacle is 
to synthesize the big picture: who will own the private key, what 
participant will do what.

I think we should clarify all the steps, generate all the possible 
scenarios (what step can/should/must be done by which participant),
and provide the needed software libraries with clear, documented interfaces.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

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 

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

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 
>>>

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

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
>>
>>

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

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.

[go-nuts] Re: Go Community Charity Work?

[matthewjuran]

We would write a scaling server with Go on one of these public datacenter 
services. A manufacturer or distributor could register a UUID with us that 
is then verified through us by the pharmacy and consumer later. The 
pharmacy/consumer has the aztec barcode with the UUID, manufacturer 
cryptographic number, and distributor cryptographic number, so maybe we’re 
talking about two barcodes and a distribution standard.

Capturing already-scanned UUIDs may mitigate some copying, or at least 
indicate to the consumer or pharmacy that there's a copier problem.

Would the picture be processed by the server or by the client? How are 
existing Go libs for these aztec barcodes?

We'd need an authentication system for people or organizations registering 
UUIDs.

Could we have data tied to the UUID on the target distributor, target 
pharmacy, or target consumer?

“when we are looking at the source, we are looking at the stock cards, and 
also cross-checking with the delivery sheet to confirm this is what is 
being supplied”

In Kenya one distributor handles 40% of the country’s medicine supply. They 
have a QA process. But: “Many small storefronts buy from unauthorized 
distributors” - we’re not fixing this part except maybe through consumer 
knowledge (“we’re expecting the bar code”). PBS pointed out barcoding as a 
solution put into place already.

Thomas Woods of the World Bank talks about “rapid authentication devices”. 
As a group of app implementers I think we’d be best served by partnering 
with an organization with connections to the industry instead of directly 
with manufacturers or distributors. Who can we talk to?

I think this is on-topic for golang-nuts as we’re discussing a use case of 
Go and programming: building global information services. Maybe somebody 
can use our designs for their Go service later.

Matt

On Sunday, December 24, 2017 at 4:14:22 PM UTC-6, Tamás Gulácsi wrote:
>
> A signed nonce is enough to prove private key ownership - as far as it 
> can. Replay attack is unavoidable.
> Uuid is useful for tracking.
>
> But how feasible is this? Here (Hungary, Eastern Europe) we have drugs 
> packed in preprinted boxes, and the serial ids are just pushed into the 
> paper.
> Per-box personalized aztec code would push up the packaging price 
> significantly.
>
> But for dangerous/pricey drugs this may be acceptable.
>
>
> But this is not Go related yet, so maybe we should move this to somewhere 
> else.
>
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Tamás Gulácsi]

A signed nonce is enough to prove private key ownership - as far as it can. 
Replay attack is unavoidable.
Uuid is useful for tracking.

But how feasible is this? Here (Hungary, Eastern Europe) we have drugs packed 
in preprinted boxes, and the serial ids are just pushed into the paper.
Per-box personalized aztec code would push up the packaging price significantly.

But for dangerous/pricey drugs this may be acceptable.


But this is not Go related yet, so maybe we should move this to somewhere else.

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

I think the verification would have to happen online? But a lot of places 
are getting online and also, it doesn't have to be perfect. If it stopped 
70% of the fraud and the stupid fraudsters, that's still plenty?

On Sunday, December 24, 2017 at 2:07:51 PM UTC-5, Damian Gryski wrote:
>
> In cryptographic terms, this would be a "replay attack", although I'm not 
> sure how any of the standard mitigations would apply in the resl world, 
> especially if the verification is to be done offline.
>
> Damian
>

-- 
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.

[go-nuts] Re: Go Community Charity Work?

[Frank Davidson]

The UUID (or similar). The aztec code would be unique for each bottle. 
Also, the manufacturer could provide verification of that bottle provenance 
in terms of dates, when it was first verified, etc. 

A fraudster could copy a whole pallet, but it would be a heck of a lot of 
work and they'd have to do it continuously.

It wouldn't be perfect, but might prevent the vast bulk of the fraud and 
certainly stupid fraudsters.

At least, I think it would.

On Sunday, December 24, 2017 at 1:30:28 PM UTC-5, Tamás Gulácsi wrote:
>
> "packaged to look like the real deal"
> How would you stop them copying a real package?
> They don't need to create a new signed aztec barcode, they can just 
> blindly copy a real one.

-- 
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.