Using custom remote contexts

#1

Any advice on adding my own contexts remotely to my credentials?

Whenever I try to implement credentials with my own context I receive a jsonld error

pyld.jsonld.JsonLdError: ('Could not retrieve a JSON-LD document from the URL.',)

Type: jsonld.LoadDocumentError

Code: loading document failed

Details: {'remoteDoc': {'contextUrl': None, 'documentUrl':
#2

After more testing. In my @context, if I use the url that contains the v2.1 blockcerts context from the blockcerts url (https://www.blockcerts.org/schema/2.1/context.json) I get json-ld parsing errors, BUT if I use the https://w3id.org/blockcerts/v2.1 link that redirects to the context on the blockcerts domain then the issuer yields no errors. What is the difference between these two links as far as the issuer is concerned?

#3

I am not sure about the internals of jsonld which I have had to debug at times, but w3id.org is there to provide some sort of normalization of the data. However in early days of v3 blockcerts referencing a URL that was not going through w3id.org was working. So from what you describe, I don’t know what the error could be.
Is your custom context a valid jsonld? You should be able to specify a third context or extra properties, as we do with Learning Machine (displayHTML, metadataJson, etc).

#4

I have successfully linked direct contexts using the additional_global_fields for displayHTML and others but when I try to add another url to a remote context it gives me the error, I have validated that it is valid jsonld using the jsonld playground(JSON-LD Playground). The main reason I need this is that the Open Badges validation is yielding error from all 4 of the open badges extensions that blockcerts uses (RecipientProfile, SignatureLine, MerkleProof2017 and MerkleProofVerification2017).

#5

if you can provide me with an example I can to see what’s happening locally

#6

or at least a link to the context you are trying to use as an extra

#7

I sent you the link to the remote context I am trying in a PM.

#8

After coming back to this I noticed this line on the cert_schema repo here

def to_loader_response(data, url):
    return {
        'contextUrl': None,
        'documentUrl': url,
        'document': data
    }


def load_document(url):
    """
    :param url:
    :return:
    """
    result = validators.url(url)
    if result:
        response = requests.get(
            url, headers={'Accept': 'application/ld+json, application/json'}
        )
        return response.text
    raise InvalidUrlError('Could not validate ' + url)


def jsonld_document_loader(url):
    """
    Retrieves JSON-LD at the given URL. Propagates BlockcertValidationError is url is invalid
    or doesn't exist
    :param url: the URL to retrieve
    :return: JSON-LD at the URL
    """
    data = load_document(url)
    return to_loader_response(data, url)


def preloaded_context_document_loader(url, override_cache=False):
    if url in PRELOADED_CONTEXTS:
        context = PRELOADED_CONTEXTS[url]
        return to_loader_response(context, url)
    else:
        return jsonld_document_loader(url)

the cert_schema is sending a response that doesn’t include any contentType which causes the pyld to yield invalid json if you use a context that isn’t included in the Preloaded contexts list.

Edit: I was able to issue a credential with a remote context after making a change to cert_schema’s to_loader_response return value but now with the custom context the verifier is yielding the “Not a Valid Blockcerts Credential” error when I attempted to verify the credential through blockcerts-verifier.

#9

Can someone help me understand what is happening in this function. I think this may be the source of my remote context parsing issue

const blockcertsContext = context.filter(ctx => typeof ctx === 'string').find(ctx => ctx.toLowerCase().indexOf('blockcerts') > 0);
  const blockcertsContextArray: string[] = blockcertsContext.split('/').filter(str => str !== '');

  const availableVersions: string[] = Object.keys(versionParserMap);

  return parseInt(availableVersions.filter(version => lookupVersion(blockcertsContextArray, version.toString()))[0], 10);
#10

Hi @ampatt97 glad you identified your issue, I couldn’t really understand your problem with what you shared with me.

I am a bit surprised by your first post, I believe there is a fetching action for non referenced (preloaded) contexts.

In the verifier “Not a Valid Blockcerts Credential”, you should be seeing the error in the console: blockcerts-verifier/parse.ts at master · blockchain-certificates/blockcerts-verifier · GitHub

Lastly the function you mentions retrieves among the different contexts the one that is referencing blockcerts, and then we analyze the version to know if it’s a v1, v2 or v3 certificate. I have not experienced issues with it but I guess it’s also because we are always expecting one of the contexts to be bound to blockcerts (either through w3id or through blockcerts.org).

If you completely moved your context to something not blockcerts, I would actually recommend that you maintain the blockcerts one, and use yours as an extension of said context, that you reference after (that way you may rewrite some of the semantics to suit your need). The other solution is to go and modify the cert-verifier-js to your needs.