Version 1.1.7

• Minor bug fixes related to Infura URLs

Version 1.1.6

• Upgraded several dependencies to support Infura URLs that require a PROJECT ID

Version 1.1.5

• Upgrade uport-transports to use Infura URLs with API key

v1.1.4 Update did-jwt

• Upgrade to latest version of did-jwt

v1.1.3 Fix for CallBack

• Callbackurl has been added as a parameter in createVerification method
• rpcUrl has been added as a parameter in createDisclosureRequest method to support private chains
• upgrade to latest version of did-jwt

uPort Credentials 1.0

This release includes breaking changes, and marks the first release under the new name uport-credentials (formerly uport-js).

What's new in 1.0?

With the release of uPort Credentials v1.0.0, there are a number of changes to our API -- the main differences to watch out for are described in this document, and the full API reference can be found here. The primary changes consist of function name changes, with the hope of improving clarity. We have also clarified the role of this library as the primary method for creating and verifying messages in the form of verifiable claims, all of which are described in the uPort specs repo.

New static method createIdentity

With the new identity architecture used in this release, it is now possible to create a uPort identity without any on-chain interactions. This static method creates a new keypair of a did and privateKey, which are all that are necessary to create a new identity. A new Credentials object can then be instantiated with a brand new identity as follows:

const {did, privateKey} = Credentials.createIdentity()
const credentials = new Credentials({did, privateKey})

createRequest -> createDisclosureRequest

This is a simple name change to clarify the fact this creates a request as part of a selective disclosure flow.

New method createDisclosureResponse

To better support two-way communication between all types of uPort clients, it is now possible to create a disclosure response as well as a request from uport-credentials. This is the response part of the selective disclosure flow, and is equivalent to what gets returned by the mobile app when a disclosure is approved.

createVerificationRequest -> createVerificationSignatureRequest

Another name change to clarify that this request asks for a signature from a user, on the provided unsignedClaim.

receive, authenticate -> authenticateDisclosureResponse

The receive method has been removed, and the equivalent authenticate method has been renamed to reflect that it is verifying the response to a selective disclosure request, as well as the fact that the original request came from the verifying identity (i.e. the current Credentials instance). This makes the selective disclosure flow suitable for user authentication.

New method verifyDisclosure

This is a new function to verify a JWT that is not necessarily part of a selective disclosure request (e.g. a JWT that is part of a public profile, or given from a third party). It differs from authenticateDisclsoureResponse in that it does not verify an authentication challenge, so doesn't confirm that the request originated from this identity. Instead it just verifies the data and signer of the claim, and returns the verified object.

attest -> createVerification

We have renamed attest to better clarify that the return value of the attestation creation method is a JWT, and that it does no sending of the attestation/verification on its own. In addition, we have adopted the language verification to refer to the most general sense of attestation, claim, and credential, as the language often can get confusing.

New method createTxRequest

This is a request for a user to make an ethereum transaction. It provides the signature and address of the contract inside a signed JWT, allowing the recipient to verify the identity requesting that they make the transaction, and have the parameters and contract address pre-filled.

lookup -> removed

As the primary method for identity creation and management has changed, we no longer need to look up identities in a uport-specific contract. Instead, DIDs are resolved with the appropriate did-resolver, which handles any lookup/document retrieval necessary for a particular DID.

credentials.push -> removed

Push functionality is now handled by the new uport-transports library. Additionally, when using uport-connect, a Connect instance will make requests using push automatically if given permission from a mobile app.

v0.6.3 Required Upgrade to support new uPort Clients

What's New in Version [email protected]

• Backward compatible Ethr-DID response support that allows communication with IDs created with the ethr-did registry in the upcoming uPort mobile client release.

• Use the networkAddress key/value received in responses for all blockchain interactions if you have not already switched from using the address key/value. A networkAddress will continue to be a MNID encoded address for the network your app is configured for. It you are using the uPort subProvider this already happens by default. Continue to use the address key/value as you have for all other interactions (i.e as the subject for attestations issued). In the transition to DIDs the address key/value in a response may be a DID or MNID, but the libraries will set this appropriately to support both new and old mobile app identities.

Steps to migrate

• npm install uport

• Use networkAddress key/value in response for all blockchain interactions instead of address key/value if you have not switched already. Continue to use address key/value for all other interactions (i.e attestations). This change may not be required, its dependent on your current implementation.

Legacy support

• Versions 0.6.2 and earlier will continue to work with all uPort Mobile clients until the uPort Mobile clients with DID support are released in August (exact date listed once known).
• Once the new uPort Mobile clients are released, these clients will only work with versions 0.6.3 and later minor versions of uport-connect.
• 0.6.3 and later minor versions will remain backwards compatible, working with both current uPort Mobile clients and future releases.