Authorization endpoint for gaining token used for API requests requiring bearerAuth.

You will be provided the required client_id and client_secret as part of onboarding.

A custom domain allows the display of your credentials or presentation requests to be rendered under the domain your preference as a tenant on the Mattr VII platform.

The verifiable custom domain can be mapped with that of the issuer or verifier stated in a credential or presentation and allow for the following attributes to be defined and returned:

• Organisation Name
• Domain Name
• Logo
• Home Page

Returns

On Success, the response from the endpoint always include the Custom Domain

Retrieve the custom domain information and it's veification status for your Mattr VII tenant.

Delete the custom domain.

By deleting your existing custom domain it will break the linkage with any credentials issued under the custom domain, in turn causing issues when holders of those credentials go to present them.

Update the custom domain.

Follows the same structure as the Create a Custom Domain endpoint.

Verifies that you have control of the custom domain by examining the TXT record of the domain.

Returns a list of Decentralized Identifier (DID) Configuration entries from the tenant.

See https://identity.foundation/.well-known/resources/did-configuration/

These entries are automatically configured for all DIDs created by the tenant and is used for any party wanting to establish the relationship between domain ownership and the DIDs by exposing cryptographic proofs.

This endpoint is unprotected, public facing and can be determinisically found at the root of the tenant subdomian or alias by any party wishing to discover the domain to DID relationship.

Resolves the DID provided in the path to its DID Document from the DID method and method identifier. The DID Document may contain cryptographic material like a public key and service endpoints.

Example:

did:sov:1234556 - will be referenced on the Sovrin network did:key:z6Mkjr7vfzBfamiN6Wi6cyQUgTq6CEMXP1MzWQawsUEXJoa9 - the public key is encapsulated in the DID

Returns

The DID Document is returned along with meta-data already held about the DID by the tenant;

• Registration Status: Given there can be a lag in writing on-ledger DIDs this status will be updated over a short timeframe (usually within 10 minutes).
• Registered: Timestamp of registration.
• Keys: A reference to the Keys in a KMS

Delete a DID

Returns a list of all DIDs (Decentralized Identifiers) managed by the tenant and their associated meta-data.

Takes a supported DID Method and generates keys and associated information for a new DID and registers the DID Document if applicable.

Methods supported:

• key
• web
• sov

During a trial any did:sov DIDs will not reside on the Sovrin MainNet, and when migrating to the MainNet any sov DIDs will be removed. Any did:sov DIDs created using this endpoint should be considered as experimental as well as any credentials created using them.

Creating did:key

A DID with a DID method of key can be created as follows.

• {"method": "key", "options": {"keyType": "ed25519"}}
• {"method": "key", "options": {"keyType": "bls12381g2"}}

If no options are provided, a DID will be created with an ed25519 key type.

If the key type in options is set to bls12381g2 a DID will be created with a BLS key type which supports BBS+ signatures for issuing ZKP-enabled credentials.

A DID created with an experimental bls12381g2 key type can only be used for issuing credentials.

Creating did:web

A DID with a DID method of web can be created as follows.

• {"method": "web", "options": {"domain": "mattr.global"}}

The returned initial DID Document then needs to be hosted so that it is accessible from the domain provided in the options, e.g. https://mattr.global/.well-known/did.json.

When the DID Document is not available for download from the domain, the Registration Status of the DID is PROCESSING.

Once the DID Document can be downloaded from the domain, the Registration Status will be COMPLETED.

Note that the tenant will be able to prove ownership of the keys associated with the did:web DID Document through the well-known endpoint, i.e. https://tenant.vii.mattr.global/.well-known/did-configuration, while the DID Document hosted on the domain links the DID to a domain.

Creating did:sov

A DID with a DID method of sov can be created as follows.

• {"method": "sov"}

The Registration Status of the DID is updated over a short timeframe due to the lag incurred in registering the DID Document, which may take up to 10 minutes.

