1.3.5 (2020-09-25)
1.3.4 (2020-08-07)
- deps: update dependency elliptic to v6.5.3 [security] (#241) (b601c62)
- make ClaimSpec.user_info and VerifiableClaimSpec.iss optional (#251) (d598623), closes #250
1.3.3 (2020-06-11)
1.3.2 (2020-06-11)
1.3.1 (2020-06-09)
- build: automatic release (b9847b9)
1.3.0 (2020-02-07)
- add support for did-jwt-vc (#192)
1.2.3 (2019-10-08)
- Fixes exports to allow
Credentials
to be used as a type
- New method
Credentials.createPersonalSignRequest()
for creating a message to request apersonal_sign
RPC call from a uPort mobile wallet - New method
Credentials.createTypedDataSignatureRequest()
for creating a message to request aeth_signTypedData
RPC call from a uPort mobile wallet - Support for
vc
property throughout messages, see accompanying notes in[email protected]
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.
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, priYeah vateKey})
This is a simple name change to clarify the fact this creates a request as part of a selective disclosure flow.
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.
Another name change to clarify that this request asks for a signature from a user, on the provided unsignedClaim
.
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.
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.
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.
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.
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, DID
s are resolved with the appropriate did-resolver
, which handles any lookup/document retrieval necessary for a particular DID.
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.
- Support seconds (instead of milliseconds) for JWT timestamps
- Support for encrypted push notifications
- Docs update
- Bugfix for
createRequest
- Use correct entry point for package