Version 1.1.11

• Added ability to specify brandColor param that can be used by uport mobile app to style requests from your app. (Note: this feature has not yet been released in the mobile app, will update with the version number when it does)

Version 1.1.9

• Minor bug fixes related to Infura URLs

Version 1.1.8

• Upgraded uport-transports to include Chasqui URL fix

Version 1.1.7

• 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

Version 1.1.2

Connect

• Includes support for requesting ethereum accounts on a private chain, by providing a unique chainId and rpcUrl in a disclosure request
• Bumps versions on several dependencies for bug fixes and additional features

UportSubprovider

• Adds dialog to select injected providers when present. Enables dapps to support both uPort and Metamask/Mist/Coinbase Wallet etc. as web3 providers with the same code

Version 1.1.1

Personal Sign Flow

The uPort mobile app now supports "personal sign" functionality, and there is a new message to make such a request to a uPort mobile app. For uport-connect, support for this feature includes:

• New method Connect.requestPersonalSign(data, id, sendOpts) which creates and sends a personal sign request message to a mobile app. Its response may be listened for with Connect.onResponse as all other messages.
• Support for personal_sign RPC call (invoked by web3.personal.sign, e.g.) in UportSubprovider, via the above method on Connect

Typed Data (ERC712) Signature Flow

The uPort mobile app also supports the new eth_signTypedData RPC call defined by the EIP712 Specification. Correspondingly, this library now includes:

• New method Connect.requestTypeDataSignature(typedData, id, sendOpts), which creates and sends a typed data signature request message to a mobile app. Its response may be listened for with Connect.onResponse as all other messages.
• Support for eth_signTypedData and eth_signTypedData_v3 RPC calls in UportSubprovider, via the above method on Connect

uPort Connect 1.0

What's new in 1.0?

With the release of uPort Connect 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.

ConnectCore -> Connect

First, on the module level, there is no longer a ConnectCore class. All core functionality is now implemented by the Connect object, instantiated as new Connect(appName, opts). Supplemental "transports" which facilitate communcation with the mobile app have moved to a new repository, uport-transports. The transports used in Connect are configurable, and you also have the option of providing custom transports in the constructor. See the transport, pushTransport, and mobileTransport options in the configuration object.

No public keys in the browser

There was previously confusion about how to keep private keys safe when Connect required its own keypair in order to sign messages. To aleviate this, we no longer require that Connect is instantiated with a privateKey or signer; instead, when a Connect is instantiated for the first time on a particular site, it generates a new keypair in the browser to serve as the instance's identity. This is the identity that will sign requests to a mobile app, and the mobile app user can confirm that subsequent requests come from the same identity. It is still the case that signing a claim with a particular unique identity (which may belong to your application or company) requires that the keypair for that identity be stored somewhere secure (such as a server), and client

localStorage Persistance

As mentioned above, the keypair that is created on construction of the Connect object is saved to localStorage, and is used to re-instantiate the object with the same keypair when the site is reloaded. Additionally, the did and address of the most recently authenticated user, and any verified claims they have shared with the application are persisted in localStorage, so that they need not be requested again when a user revisits the page. Note that this does not share the information with any external service, and is intended to allow applications to maintain something akin to a session without storing a user's information on a server. For more information about controlling the persistance behavior of Connect, see the API reference

New functions logout, reset

To clear all saved data about a user from the browser, use the logout() method. To additionally destroy the keypair, and so the application's identity, use reset(). Note that following a reset, the user will be prompted to create a new identity in the mobile app upon the next interaction, and will not be able to associate the new browser identity with the old.

mnid, address, did

With v1.0, we have changed our underlying architecture to use Decentralized Identifiers (DIDs) as our primary ID. We retain support for old identities via the did:uport: did method, while new accounts are created using the did:ethr: did method. The did of the currently authenticated user is readable from a connect instance as connect.did. The address field now returns the ethereum address of the currently authenticated user, and the mnid field is an encoding of the address along with the network id, described further here.

<request>.then() -> onResponse(requestId).then()

In order to address issues that can arise with page reloading when switching between mobile browsers and the uPort app, this release decouples the concepts of requests and responses. Where previously a request would return a promise which would resolve when the response was available, now each request requires a requestId, which is then used to listen for the response. This is a much more powerful pattern, that allows for more customized handling of requests and responses potentially on different pages of an app, and the request flow itself is stateless with respect to the browser.

requestAddress -> requestDisclosure

The requestAddress function has been removed, and address and did are returned by default for all disclosure requests. Use requestDisclosure() instead.

attestCredentials -> sendVerification

Renamed to make names more consistent across our libraries.

request -> send

This is the function that sends a pre-signed JWT to the mobile app using the appropriate transport. It was renamed to clarify it's role as the function that actually invokes the transports.

(new Connect(appName, {provider})).getProvider() -> connect.getProvider(provider)

By default, uport-connect now uses ethjs as our base web3 provider. To pass a different base provider onto which uport functionality should be applied, pass the provider instance to the getProvider instance method, and the returned UportSubprovider will wrap the given provider. Note: some providers may not play nicely with the added uport functionality.

connect.getWeb3 removed

To reduce bundle size for those who do not need it, we no longer bundle web3 with uport-connect. To get a web3 object configured with uPort functionality, created a new web3 instance with the UportSubprovider returned by getProvider, i.e.

const web3 = new Web3(connect.getProvider())

v0.7.5 Required Upgrade to support new uPort Clients

What's New in Version uport-connect@0.7.5

• 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-connect

• 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.7.3 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.7.5 and later minor versions of uport-connect.
• 0.7.5 and later minor versions will remain backwards compatible, working with both current uPort Mobile clients and future releases.