During a trial DID Documents are anchored on a private Indy pool not the Sovrin MainNet. Please contact us to discuss further options.

Returns

The DID, associated metadata and registration status.

Unsupported Methods result in a 400 response with an "Invalid value" message.

Creates a Verifiable Credential (VC or just Credential) in a JSON-LD format adhering to the W3C VC Data Model spec.

Creating the Payload:

The values required by the operation are validated where available and used to construct the Verifiable Credential.

The Credential is issued using JSON-LD with linked data proofs, the type values of the Credential and the Subject Claims must be represented by a schema in @context.

The schema https://www3.org/2018/credentials/v1 is always required in addition any @context values, so that the Credential can be referenced.

The type value of VerifiableCredential must be used as the first value in the array to conform to the W3C VC Data Model spec.

Subject Identifiers

In general, the Subject identifier in the subjectId field should have been authentically bound to the subject and authenticated against the information used in the claims, for example by using an OpenID Connect authentication flow or another mechanism including out-of-band processes.

Credentials may be issued without subject identifiers, this covers uses-cases, where the credential cannot or does not need to be adequately bound to a Subject DID and may be treated as a bearer credential or reissued at a later time once the credential can be bound.

ZKP-enabled BBS+ credential:

If you wish to issue a ZKP-enabled Verifiable Credential, the provided issuer id must be a did:key with a key type of bls12381g2. The platform will automatically detect this capability and issue a ZKP-enabled BBS+ credential. Note that the schema https://w3c-ccg.github.io/ldp-bbs2020/context/v1 will automatically be added to the @context in the credential.

During Preview this feature is experimental. It may change over time and may require credentials to be reissued.

Credential meta-data:

Setting the persist value to true will store the entire credential contents as well as the meta-data on the platform. If set to false only the credential meta-data is held on the platform:

• id
• tag (optional)
• credentialStatus (optional)
• issuanceDate

The optional tag value can be used to externally reference the issued credential.

Returns

On success, the Verifiable Credential is always provided in the response along with meta-data. Subject bound credential should be delivered to the intended subject.

Returns a list of all credential data stored in the tenant.

In the list

Inside the data array, there is an body for each credential issued on the platform, in addition to the id the body will contain optionally added meta-data and may contain the entire credential contents if persist was invoked during credential creation.

Credentials issued via the OIDC Bridge are set not to be persisted.

Pagination

Pagination can be controlled by a cursor method using the cursorand limit query parameters. The nextCursor is found at the start of each returned range of credential entries and the limit determines how many entries are returned in that request, with a maximum value of 1000.

Not using a query parameter defaults the response to return the first range of credential entries with a limit of 100.

The optional tag filter or the Credential type can be used to retrieve credential data.

Get data for a previously created credential using its ID.

In addition to the id the body will contain optionally added meta-data and may contain the entire credential contents if persist was invoked during credential creation.

Credentials issued via the OIDC Bridge do not have their contents persisted.

Remove all stored credential data from the tenant using its ID.

The entire entry including meta-data and the credential contents is removed from the system and cannot be recovered.

Send any JSON-LD Verifiable Credential that conforms to the W3C Verifiable Credentials data model to perform verification checks and return a response:

• Issuer DID can be resolved
• JSON-LD context is valid for subject claims
• Proof is valid & the credential has not been tampered with
• Is not in a revoked status on a RevocationList2020 This endpoint can be used to check any Credential issued by any service provider.

A credential can be revoked by setting the revocation status.

Retrieve the revocation status of a certain credential.

Returns

The revocation status of the credential

Retrieve the revocation list that contains the revocation status of a number of credentials.

Returns

The revocation list

Create a payload that can form a message in the JWM format that can be used in sending notifications to subjects based on the revocation status of their issued credentials.

• Use a DID setup on the tenant as the from value, this should be a DID with a key type suitable for messaging (not a BLS key type)
• Include a SubjectDID as the to value - this value is only used in the message construction, it should be the same value as the intended recipient.

