blockchain-certificates / cert-verifier-js Goto Github PK
View Code? Open in Web Editor NEWJavascript library for verifying Blockcerts Certificates
Home Page: https://www.blockcerts.org
License: MIT License
Javascript library for verifying Blockcerts Certificates
Home Page: https://www.blockcerts.org
License: MIT License
Describe the bug
I'm seeing some inconsistencies with the names of some of the test files. Documenting it now to investigate later.
https://github.com/blockchain-certificates/cert-verifier-js/blob/master/test/fixtures/mainnet-invalid-merkle-receipt-2.0.json : says mainnet but checks against bitcoin testnet. There is no chain specified in the certificate.
https://github.com/blockchain-certificates/cert-verifier-js/blob/master/test/fixtures/mainnet-merkle-root-unmatch-2.0.json : says mainnet but checks against bitcoin testnet. There is no chain specified in the certificate.
https://raw.githubusercontent.com/blockchain-certificates/cert-verifier-js/master/test/fixtures/mainnet-revoked-2.0.json : says mainnet but checks against bitcoin testnet. There is no chain specified in the certificate.
https://raw.githubusercontent.com/blockchain-certificates/cert-verifier-js/master/test/fixtures/mainnet-valid-2.0-alpha.json : says mainnet but checks against bitcoin testnet. There is no chain specified in the certificate.
https://raw.githubusercontent.com/blockchain-certificates/cert-verifier-js/master/test/fixtures/testnet-404-issuer-url-1.2.json : says testnet but checks against bitcoin mainnet. There is no chain specified in the certificate.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Mainnet files should say/check mainnet, testnet files should say/check testnet.
Additional context
It appears that when chain
is not specified, it checks against the address prefix? Not the best logic, but in either case it looks like these files are named incorrectly.
Describe the bug
i installed cert-verifier-js as npm package then i require the package
var Certificate = require('@blockcerts/cert-verifier-js');
and trying to Verify a Blockcert certificate
but i am keep getting error
TypeError: global$1.XMLHttpRequest is not a constructor
in am running node v10.16.0 and npm 6.9.0
here is code snippet which i try to run
const Certificate = require('@blockcerts/cert-verifier-js');
const fs = require('fs');
fs.readFile('./certificate.json', 'utf8', function (err, data) {
if (err) {
console.log(err);
}
let certificate = new Certificate(data);
const verificationResult = await certificate.verify(({ code, label, status, errorMessage }) => {
console.log('Code:', code, label, ' - Status:', status);
if (errorMessage) {
console.log(`The step ${code} fails with the error: ${errorMessage}`);
}
});
if (verificationResult.status === 'failure') {
console.log(`The certificate is not valid. Error: ${verificationResult.errorMessage}`);
}
});
Getting this error
./node_modules/@blockcerts/cert-verifier-js/dist/verifier.js:1
"use strict";function startsWith(e,t){return"string"!=typeof e?(console.warn("Trying to test a non string variable"),!1):0===e.indexOf(t)}Object.defineProperty(exports,"__esModule",{value:!0});const blockCypherUrl="https://api.blockcypher.com/v1/btc/main/txs/",blockCypherTestUrl="https://api.blockcypher.com/v1/btc/test3/txs/",chainSoUrl="https://chain.so/api/v2/get_tx/BTC/",chainSoTestUrl="https://chain.so/api/v2/get_tx/BTCTEST/",etherScanMainUrl="https://api.etherscan.io/api?module=proxy",etherScanRopstenUrl="https://api-ropsten.etherscan.io/api?module=proxy";var API_URLS={blockCypherUrl:blockCypherUrl,blockCypherTestUrl:blockCypherTestUrl,chainSoUrl:chainSoUrl,chainSoTestUrl:chainSoTestUrl,etherScanMainUrl:etherScanMainUrl,etherScanRopstenUrl:etherScanRopstenUrl};const V1_1="1.1",V1_2="1.2",V2_0="2.0";var CERTIFICATE_VERSIONS={V1_1:V1_1,V1_2:V1_2,V2_0:V2_0};const formatValidation="formatValidation",hashComparison="h
TypeError: global$1.XMLHttpRequest is not a constructor
at checkTypeSupport (/node_modules/@blockcerts/cert-verifier-js/dist/verifier.js:1:89756)
at Object. (/node_modules/@blockcerts/cert-verifier-js/dist/verifier.js:1:90080)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:690:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/server.js:53:21)
We need to get another certificate v1.2 I guess.
Describe the bug
blockcerts-verifier doesn't seem to display foreign languages.
To Reproduce
Set browser language to Italian or Japanese in the latest version of Firefox (66.0.4)
Expected behavior
I expected to see the i18n translations on the progress bar.
Screenshots
Environment information:
N/A
Additional context
I hope I didn't miss something obvious. Please assist me with some guidance if you can.
Allow exposing types and also improve confidence in code.
Will be useful for #471
Noticed outstanding bug in cert-wallet. This is also affected, and is a good starter task candidate. See verification process for details and cert-verifier implementation
Describe the bug
cert-verifier-js
defaults to chain.so
to make api requests. The behavior of chain.so
has changed recently and is returning a 503 when the verifier attempts to validate a certificate. This appears to be caused by Cloudflare "cloudflare i'm under attack mode" recently implemented by chain.so
.
To Reproduce
src='./dist/verifier-iife.js'
new Verifier.Certificate(certificateDefinition)
using a valid blockcert;Failed to load resource: the server responded with a status of 503 ()
Expected behavior
No 503 is expected
Describe the feature
The OpenBadges 2.0 spec defines revocationList
as a list of revokedAssertions
. This list can potentially become enormous as the list ofrevokedAssertions
grows.
We want to be able to pass the assertionId as optional parameter to the request, so the server returning the list of revoked assertions can filter on its end, reducing the response payload size & load time. This will also help server side scripts who deal with list max count (i.e. returning only the first 100 items).
We propose the following URL format:
{revocationList}{?|&}assertionId={assertionIdValue}
Per OpenBadges 2.0 spec, the response shape of the request should not changed.
A public key is lingering in the code, let's remove it by adding the ability to pass keys from outside
see values in cert-schema
Not sure if cert-verifier-js has ever ran into a bitcoin address compare issue at all, but for ethereum, if the issuing address is 0xDeaDDeaD... but a blockchain explorer api returns 0xdeaddead... as the address that issued the certificate, then the ensureValidIssuingKey()
method will fail.
In Ethereum, case sensitive addresses only matter for checksum checking opportunities, but otherwise resolve to the same all lower case equivalent version of the address.
all of the verification E2E testcases are testnet; need to include mainnet
Describe the bug
When use ES module import usign babel:
import { Certificate } from '@blockcerts/cert-verifier-js'
Throws the next error:
TypeError: F.XMLHttpRequest is not a constructor
Environment information:
Additional context
I tried using the way is explained in the documentation:
const { Certificate } = require('@blockcerts/cert-verifier-js/lib');
var certificate = new Certificate(certificateDefinition);
But got the next error:
import Certificate from './certificate';
^^^^^^
SyntaxError: Cannot use import statement outside a module
while working on #549 I found that ethereum e2e tests require the API key for etherscan. However since we are supposedly caching API call results, this shouldn't be the case.
We should investigate if calls are actually made to the API during unit tests, and circumvent them if they are happening.
The README.md file states:
signatureImage
:String
. Raw data of the certificate's signature image;
While the source files src/parser.js and src/certificate.js are indeed creating an array of SignatureImage
objects that match the SignatureLine
model from the Blockcerts standard.
Checked as when adding
console.log(certificate.signatureImage);
to script-tag.html, it prints the array of SignatureImage
objects.
I propose changing the API documentation in README.md to reflect the true type of the signatureImage
field.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior: try to validate a testnet certficate.
Expected behavior
A call to blockchain.com/btc-testnet.
Screenshots
A call, instead, to the old testnet.blockchain.info.
If applicable, add screenshots to help explain your problem.
I am using @blockcerts/blockcerts-verifier with angular 6 and it give me error : ERROR TypeError: i is not a function
But when use this without any other js file it works fine.
How can i use this package if using other js files
Describe the bug
When revocationList
is not present inside of the certificate, the verifier should check if it is included in the Issuer Profile and use that. Currently that is not happening, per
cert-verifier-js/src/verifier.js
Line 198 in f8176c6
(note: this.issuer
refers to certificate.issuer
in this context`)
This is where the schema specifies that issuer's revocationList
should be checked as a fallback: https://github.com/blockchain-certificates/cert-schema/blob/master/docs/issuer_schema-2.1.md#revocationlist
To Reproduce
Steps to reproduce the behavior:
revocationList
property directly inside it: https://github.com/AnthonyRonning/https-github.com-labnol-files/blob/master/test/test-revocation.jsonExpected behavior
It should check the issuer profile (https://github.com/AnthonyRonning/https-github.com-labnol-files/blob/master/issuer-eth.json) to grab the revocationList property (https://github.com/AnthonyRonning/https-github.com-labnol-files/blob/master/revocation-eth.json) and fail verification due to revocation.
CVJS should accept a custom list of explorers
This data could be passed as follow:
[
{
serviceUrl: string,
key: string,
priority: number: 0 | 1 // if it's 0 it means it gets executed before the free APIs listed in CVJS, 1 after.
}
]
It seems it is not a concern of the Certificate itself, so this would more likely be pertinent to be sent into the verify method of the certificate object.
One concern that remains is the parsing of the response, an ideal solution would be generic for most or all cases. In practice the API response is likely to be specific per explorer service and difficult to generalize.
This means, do we need to allow the parsing function to be sent along for each explorer? This might prove complicated when consuming from Blockcerts Verifier. More exploration needed.
we are currently on v1(.8.1). it'd be nice to update that dep.
There is a bit of information there but I think it's not sufficient considering how we implement things: https://github.com/digitalbazaar/jsonld.js#custom-document-loader. I was able to remove the callback but then got some timeouts. Didn't have time to investigate more.
This is mainly where we use it: https://github.com/blockchain-certificates/cert-verifier-js/blob/master/src/inspectors/computeLocalHash.js
Certificate.parseJson()
is called twice: once by the consumer to parse the certificate and get its descriptive object, and a second time inside the verification functionThis is a shared effort, any suggestion is most welcomed.
import Certificate from 'cert-verifier-js';
const certificate = new Certificate(certificateContentString);
constructor(certificateContentString)
const certificate = new Certificate(certificateContentString);
The constructor automatically parses a certificate.
certificateContentString
: String
. certificate raw content
The certificate instance has the following properties:
isFormatValid
: Boolean
. Indicates whether or not the certificate has a valid formatcertificateImage
: String
. Raw data of the certificate imagechain
: Object
. Chain the certificate was issued ondescription
: String
. Description of the certificateexpires
: String
. Expiration dateid
: String
. Certificate's IDissuer
: Object
. Certificate issuerpublicKey
: String
. Certificate's public keyrawTransactionLink
: String
. Raw transaction IDreceipt
: String
. Certificate's receiptrecipientFullName
: String
. Full name of recipientrevocationKey
: String|null
. Revocation key (if any)sealImage
: String
. Raw data of the seal's image;signature
: String
. Certificate's signaturesignatureImage
: String
. Raw data of the certificate's signature image;subtitle
: String
. Subtitle of the certificatename
: String
. Name of the certificatetransactionId
: String
. Transaction IDtransactionLink
: String
. Transaction linkverificationSteps
: VerificationStep[]
. The array of steps the certificate will have to go through during verificationversion
: CertificateVersion
. Version of the certificateNote: verificationSteps
is generated according to the nature of the certificate. The full steps array is provided ahead of verification in order to give more flexibility to the consumer. For example, the consumer might want to pre-render the verification steps for animation, or render a count of steps and/or sub-steps.
A VerificationStep
has the following shape:
{
code: `stepCode`,
name: `Readable Step Name`,
status: `success`,
substeps: [
{
code: `subStepCode`,
name: `Readable Sub Step Name`,
status: `success`,
parentStep: `stepCode`
},
...
]
}
verify(stepCallback)
The function is asynchronous.
const certificateVerification = await certificate.verify(({code, name, status, errorMessage}) => {
console.log('Sub step update:', name, status);
}));
console.log(`Verification was a ${certificateVerification.status}:`, certificateVerification.errorMessage);
({code, name, status, errorMessage}) => {}
: Function
. Callback function called whenever a substep status has changed. The callback parameter has 4 properties:
code
: substep codename
: readable name of the substepstatus
: substep status (success
, failure
, starting
)errorMessage
: error message (optional)The final verification status:
{ status, errorMessage }
status
: final verification status (success
, failure
)errorMessage
: error message (optional)After adding "babal-polyfill" library for removing the regenertorRuntime error. it's giving the error t.resolve is not a function in the build/ployfill.js file. Please response ASAP.
Hi, I'm trying to follow the instruction in the doc but get the error: Certificate.parseJson is not a function.
var Certificate = require('cert-verifier-js');
var fs = require('fs');
fs.readFile('./sample.json', 'utf8', function (err, data) {
if (err) {
console.log(err);
}
console.log(data);
let cert = Certificate.parseJson(JSON.parse(data));
console.log(cert.name);
});
Need some help.
In default.js
, there's an enum for the blockchains and a string name:
Blockchain: {
bitcoin: "bitcoin",
testnet: "testnet",
regtest: "regtest",
mocknet: "mocknet",
ethmain: "ethmain",
ethropst: "ethropst",
ethtest: "ethtest"
},
There's also:
ChainSignatureValue: {
/*
These are the external display of `chain` in the signature suite. Adding a new type since `Blockchain` is
used by the web component and so we need to remain compatible.
*/
bitcoin: "bitcoinMainnet",
testnet: "bitcoinTestnet",
regtest: "bitcoinRegtest",
ethmain: "ethereumMainnet",
ethropst: "ethereumRopsten",
ethtest: "ethereumTestnet",
mocknet: "mockchain"
},
I'm wondering if it makes sense to combine these or maybe use ChainSignatureValue
strings for Blockchain
as well? In order to provide a more easily parseable string for frontends?
My main concern is with ethereum in this case. Maybe use ethereum
for ethmain and ropsten
for ethropst?
It can happen that the issuer
key is a string (most likely a URL). If such is the case, as the issuer
data is not stored in the certificate definition, the Certificate constructor will return just the URL of the issuer profile.
It would feel like an adequate responsibility to actually fetch the distant profile and populate the Certificate.issuer
with the distant data.
Tests too often timeout or fail because they are dependent on the network.
As we've done here (#462) for v1.2 we should stub the responses and the transaction data to avoid relying on third parties during unit tests.
We have been using the verifier package for some time on older versions, but after we realized that we need to upgrade to due api key requirement now we noticed that all later versions other than 3.2.1 do not seem to transpile properly. Here is the error I get when importing the package:
Import via:
import {Certificate} from '@blockcerts/cert-verifier-js';
Results in:
index.js:1 Error compiling schema, function code: var refVal1 = refVal[1]; var validate = function(data, dataPath, parentData, parentDataProperty, rootData) { 'use strict'; var vErrors = null; var errors = 0; var errs_1 = errors; var errs_2 = errors; if ((typeof data !== "number" || (data % 1) || data !== data)) { validate.errors = [ { keyword: 'type' , dataPath: (dataPath || '') + "" , schemaPath: '#/definitions/nonNegativeInteger/type' , params: { type: 'integer' } , message: 'should be integer' } ]; return false; } if (typeof data === "number") { if ( data < 0 || data !== data) { validate.errors = [ { keyword: 'minimum' , dataPath: (dataPath || '') + "" , schemaPath: '#/definitions/nonNegativeInteger/minimum' , params: { comparison: '>=', limit: 0, exclusive: false } , message: 'should be >= 0' } ]; return false; } } var valid2 = errors === errs_2; var valid1 = errors === errs_1; validate.errors = vErrors; return errors === 0; }; return validate;
I figured it may be an issue with babel config or node versions, so I tried to update that to be like what is in this repo. Still no luck. Here is current babel config:
presets: [
[
'@babel/preset-env',
{
targets: {
node: 'current',
},
},
],
],
overrides: [
{
test: ['./src'],
presets: ['next/babel'],
plugins: [['styled-components', {ssr: true}]],
},
],
};
Something changed in version v3.3.0 that is causing this issue. Any insight would be appreciated.
As used to validate expiration of credential
Recommended to avoid having the following runtime error:
only one instance of babel-polyfill is allowed
There was no NPM package published, so I published it : https://www.npmjs.com/package/cert-verifier-js
Did you have a reason not to publish it ?
I can add you as maintainers anytime.
verifier.js is checking in api.blockcypher.com for the transaction id.
But this API is showing that the transaction id does not exist.
https://api.blockcypher.com/v1/btc/test3/txs/52cbb934e0803ce7b26a98e669a25136221efaca4f65565da18d842e57e52f69?limit=500
But the same transaction is appearing in chain.so
https://chain.so/api/v2/get_tx/BTCTEST/52cbb934e0803ce7b26a98e669a25136221efaca4f65565da18d842e57e52f69
Have noticed many times that this happens with blockcypher (i don't know the reason though). So we would like to switch to chain.so for checking transaction id. Please let us know how to proceed on this.
With a specific error message "Could not obtain issuer profile".
Make sure all steps labels are capitalized: https://github.com/blockchain-certificates/cert-verifier-js/blob/master/src/data/i18n.json
Currently this relies on only 1 bitcoin explorer API to look up the transaction. This should promote a better practice and consult several.
Also should ensure we add documentation about other options, such as running a bitcoin node directly
how to show revoked reason if certificate is revoked from issuer?
This shouldn't only be for v2 certs, but all of them (or at least above and including v2):
https://github.com/blockchain-certificates/cert-verifier-js/blob/master/src/inspectors/computeLocalHash.js#L63
Also this should be done on a separate check
When passing a custom explorerAPI
with a set of keyPropertyName
& key
for a specific serviceName
, the key value pair (&|?keyPropertyName=key
) is only applied on the first verification flow, not on any subsequent verification.
Hi guys,
As you may be aware, etherscan has begun requiring API keys as of Feb. 15—yesterday.
This prevents ANY unmodified cert-verifier-js implementations—including blockcerts-verifier implementations and blockcerts.org(!!)—from validating Ethereum-based blockcerts (showing the "transaction occurred when issuing address wasn't valid" error).
Having broken verifiers all over the internet is a bad look for the Blockcerts ecosystem; so maybe a simple solution would benefit everyone.
My suggestion would be to allow people to pass their api key into cert-verifier-js, with api.js Line 30~ looking something like this:
[TRANSACTION_APIS.Etherscan]: {
main: `https://api.etherscan.io/api?module=proxy&apikey=${ETHERSCAN_API_KEY}`,
ropsten: `https://api-ropsten.etherscan.io/api?module=proxy&apikey=${ETHERSCAN_API_KEY}`
}
Then (ideally) I would allow that api key to be passed through blockcerts-verifier as a prop to cert-verifier-js.
I would love to help with this more directly but I haven't been able to easily build cert-verifier-js on my machine.
EDIT: Even though the api key is free, exposing it definitely isn't ideal. But it seems like it may be necessary as a stopgap measure/way for new users to get the verifier working until a more permanent solution can be devised.
Thoughts?
We need to be able to expose translated versions of the verification messages.
en-US
) should be the default languagecert-verifier-js
auto-detect the language (fallback to English en-US
)en-US
fallback if languages not available)For this feature we are introducing a second parameter options
(Object
) to the Certificate
constructor. This is a non breaking change as it will default to { locale: 'en-US' }
. Existing implementation of the library will still use english language by default.
import Certificate from '@blockcerts/cert-verifier-js';
// English language by default (no API change)
const certificate = new Certificate(certificate);
// Auto-detect language
const certificate = new Certificate(certificate, { locale: 'auto' });
// Enables translation, set static language
const certificate = new Certificate(certificate, { locale: 'es-ES' });
We need to expose the different languages codes available on the library:
import { getSupportedLanguages } from '@blockcerts/cert-verifier-js';
console.log(getSupportedLanguages()); // [ 'en-US', 'es-ES', ... ]
We also need to expose the current language locale code:
import Certificate from '@blockcerts/cert-verifier-js';
const certificate = new Certificate(certificate);
console.log(certificate.locale); // 'en-US'
The certificate.verificationSteps
property will expose the steps array filled with the localized translation.
Existing exposure of STEPS
and SUB_STEPS
objects will remain and use english language by default since they can be imported separately.
If certificate has an external context(that is not preloaded by default), verifier.js throws following error:
TypeError: request is not a function at loadDocument (./cert-verifier-js/verifier.js:21623:5) at jsonld.RequestQueue._loader (./cert-verifier-js/verifier.js:21598:5) at jsonld.RequestQueue.add (./cert-verifier-js/verifier.js:21382:10)
The verification step details need to be consistent, we are currently using lowercase and uppercase. Example image attached.
We should prob capitalize everything? @cjagers
Describe the cause. Is this a regression?
Are other areas of the code likely to be impacted? Does customer data need to be repaired? If customers may experience corrupt data or downtime, please notify in Slack #production channel immediately.
Should be a simple copy edit?
Which unit or integrations tests were added to address this going forward. Create github issues for any in addition to the bug fix
Describe the E2E test scenarios you performed in auto
Hey guys,
Is there a way to issue/sign certs in nodejs?
I've started working on a MerkleProof2017 npm module to sign certs.
https://w3c-dvcg.github.io/lds-merkleproof2017/
Have some issues and I am hoping somebody can help.
I am using the blockcerts sample 2.1 schema to test that I am getting the correct targetHash
2.1 Schema Blockcerts signed sample
{algorithm: 'URDNA2015', format: 'application/n-quads'}
: canonizeDatasha256
the canonized data however we are not getting the same targetHash
We got: df7c2bbd51a0865a990bbe33c0c760436294f41c8c2489869cc1c026b09b4e45
Sample cert: 4298534bd9ac0eeb59ccf767b2da67e4203abc66b9b7b4df398cdce50c4460b2
Clearly we are not hashing the correct data. Would be grateful if anyone could shed some light.
The module will be open source
Thanks
Currently, this repository has a few different options for support chains - but many other ethereum sidechains would be interested in using the blockcerts infrastructure for verifiable credentials. I recommend adding the ability to pass a custom RPC in order to look up transactions on other chains.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.