uport-project / specs

uPort Protocol Specs

title	index	category	type	source
Uport Specs	3	specs	reference	https://github.com/uport-project/specs/blob/develop/README.md

uPort Specs

uPort is a platform for user centric identity and communication. The platform currently consists of our mobile app, Ethereum smart contracts and number of open protocols for signed messages and message flow.

Identities

An identity in uPort is really just someone or something that can sign data or transactions and also receive signed data about itself.

An identity has:

• An Identifier in the form of a Decentralized ID (DID)
• A signing key
• A public key stored on the uPort Registry

An identity can:

• Sign JWTs (JSON Web Tokens)
  • Authenticate themselves to a third party
  • Disclose private information about themselves
• Receive requests for disclosure about themselves
• Receive and store signed third party verifications about themselves
• Sign Ethereum transactions

Identities created using the uPort Mobile App

Currently most uPort users manage their identities through our mobile app. Identities created today consist of an instance of the Proxy smart contract deployed on a supported Ethereum-compatible blockchain.

Request Flows

A request will typically be signed by a client app and sent to mobile app using this generic request flow:

We currently support the following flows:

• Selective Disclosure Flow
• Send Verification Flow
• Ethereum Transaction Request Flow
• Private Chain Flow

More about request flows

Request and Response Transports

There are various ways that requests can be sent to the uPort app and how responses can be returned.

Request/Response Transports

Off-chain Messages

Most request and responses are performed privately off-chain between the different parties to a flow.

Most off-chain messages consist of signed JWTs (JSON Web Tokens) as defined in RFC 7519. Signatures are verified using our simple uPort PKI (see later in this document).

More about Off-chain Messages

On-chain Transactions

The user can sign Ethereum transactions using the mobile app.

More about Signing Ethereum transactions

uPort PKI

uPort implements a simple yet general purpose decentralized PKI system making it easy to create and verify off-chain JWT messages.

More about the uPort PKI

specs's Issues

Create spec for requesting SignedTypedData signature

Interaction with an application for the first time

The workflow of the first interaction of a user using the uport mobile app with an application like the uportlandia demo is different from the workflow of the login example
Can anyone give me the workflow for the first interaction of a user using the uport mobile app with an application

Array of either `String` or `Object` is difficult to implement in typed languages

The verified claims spec is difficult to implement in typed languages.

The verified claims requested from a user. Array of claim types or Claims Specs for self signed claims eg: ["name", {type: "email", essential: true, iss: [{did: 'did:web:uport.claims'}]}]

Having an array of either String or Object is fine in JS but is a nightmare to serialize/deserialize in typed languages.
Not only that, but the logic needed to parse the request gets more complicated and is not necessarily backwards compatible.

Since this is not widespread it may be worth using a different field for the verified claim query in the request instead of complicating the logic of existing fields and breaking current implementations.

Spec simple https based DID method

It should be pretty easy to map the DID spec to this.

This only contains the specifications -- are there any reference implementations of this?

This only contains the specifications -- are there any reference implementations of this?

Also, would like to know how uPort achieves Decentralized Identities (DIDs) ?

Nathan Aw

Create ENS DID method ERC

Create a new ERC for ENS DIDs.

DID method: ens

Eg. did:ens:gnosis

Resolve the ethereum address for gnosis.eth
Treat it as an ethr did for that address

Uport for Quorum blokchain

I'm developing a donation platform based on the blockchain. I need to identify the beneficiary that can be an institution, an association, a hospital, a retirement home, a person, etc.
I study the possibility to integrate the Uport in my platform to identify the beneficiary.
So I have some questions :

1/ My platform is based on the Quorum private blockchain. So, I wonder if I can integrate Uport as an identity management solution in the Quorum network and how?

2/ In Uport, the mobile app holds the user’s keys. When a beneficiary is a person it may be logic. But When it is an organization, I cannot imagine how an organization holds its identity with a mobile. Is there any exception for an organization that replaces the use of mobile?

Missing diagram for Push Notification transport

@pelle Section on Push Notification Transport has the same diagram as Desktop Browser Server Backed Transport.

Add specs for initiating a request on chasqui

Clarify IPFS storage

According to the specs, when somebody whishes to resolve my uport DID, he checks the ETHR where he finds an IPFS CID, and then he is able to retreive the DID DOC that contains my public key.

However, I see everywhere in the documentation how IPFS is treated like a magic server where data is stored for free, when in fact, in order to retrieve something from IPFS, somebody has to be hosting that document.

My question is, WHO is hosting the document containing my public key?

Clarify relation between target system and DID for https method

In the current specification of the https/web method, the target system is described as the host of the domain. This means that there is a different target system for each domain.

This makes sense because the spec of DIDs does not specify anything specific about the target system. The discussion about centralized DNS is taken out of the spec of the DID method.

However, for the target system w3c-ccg.github.io

• the method name should be something like https-w3c-ccg.github.io
• a DID on this target system should be something like
  • did:https-w3c-ccg.github.io:0xb9c5714089478a327f09197987f16f9e5d936e8a or even
  • did:https-w3c-ccg.github.io:eth:0xb9c5714089478a327f09197987f16f9e5d936e8a

The current spec for the https method needs to be updated to clarify the relation between target system and the DID. In the current spec, there is only one single DID for each target system.

Can I integrate Uport to quorum based Dapp

I'm developing a dapp based on the Quorum blockchain.
I wonder if I can integrate Uport as an identity management solution in my private blockchain and how it can be processed

Where are the verified claims stored

I'm confused about where are the verified claims stored in the uPort solution.
According to some documents that I have read, they can be integrated into the DID Document.
Is it the case for the uPort solution? If not where is the location of these claims?