To send a notification to the Subject DID holder, use the payload with the /messaging/encrypt and /messaging/send endpoints.

A Presentation Request Template defines which credentials are required for presentation. This is used to create the actual Presentation Request, which is used by the Mobile Wallet to select which credential it should display to the Holder, asking for confirmation to be used in the Presentation to be sent.

Creating the payload

The domain value must always match the domain of the tenant being used.

The name value is a convenience attribute for quickly determining the intended purpose of a created template.

The Presentation Request query follows the Verifiable Presentation Request Specification.

The following query methods have been enabled:

• Query by Example
• Query by Frame
• DID Auth

Query can accept an array of types, which makes is possible to construct complex presentation requests from the template, however creating a valid Presentation Template does not ensure that logically valid Presentation Request is created or that a credential holder would be able to satisfy the request.

Query by Example

This is a basic form of requesting credential information, it is possible to limit the request based on:

• Credential Type - based on the type of the credential
• Specific Trusted Issuer DIDs - an array of DIDs that the credential must have been issued by one of.

Query by Frame

Used primary for requesting specific claims from ZKP-enabled credentials, only the claims requested in the frame will be derived and sent in the presentation.

• Credential Type - If an array should match the exact type used in the Credential otherwise a string is required to be VerifiableCredential.
• CredentialSubject - request specific claims from a credential subject.
• Specific Trusted Issuer DIDs - an array of DIDs that the credential must have been issued by one of, ensure this DID is of a BLS key type that has issued a ZKP-enabled credential.

DID Auth

The type of Template will result in a DID Auth flow resulting in just the Subject DID from the holder to be provided in the response to the Presentation Request.

• DIDAuth

Returns

On Success, the response from the endpoint always include the Presentation Template ID, this UUID is required in OIDC Bridge Verifier instance setup and using the Verify using a Callback method. The Presentation Request endpoint uses this ID to determine the exact type of request message to create.

Returns a list of all Presentation Templates on the tenant.

Use the name value to determine the intended purpose of the templates.

Retrive a Presentation Template by providing a template ID

Delete a Presentation Template

Update a Presentation Template using the template id.

Follows the same structure as the Create a Presentation Template endpoint.

Creates a short lived Presentation Request.

Creating the payload

A challenge can be used to collerate requests The DID is used a Verifier DID to prove the authenticity of the Request to holders Any callbackUrl provide will be called on receipt of the response to the Presentation Request. If no expiresTime is provided, a default of 5 minutes will be used.

Returns

The request object holds the Presentation Request in the form of a constructed JWM message.

The request needs to be signed and conveyed to the holder, using techniques like a QR, deeplink or encrypted and sent via a notification message.

Create a Verifiable Presentation on your tenant by providing one or more Verifiable Credentials.

To successfully create a Verifiable Presentation using this endpoint you must supply;

• a holderDiDUrl that is controlled by the tenant

And optionally;

• a credentials collection containing only credentials with a subject DID that is controlled by the tenant

The resulting Verifiable Presentation will contain a proof generated via the holder DID and each unique subject DID in your request.

Non-subject-bound (bearer) credentials are not supported.

Use this endpoint to verify a Verifiable Presentation that has been generated by any platform that adheres to the W3C Verfiable Credential Data Model.

Provide a presentation in the Request

The platform ensures that the presentation conforms to the VC Data model and thus for each verifiableCredential object that is present there (if any), it will perform the following checks;

• Issuer DID can be resolved
• JSON-LD context is valid for subject claims
• Proof is valid & the credential has not been tampered with
• Is not in a revoked status on a RevocationList2020
• The proof is valid for each subjectDID to prove ownership

Finally, the platform ensures a proof is valid for the holderDID in the presentation.

Response

If all checks are passed then the verified boolean is true Otherwise it returns false with a basic reason

Further detailed reasons for verified false responses is a future roadmap item.