Opencert Verification payload and opencert viewer enquiry
March 24, 2020 at 4:11amOpencert Verification payload and opencert viewer enquiry
March 24, 2020 at 4:11amHi Nebulis, thanks for the helps last week.
(1) After discussion, we are planning to host the API on AWS API Gateway.
As shown in the screenshot above, the opencert is only valid if summary.all is “TRUE”. As tested with sample payload provided here ( https://gist.githubusercontent.com/Nebulis/dc32c107fc5112ecf863b1dfa25995a9/raw/9aed3bfbbddaaa23d453cfbb9ee42d9efffaf2b8/opencerts-ropsten-demo.json ) and few other opencert payloads as well, the summary.all still belongs to “FALSE”.
Do you have any sample payload that’ll be able to return status “TRUE” for summary.all for testing purpose?
(2) We will invoke the OA Universal Action to allow individual to view their open-cert. Hence, our hostname as provided in “uri” will require to be whitelisted on your side (action.openattestation.com). In calling the universal action, we will provide the “uri” and “redirect” parameter as we don’t encrypt our file, as shown in the screenshot below:
There’re few enquiries that require clarification from your side:
(a) the “PermittedAction”(termsOfUse) field can be left empty. In what scenario will require us to use this field (what are the option available)?
(b) Under the “redirect” field, how do we know which web client should we insert in this field (tradetrust.io or opencerts.io)? Or we can put “opencerts.io” for all opencert?
Thanks in advance!
March 24, 2020 at 5:33pm
1) You can try using the demo certs on OpenCerts => https://dev.opencerts.io/static/demo/ropsten.opencerts
2)
a) For the moment we haven't defined it completely, it's just something we thought about for instance in case people want to share OpenCerts but doesn't want to allow other to keep it
b) Please use opencerts.io (or dev.opencerts.io) for OpenCerts document. Tradetrust is meant for eBL (even if OpenCerts will work on it)
March 29, 2020 at 2:29pm
Thanks Nebulis. I've tested with the opencerts provided. However, it still showing "false" for summary.all
When I'm testing with the endpoint "https://api-ropsten.opencerts.io/verify", I'm able to get the result "true" for summary.all, as shown in the screenshot attached. Do I need to update any config when hosting the API ?
March 30, 2020 at 5:44am
Hi,
Indeed you need to configure the function => https://github.com/OpenCerts/opencerts-functions/blob/master/src/verify/config.js#L2
The error shows that there is problem with the document status (i.e. issue / revoke), which is likely because the deployed function connect to homestead instead of ropsten.
Try to set NETWORK to "ropsten" and it should work
March 30, 2020 at 12:15pm
March 31, 2020 at 11:08am
April 2, 2020 at 1:07am
Hi Nebulis, thanks for the offering ! yes, we are interested on that. Please let me know what you need from me in order to create the terraform module =)
(and can I know what is the action that terraform module will perform? our infra team need to assess it. Can email me via "[email protected]")
Thanks !!
April 2, 2020 at 10:16am
I created this issue to track => https://github.com/OpenCerts/opencerts-functions/issues/58
You can subscribe and you will receive notifications when done
As per the actions performed, it will look like this => https://github.com/Open-Attestation/terraform-aws-status-api
One difference that I can think about is that verify API as is doesn't need dynamodb
April 3, 2020 at 6:16pm
April 12, 2020 at 2:39pm
April 13, 2020 at 7:21am
May 8, 2020 at 10:10am
Added scripts to help for deployment using sls (and not terraform as proposed initially)
=> https://docs.opencerts.io/docs/api/verify#deployment
May 15, 2020 at 7:03am
Enquiry on Verify OpenCerts payload
Hi Nebulis,
Refer to the screenshort below, we would like to know which field is used to indicate whether the OpenCerts is issued by SSG registry Training Providers.
Are you supposed to look at “issuerIdentity” = true?
May 15, 2020 at 3:39pm
Thanks for the update Nebulis, had inform my team regarding the usage of sls for deployment.
I noticed the network setting for production_network to be set to "homestead" instead of "ropsten". As per tested previously, the network had to set to "ropsten" for the API to work, can confirm which setting should be the correct one?
And can please help to clarify on HengSiang's question above as well? Thanks !
May 19, 2020 at 7:45am