The Elastos scheme is the way for dApps to request operations to be completed by another Elastos application, on behalf of the user. For example, if your dApp wishes to request a payment from a user, it will call the payment scheme, which will open the installed wallet app, which will proceed to the payment (because it’s the only one to know private user information), and send the payment confirmation to your app.
Schemes and parameters are the sames for all programming environments (elastOS, native apps …). Nevertheless, the way to call them and get response changes.
Apps can request operations from other Elastos applications either through a special scheme, “elastos://", or “https://scheme.elastos.org”. Those Elastos scheme URLs can be clicked, or scanned using a QR code scanner application.
elastos://<command></RequiredParameters...>
or
https://scheme.elastos.org/<command></RequiredParameters...
The Elastos scheme usually uses signed or unsigned JWT tokens to transport requests and responses data.
Unsigned requests are used in places where we cannot secure a private key to sign the JWT payload (ex: client side web page or native mobile app). In this case, JWT tokens are generated using no signature (**{alg: none} **in header) and an empty signature part.
Signed requests are generated server side to prevent man in the middle attacks. They use the application DID keypair to sign JWTs.
Responses can be signed. They use one of user’s DID key pairs contained in the identity management application.
Although raw request parameters are supported, they are not recommended. Usage of JWT encoded requests is the preferred way.
Example of a raw request:
https://scheme.elastos.org/pay?amount=12.4
Raw requests can be used only for commands with flat parameters list (ex: pay), but they won’t work for commands that require sub-object in parameters (ex: credaccess claims object).
Command | Link | Description |
---|---|---|
Access credentials | The credaccess command | Request access to user credentials |
Issue a credential | The credissue command | Issue a new credential to a third party after signing it with user’s DID |
Import credentials | The credimport command | Let a user attach a previously issued credential to his DID |
Access wallet info | The walletaccess command | Access wallet information such as ELA address, ELA amount |
Pay | The pay command | Send secure ELA payments, with blockchain confirmations |
Ethereum transaction | The esctransaction command | Publish an ethereum transaction on the ethereum side chain |
DID transaction | The didtransaction command | Publish a DID transaction on the DID sidechain |
DPoS vote transaction | The dposvotetransaction command | Publish a DPoS vote transaction on the ELA mainchain |
Register as CR member | The crmemberregister command | Registers a new CR member candidate on the ELA mainchain |
Vote for CR members | The crmembervote command | Vote for CR members |
Sign data | The sign command | Sign any kind of data on behalf of a user in order to prove that this data belongs to him |
On the device any URL whose hostname is scheme.elastos.org or scheme is elastos:// open one of the supported Elastos apps such as the ELA wallet or the elastOS browser. If no such app is installed, scheme.elastos.org urls display a page that tells users how to get one of those apps.
iOS developers can use open() with the URL directly.
Android developers can use the ACTION_VIEW intent to open the URL as well.
By encoding the request url in a QR code it is very easy for users with an Elastos app installed to scan a request. On iOS 11, the system camera can scan QR codes automatically.
The following use cases must be handled by a wallet app implementing the Elastos scheme:
A native mobile application generates a request. The request is broadcast within the mobile operating system (android, ios) using native methods (intents, open url) and directly handled by the elatos wallet application if installed. Response is returned by the same mechanism, either using intents or open url, by providing specific scheme or hostname in the response’ callback url. There is no server interaction in this case.
A desktop browser displays a QR code that represents the request. That QR code was generated by the website back-end and the request JWT is signed. The wallet app scans the QR code and handles the request. Response is sent through a HTTP POST call to the back-end server, which informs its website front-end of the result.
A mobile browser requires its back-end to generate a signed request. This request is directly opened on the device, which opens the wallet application. Response is sent to the website back-end which handles the response and informs its front-end of the result.
The following formats are usable:
http://scheme.elastos.org/[command]/[JWT]
http://scheme.elastos.org/[command]?[query as get parameters]
elastos://[command]/[JWT]
elastos://[command]?[query as get parameters]
The benefit of using https://scheme.elastos.org URLs is that they can open a web site with an App Store link if the wallet app is not installed. On a desktop browser, the browser can display a QR code containing the request and will ask the user to scan the code with their mobile app. This should therefore be the preferred way for websites.
On the other hand, native apps may prefer calling the elastos:// scheme for a smoother (direct) user experience.
The following parameters are common to all requests. All scheme requests must provide the parameters if they are mandatory. Some of those parameters are used as information to the end user, while some others are used to secure the communication and verify that requests and responses are genuine.
Parameter | Description | Mandatory | Format |
iss | The DID of the requester (mobile app’s application DID, website’s DID) - Entity who is sending (and possibly signing) this request. | no | DID String |
iat | Time at which the JWT was created | no | Unix timestamp (seconds) |
exp | Expiration time of the JWT. After this time, responses to this request should return an error. | yes | Unix timestamp (seconds) |
callbackurl | Callback URL for returning the response to the requester. Callback is called using HTTP POST and data is passed as a JSON object {“jwt”:[JWT]}
Custom parameters in the url are preserved and passed back to the receiving server or destination. Callback receiver must return an HTTP code 200 to notify the wallet app that the response was handled correctly. |
No (1) | URL encoded string |
redirecturl | The redirect URL is called using mobile OS open url API or intent. This allows the calling app to directly handle this call.
Custom parameters in the url are preserved and passed back to the receiving mobile application. The JWT response is appended to the given url as a fragment (yourcallback?params#[JWT]) |
No (1) |
Responses are created by the app that received a request, as a response to that request. either through the callbackurl method, or redirecturl method.
The JWT token contains the response payload, and a signature that can be used to verify the provided payload.
Parameter | Description | Mandatory | Format |
type | Depends on the request type. Check this in the specific request. | no | String |
iss | DID of the entity signing the JWT. Usually, user's DID | no | DID String |
aud | DID of the requester. Usually, the application DID. | yes | DID String |
iat | Time at which the JWT was created | yes | Unix timestamp (seconds) |
exp | Expiration time of the JWT. After this time, response should be handled in error by the receiver. | yes | Unix timestamp (seconds) |
req | The original JWT received from the request | yes if the received request was signed | JWT |
This is not implemented by any app yet.
The wallet application implementing those scheme commands verifies the validity of incoming request JWTs as following:
In case responses use the callbackurl method, the receiving server back-end or client mobile application has to verify the validity of incoming response JWTs as following:
Used to request user related information first name, email address, phone number, diploma, certifications, accomplishments, or anything else related to the user.
Typically used to sign up/in users, or to prove facts (ex: user belongs to a university).
Those credentials have been attached as verified credentials on user’s DID before, by third party issuers.
/credaccess/
Parameter | Description | Mandatory | Format |
claims | List of claims the application requests from the user. See Claims format. | yes | Claims format |
customization | UI customization values | no | UI customization object |
sub | DID of the targeted user identity, in case user’s DID is already known and we want to get additional credentials. That will auto-select the right identity in the DID application. | no | DID string |
UI Customization Object format:
Parameter | Description | Mandatory | Format |
primarycolorlightmode | Color for icons, UI controls and heading texts when the light mode theme is enabled. | yes | Hex color string (ex: "#92e28b") |
primarycolordarkmode | Color for icons, UI controls and heading texts when the dark mode theme is enabled. | yes | Hex color string (ex: "#92e28b") |
"claims": {
// default parameters: required: true, no reason, no specific iss requirement
"CLAIM_NAME": true,
// or
"CLAIM_NAME": {
// If a required field cannot be provided, the request will fail
"required": true | false,
// Optional
"reason": "Reason displayed to user",
// Requirements about the credential issue (ex: if we want to target a specific organization)
"iss": {
// Set selfproclaimed to true if you would like to only accept credentials that have been verified
// via specific issuer DIDs
"selfproclaimed": "false",
// Credential must have been issued by any of these specific DIDs. Note that "selfproclaimed"
// must be set to true in order to use this parameter
"did":["issuer_did1", "issuer_did2"]
}
}
}
https://scheme.elastos.org/credaccess/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"claims": {
"email": true,
"diploma": {
"required": false,
"reason": "If provided, will be shown to end user",
// or
"reason": [{
"lang": "en|fr|zh|etc",
"value": "Language specific reason",
}],
"iss": {
"selfproclaimed": true,
"did":["did:elastos:my_university_did"]
}
}
}
}
Parameter | Description | Mandatory | Format |
presentation | The verifiable presentation | yes | W3C’s verifiable presentation |
JWT Payload:
{
"type": "credaccess",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"presentation": [PRESENTATION_CONTENT]
}
Presentation content:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Université",
"lang": "fr"
}]
}
},
// Optional. Only for credentials that can be verified (not self issued)
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}],
"proof": {
"type": "ECDSAsecp256r1",
"verificationMethod": "did:example:icJ4z2DULrHEzYSvjKNJpKyhqFDxvYV7pN#keys-1",
"nonce": "6c573d7abe8720b5a659671335788a6f",
"realm": "example.com",
"signature": "eyJhbGci...AnKb78="
}
}
The elastos scheme is agnostic to different claim types. This allows you to plug in your own taxonomy of claims or use an existing taxonomy that works in your industry.
Whenever possible, for apps communication compatibility, we recommend to use the list of standard claim names that has been defined in the Elastos Verifiable Claims Specification.
Used to generate a Verifiable Credential given a set of properties and other information. The generated credential if signed by current user’s identity and targets a subject identity.
/credissue/
Parameter | Description | Mandatory | Format |
identifier | The credential key (credential "id" in W3C terms) | yes | String |
types | Array of custom credential types. At least one type must be provided. | yes | String |
subjectdid | DID of the entity that should receive the issued credential. | yes | DID String |
properties | Custom JSON object with all the properties to attach as credentialSubject to the credential. | yes | JSON object |
expirationdate | Date at which the issued credential will be no longer valid. | no | ISO 8601 date string |
https://scheme.elastos.org/credissue/[JWT]
JWT Payload:
{
"identifier": "customcredentialkey",
"types": ["MyCredentialType"],
"subjectdid": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"properties": {
"customData": "Here is a test data that will appear in someone else's DID document after he imports it.",
"moreComplexData": {
"info": "A sub-info"
}
},
"expirationdate": "2025-05-25T08:08:04.000Z"
}
Parameter | Description | Mandatory | Format |
credential | The verifiable credential | yes | W3C’s verifiable credential |
JWT Payload:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC#customcredentialkey",
"type": ["MyCredentialType"],
"issuer": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"issuanceDate": "2020-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"customData": "Here is a test data that will appear in someone else's DID document after he imports it.",
"moreComplexData": {
"info": "A sub-info"
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2020-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}
Requests the user to accept or reject one or more credentials issued by an issuer (ex: a university issues a diploma for this user) before attaching this credential to user’s DID. The issuer’s credential is first attached to the local DID on user’s device, and the user can choose to make it public or not (DID sidechain) later.
Credentials can be generated using a DID SDK, such as the Elastos native or Java SDKs, or the elastOS DID plugin.
In order to issue a credential, the issuer needs to have a DID himself first, because this DID is used to sign the credential. Later on, this signing DID can also be checked on the DID sidechain by a service, to make sure if the credential issuer is valid and trusted or not.
/credimport/
Parameter | Description | Mandatory | Format |
credentials | Array of verifiable credentials as per the W3C specification | yes | W3C’s verifiable credential |
{
"credentials": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2018-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.com/jdoe/keys/1",
"jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19
..DJBMvvFAIC00nSGB6Tn0XKbbF9XrsaJZREWvR2aONYTQQxnyXirtXnlewJMB
Bn2h9hfcGZrvnC1b6PgWmukzFJ1IiH1dWgnDIS81BH-IxXnPkbuYDeySorc4
QU9MJxdVkY5EL4HYbcIfwKj6X4LBQ2_ZHZIu1jdqLcRZqHcsDF5KKylKc1TH
n5VRWy5WhYg_gBnyWny8E6Qkrze53MR7OuAmmNJ1m1nN8SxDrG6a08L78J0-
Fbas5OjAQz3c17GY8mVuDPOBIOVjMEghBlgl3nOi1ysxbRGhHLEK4s0KKbeR
ogZdgt1DkQxDFxxn41QWDw_mmMCjs9qxg0zcZzqEJw"
}
}]
}
Parameter | Description | Mandatory | Format |
importedcredentials | List of IDs of credentials that were imported | yes | Array of strings |
Used to get user ELA address, ELA wallet amount, or other wallet related information.
/walletaccess/
The following parameters could or should be part of the JWT structure:
Parameter | Description | Mandatory | Format |
reqfields | List of fields requested to the user. | yes | Requested field format |
{
"reqfields": [{
// default parameters: required: true, no reason
"FIELD_NAME": true,
// or
"FIELD_NAME": {
// Optional
"reason": "Reason displayed to user",
// or
"reason": [{
"lang":"en|fr|zh|etc",
"value":"Language specific reason",
}]
}
}]
}
Field | Description | Format |
elaaddress | ELA wallet address | Wallet address string |
https://scheme.elastos.org/walletaccess/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"reqfields": [{
"elaaddress": true,
// or
"elaaddress": {
"reason": "If provided, will be shown to end user",
// or
"reason": [{
"lang":"en|fr|zh|etc",
"value":"Language specific reason",
}]
}
}]
}
Parameter | Description | Mandatory | Format |
walletinfo | List of information for requested fields | yes |
JWT Payload:
{
"type": "walletaccess",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"walletinfo": [ {
"elaaddress": "abcdef"
}]
}
Used to send payments, usually from a user to another user, or from a user to a “shop” to purchase a good. This does not include specific transaction like paying fees to create a DID, run a smart contract, or vote for DPoS. This pay command should remain related to what end users are used to do with google pay or apple pay.
Several kind of payments are available:
In case of ERC20 tokens, token smart contract addresses are hardcoded by the implementing application, not passed as command parameter.
/pay/
Parameter | Description | Mandatory | Format |
amount | Amount to be transferred | yes | Number (0.00) |
receiver | ELA address receiving the payment | yes | ELA address |
currency | Crypto currency name or ERC20 token name. If nothing is provided, ELA is assumed. | no | "ELA","ELA/ETHSC","ELA/ETHSC:TOK", etc |
Parameter | Description | Mandatory | Format |
txid | Chain-specific ID generated by the created transaction | yes | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/pay/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"amount": 20.50,
"receiver": "EfPaLGVqoBTCRtioLN5CFbExBVu7NsgFpX"
}
JWT Payload:
{
"type": "pay",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"txid": "cLx02f6a26FxLKE4eYJiEz8n9e02e05zC"
}
Transaction to execute an ethereum sidechain smart contract.
/esctransaction/
Parameter | Description | Mandatory | Format |
receiver | Smart contract account address | yes | ETH account address |
amount | Amount of ELAESC to be passed to the smart contract | no | Number (0.00) |
payload | Smart contract payload. Ex: the result of “web3.eth.contract(abi).at(address).myMethod.getData(myParam);"
|
yes | ETH transaction data payload |
Parameter | Description | Mandatory | Format |
txid | Chain-specific ID generated by the created transaction | yes | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/esctransaction/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"amount": 20.50,
"receiver": "EfPaLGVqoBTCRtioLN5CFbExBVu7NsgFpX",
"payload": [......]
}
JWT Payload:
{
"type": "esctransaction",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"txid": "cLx02f6a26FxLKE4eYJiEz8n9e02e05zC"
}
Used to record a given DID request (ex: including updated DID document given by the DID app) to the DID sidechain.
/didtransaction/
Parameter | Description | Mandatory | Format |
didrequest | DID request (JSON), as provided by the DID SDK | yes | DID Request |
Parameter | Description | Mandatory | Format |
txid | DID sidechain-specific ID generated by the created transaction | yes | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/didtransaction/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"didrequest": {
"header": {
"specification": "elastos/did/1.0",
"operation": "create"
},
"payload": "eyJpZCI6ImRpZDplbGFzdG9zOmlZY3A3SkRCenhTZnFlcVV0VlQ1TG5yZ1dvNDhpUVV0Q2oiLCJwdWJsaWNLZXkiOlt7ImlkIjoiI3ByaW1hcnkiLCJwdWJsaWNLZXlCYXNlNTgiOiJ6bkduc042N3BFUXBwQ3FIS2t4TDJuNzV4MnlqSmNtcllrbW1MdnNoNGZSQSJ9XSwiYXV0aGVudGljYXRpb24iOlsiI3ByaW1hcnkiXSwiZXhwaXJlcyI6IjIwMjQtMTEtMTJUMTM6MDA6MDBaIn0",
"proof":{
"verificationMethod": "#primary",
"signature": "h3PQyLMVR+vWXF6jPGmHSXDD/3QwjtBy17aqZ9DErL+2xNUE9s1NdSQ5jpBUAqXrG/8nGkBDVDYTHixV2uvBSw=="
}
}
}
JWT Payload:
{
"type": "didtransaction",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"txid": "cLx02f6a26FxLKE4eYJiEz8n9e02e05zC"
}
Used to record a user vote to the mainchain.
/dposvotetransaction/
Parameter | Description | Mandatory | Format |
publickeys | List of public keys of supernodes for which we want to vote. Between 1 and 36 keys are allowed. | yes |
Parameter | Description | Mandatory | Format |
txid | The created mainchain transaction ID. | yes | Array of public key dids | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/dposvotetransaction/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"publickeys": ["abcd","defg","hijk"]
}
JWT Payload:
{
"type": "dpostransaction",
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"aud": "did:ela:e02e05a2e7dc29a5f2a5882c509a56CeYJ",
"iat": 1566352213,
"exp": 1566382213,
"req": "440645e21aabd6820110f3dc2449e02e05a2e7dc29a5f2a5882c509a566fd7f2aa4d0bd2bca040a2f3a7dc8b8dc2ec14a98688b28602f6a2efb3f0513ef04ac4",
"txid": "cLx02f6a26FxLKE4eYJiEz8n9e02e05zC"
}
Registers a CR council member candidate so that other persons can vote for her/him.
/crmemberregister/
Parameter | Description | Mandatory | Format |
did | DID of the user that has to be registered as a proposed candidate for the CR voting process | yes | DID string |
nickname | Name of the candidate | yes | String |
url | Marketing website url for the candidate | no | URL |
location | Location of the CR member candidate. | yes | International calling code number without the + prefix |
Parameter | Description | Mandatory | Format |
txid | Generated transaction ID on the Elastos mainchain | yes | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/crmemberregister/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"did": "did:ela:ia9akyCKcvwDNGAGxPrMTNVSKZV4f3tcKj",
"url": "http://my.website.com",
"nickname": "The candidate",
"location": "86"
}
Allows a user to vote for one or more CR council members
/crmembervote/
Parameter | Description | Mandatory | Format |
votes | List of candidate did / number of SELA | yes | Object that contains a list of key/value vote pairs |
Parameter | Description | Mandatory | Format |
txid | Generated transaction ID on the Elastos mainchain | yes | status | Transaction status | yes | "cancelled", "published", “error” |
https://scheme.elastos.org/crmembervote/[JWT]
JWT Payload:
{
"iss": "did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC",
"iat": 1566352213,
"exp": 1566382213,
"redirecturl": "myapp://elastosschemeresponse",
"votes": {
"did:ela:ia9akyCKcvwDNGAGxPrMTNVSKZV4f3tcKj":"1000000",
"did:ela:iUQtoHoQx8zgxRcLx6FxLKE4eYJiEz8nzC":"2500000"
}
}
Used to sign a document with user’s DID. Later on, anyone can check the signed result to make sure of the original data ownership.
/didsign/
Parameter | Description | Mandatory | Format |
data | Binary data to sign | yes | String |
signatureFieldName | Name of the field that holds the signature output, in the response. Useful for example to customize a generated JWT with a custom signature field name. | no | String |
jwtExtra | Object that holds fields that are directly added to the resulting response / JWT. Useful for example to send server side challenges back, or other custom application data. | no | JSON Object |
Parameter | Description | Mandatory | Format |
signingdid | DID Url of the signer | yes | DID URL |
publickey | Public key of the signer | yes | DID public key |
signature | Generated signature using the original data and the selected DID’s keypair | yes | String |
Besides standard command listed above, the same scheme can be extended to exchange custom requests and responses among elastos apps.
Examples:
In such cases, it’s up to the application to decide:
Custom command example:
Developers willing to use the Elastos scheme may need to create an identity for each application (website, native app, elastOS capsule…) on the DID sidechain first if they want to sign their requests JWTs. After registration, they may get the following information at least: