Mobile

Sections

Scannable QR Codes

Scannable QR Codes

There are 4 types of scannable QR codes that the mobile app accepts. Each of the following sections provides details of each type. See global requirements for information pertaining to all QR code types.

Connect

This type of QR code is generated for peer to peer communication. When scanned, the embedded URL is used for requesting a connection to the inviting party (generator of the QR code). An example could be if a business sent out a flyer with a connect QR code printed on it. Receivers of the flyer would be able to scan the code to request a connection to the business.

The QR code can be built using our proprietary format or an Aries standard interoperable format.

1. Proprietary format

QR-connect

Example Data

{
    "type": "connect",
    "data": {
        "name": "Archer",
        "url": "https://agency.dev.ti.verify-creds.com/a2a/v1/messages/281b767b-0b48-472d-832c-26c9bd09b3ed/ci_urls/e1715f8f-f50c-4ee2-9d49-018867b8f329"
    }
}

Data Parameters Explained

  • name : [Optional] The name of the user
  • url : shortURL of the generated connection invite.
2. Aries standard interoperable format

IBM Verify Credentials mobile app is interoperable with Aries standard invitation scannable QR Code.
An invitation as created by the POST /api/v1/invitations call contains two generated fields: url and short_url. A QR code which contains the value of the url field adheres to the Aries standard referenced above which is part of the Aries Interop Profile version 1. A QRCode which contains the value of the short_url field adheres to an emerging Aries standard but has not yet been fully accepted.

Example Data:

https://agency.url.com/a2a/v1/messages/10187441-56b1-43e4-ac21-8e8a14fc933c/ci_urls/89cb2115-e152-456f-b288-61cb283bcbc1

or

https://agency.url.com/invitation?c_i=eyJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwiQGlkIjoiODljYjIxMTUtZTE1Mi00NTZmLWIyODgtNjFjYjI4M2JjYmMxIiwibGFiZWwiOiJteUFnZW50MSIsInJlY2lwaWVudEtleXMiOlsiNFV2a2d2UVl5cWVMUUFtWGtDNXVDa0hzNEIyRUhlclBnTXVnTHBielhXWm0iXSwic2VydmljZUVuZHBvaW50IjoiaHR0cHM6Ly9hZ2VuY3kuZGV2LnRpLnZlcmlmeS1jcmVkcy5jb20vYTJhL3YxL21lc3NhZ2VzLzEwMTg3NDQxLTU2YjEtNDNlNC1hYzIxLThlOGExNGZjOTMzYyIsInJvdXRpbmdLZXlzIjpbXSwiZXh0Ijp0cnVlfQ==

Credential

This type of QR code is used for a user to request a credential from an issuer. The issuer - the State of Arizona for example - would provide this QR code for its residents who wish to request an official Driver's License. When the user scans this code, their currently selected agent will first determine if a connection already exists with the issuer. If so it will use it. If not, it will first send a connection offer before continuing on to send the credential request.

QR-credential

Example Data

{
    "type": "credential",
    "data": {
        "name": "Arizona DOT",
        "url": "https://azstate:@124dff934a7e113aac08e8e2dd31dab59febfa3b3577f61059f82e93.staging-cloud-agents.us-east.containers.appdomain.cloud",
        "schema_name": "AZDOT",
        "schema_version": "1.2",
        "meta": {}
    }
}

Data Parameters Explained

  • name : [Optional] The name of the issuer
  • url : The URL of the issuer's agent, where the credential request will be sent, and from which the credential will be received.
  • schema_name : Credential schema name
  • schema_version : Credential schema version

Additional Notes:

  • schema_name and schema_version together are used to describe the credential object.

Proof

There are 2 different types of proof QR codes. A QR code can either request a proof, or provide proof.

Requesting Proof

This type of QR code would be displayed by a verifier. When a mobile app user scans one of these QR codes, their currently selected agent will first determine if a connection already exists with the verifier. If so it will use it. If not, it will first send a connection offer before continuing on to send the verification request. This is a request for the verifier to send a proof request back to the user's agent. Any meta information included in the QR code will be included in the verification request back to the verifier. This information could be used, for example, by the verifier to correlate an incoming verification request to a user session in their web app. Upon receiving this verification request, the verifier should change the state of the verification from inbound_verification_request to outbound_proof_request in order to send the desired proof request back to the user's agent.

QR-requestProof

Example Data:

{
    "type":"proof",
    "data":{
        "name":"bbcu",
        "nickname":"Big Blue Credit Union",
        "verifier":"https://bbcu:@bcd483d6e49b3316cf9c54094c73a441a36c1e89ae1a7eb213de7c2b.staging-cloud-agents.us-east.containers.appdomain.cloud",
        "proof_schema_id":"Verify Employment:1.01588005388732",
        "wait":false,
        "meta":{
            "nonce":"dg8zU9Wf49sJ24Q8gjUa",
            "username":""
        }
    }
}

Data Parameters Explained

  • name : Verifier name
  • nickname : UI use only. This value is not read or returned by mobile SDK.
  • verifier : The URL of Verifier's Agent where the verification request will be sent and from which the proof request will be received
  • proof_schema_id : The id of a proof schema already published by the verifier. A proof schema describes the credential (or self-attested) values needed to satisfy the proof.
  • wait : T=Wait for proof to be verified before returning (True/False)
Offer Proof

This type of QR code would be used to offer proof to an end-user. An example would be if a bank wished to prove to a potential client that they are FDIC insured. A client could scan the code, which would prompt the bank to respond with information from their FDIC credential.

QR-offerProof

Example Data

{
    "type": "proof",
    "data": {
        "schema_name": "FDIC",
        "schema_version": "1.0",
        "schema": {},
        "prover": "https://bbcu:@bcd483d6e49b3316cf9c54094c73a441a36c1e89ae1a7eb213de7c2b.staging-cloud-agents.us-east.containers.appdomain.cloud",
        "wait": false,
        "meta":{
            "nonce":"02BTvpCW1jKwFZ8AFK6T",
            "username":""
        }
    }
}

Data Parameters Explained

  • schema_name : Schema name
  • schema_version : Schema version
  • schema : Full JSON proof schema object
  • prover : The URL of Prover's Agent where the proof request will be sent and from which the verification will be received.
  • wait : T=Wait for proof to be verified before returning (True/False)

Additional Notes:

  • if schema_name exists, it will be used along with schema_version to determine the JSON proof schema object. Otherwise, schema will be used - which must contain the entire object, which could be too large for storage in a QR code.

Agent

This QR code is intended for connecting your mobile device to an existing agent.

QR-agent

Example Data:

{
    "type":"agent",
    "data":{
        "url":"https://agency.dev.ti.verify-creds.com",
        "name":"CIA",
        "pw":"somepassword",
        "user":"281b767b-0b48-472d-832c-26c9bd09b3ed"
    }
}

Data Parameters Explained

  • url : Agency URL
  • name : Name of the agent (what you wish to call it on your device)
  • pw : Agent password
  • user : Agent ID

Additional Notes:

  • if name is not provided, one will be automatically generated "IBM Agent - user"

Global Requirements

  • All QR codes must translate to data in JSON format
  • There must be a type, and this must be one of the 4 accepted types detailed above (agent, connect, proof, credential).
  • There must be a data object containing all type-specific parameters.
  • The data:meta field can be used by the creator of the QR code for tracking any additional information, such as nonce. A nonce is used in our examples as a method of tracking unique sessions. See Proof for an example of when a nonce stored in the metadata is used. Any metadata received by the mobile interface via a scanned QR code will be included in the generated response.