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

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.

problem described here:
http://community.blockcerts.org/t/cert-verifier-root-error-key-not-found-not-found-id-error-solved/282/3?u=kim

With a specific error message "Could not obtain issuer profile".

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.

how to show revoked reason if certificate is revoked from issuer?

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

1. clone this repo
2. create an empty page and set script source to src='./dist/verifier-iife.js'
3. run new Verifier.Certificate(certificateDefinition) using a valid blockcert;
4. 503 appears in javascript console:

Failed to load resource: the server responded with a status of 503 ()

Expected behavior

No 503 is expected

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?

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.

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?

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:

• Node version: 12.13

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

We need to get another certificate v1.2 I guess.

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

As used to validate expiration of credential

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.

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

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

1. Go to blockcerts.org
2. In put this certificate, which does not have a revocationList property directly inside it: https://github.com/AnthonyRonning/https-github.com-labnol-files/blob/master/test/test-revocation.json
3. See that it passes verification (as a testnet cert)

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

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.

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.

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.

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)

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.

all of the verification E2E testcases are testnet; need to include mainnet

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.

A public key is lingering in the code, let's remove it by adding the ability to pass keys from outside

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

Make sure all steps labels are capitalized: https://github.com/blockchain-certificates/cert-verifier-js/blob/master/src/data/i18n.json

• address the current Ethscan configuration: the API key is hardcoded in the constants, which works but is no ideal
• implement more Ethereum APIs

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.

Recommended to avoid having the following runtime error:
only one instance of babel-polyfill is allowed

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:

1. Put each of these certs into blockcerts.org

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.

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.

Allow exposing types and also improve confidence in code.
Will be useful for #471

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.

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

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.

Bug Report

Issue description

The verification step details need to be consistent, we are currently using lowercase and uppercase. Example image attached.

Steps to reproduce the issue

1. Just verify a certificate and click to read details for each step.

What's the expected result?

We should prob capitalize everything? @cjagers

What's the actual result?

Additional details / screenshot

Investigation

Cause

Describe the cause. Is this a regression?

Impact

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.

Fix

Should be a simple copy edit?

Tests

Unit and Integration Tests

Which unit or integrations tests were added to address this going forward. Create github issues for any in addition to the bug fix

E2E Tests in Auto

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

1. The first step was to remove the signature.
2. Next, we canonized the data as per the spec {algorithm: 'URDNA2015', format: 'application/n-quads'}: canonizeData
3. Finally we sha256 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

Goals

• update API design to reflect the verification steps update
• simplify the current API: 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 function
• introduce an easier way for a consumer app to know if a certificate has a valid format or not
• ...

Contribution

This is a shared effort, any suggestion is most welcomed.

Proposal

Usage

import Certificate from 'cert-verifier-js'; 
const certificate = new Certificate(certificateContentString);

API

constructor(certificateContentString)

const certificate = new Certificate(certificateContentString);

The constructor automatically parses a certificate.

Parameter

certificateContentString: String. certificate raw content

Instance

The certificate instance has the following properties:

• isFormatValid: Boolean. Indicates whether or not the certificate has a valid format
• certificateImage: String. Raw data of the certificate image
• chain: Object. Chain the certificate was issued on
• description: String. Description of the certificate
• expires: String. Expiration date
• id: String. Certificate's ID
• issuer: Object. Certificate issuer
• publicKey: String. Certificate's public key
• rawTransactionLink: String. Raw transaction ID
• receipt: String. Certificate's receipt
• recipientFullName: String. Full name of recipient
• revocationKey: String|null. Revocation key (if any)
• sealImage: String. Raw data of the seal's image;
• signature: String. Certificate's signature
• signatureImage: String. Raw data of the certificate's signature image;
• subtitle: String. Subtitle of the certificate
• name: String. Name of the certificate
• transactionId: String. Transaction ID
• transactionLink: String. Transaction link
• verificationSteps: VerificationStep[]. The array of steps the certificate will have to go through during verification
• version: CertificateVersion. Version of the certificate

Note: 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);

Parameter

({code, name, status, errorMessage}) => {}: Function. Callback function called whenever a substep status has changed. The callback parameter has 4 properties:

• code: substep code
• name: readable name of the substep
• status: substep status (success, failure, starting)
• errorMessage: error message (optional)

Returns

The final verification status:

{ status, errorMessage }

• status: final verification status (success, failure)
• errorMessage: error message (optional)

Hi!
I noticed that python and js versions differently compare Merkle root.
In JS validation is more strict and if your transaction's input has additional data - validation fails.
But it will pass in python.

Is additional tx input allowed?

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.

Feature

We need to be able to expose translated versions of the verification messages.

Requirements

• Enabling translation should be optional
• English (en-US) should be the default language
• Consumer should let cert-verifier-js auto-detect the language (fallback to English en-US)
• Consumer should be able to set a static language (English en-US fallback if languages not available)

Proposal

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.

Static constants

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)

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.

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.

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