1 of 13

Use Case Flow for Sharing Electricity Metering Data

Presenter

ELERING-ENERGINET/WORKSHOP / 15.03.2018

Slides: [bit.ly link]

2 of 13

Sovrin Basic Elements

Trust Anchor - provider of the Sovrin Identity

Sovrin clients

Edge Agent (offline, mobile)
Cloud Agent (always-online)

DID - Decentralized ID

Provide pairwise non-correlating identifiers to all relationships

DID Document

Link DIDs to its public key and endpoints

Service endpoint

Reveals a service related to the DID owner, listed on the DID document

3 of 13

Indy/Sovrin Transactions

For Sharing Electricity Meter Data

to a 3rd Party

4 of 13

Actors in this Use Case

Watts, a 3rd party App from Denmark that utilises electricity consumption data as part of its value-adding service (Data using service). It

has public Sovrin DID (as a company) and a cloud agent

Alice gets interested on Watt’s service and installs the app. She is

a Sovrin identity owner (private DID) within her agent
end customer at one of European Electricity Provider’s Datahubs. �

Elering and Energinet, Electricity Provider & Datahubs (Data providers)

have public DID, DID document and data provisioning service endpoints (APIs)

� Sovrin ledger

as the claim validation mechanism and
as global DID discovery ‘lookup table’ for public DIDs

5 of 13

Bootstrapping Alice’s DID with Elering

Alice’s Edge Agent

Sovrin Trust Anchor

Sovrin Ledger

Prerequisite: Elering offers an Edge or Cloud Agent, and as Trust Anchor it provides also traditional IdP and IAL through Estonian ID anchor

2-4, 6-7 DID registration process *

… 5. Anchored Verinym written to the ledger by TA - associating the Legal � Identity of Alice to her DID

0. Enrolment & identity proofing between the Steward and Identity Owner

(may be validation in the physical real-world)

“IAL of Identity Owner = 3”

Alice

1. Authenticate (traditionally) to TA

*See slide notes

Anchoring a non-reputation DID with a traditional trust framework and identity assurance with required physical/biometric/other proof��1.. The identity owner first uses the Sovrin client (possibly in conjunction with another client, such as a browser or smartphone) to connect to and independently prove his/her identity to the website or web service of the trust anchor.

*

2. The trust anchor returns a challenge token to the Sovrin client.

3. The Sovrin client generates a new cryptographic keypair and adds it to the identity owner’s Sovrin keychain. The public (verification) key is used to create the identity owner’s Sovrin identifier (see the Sovrin Identifiers section). The private (signing) key is used to sign the challenge token.

4. The Sovrin client returns the signed challenge token to the trust anchor.

5. The trust anchor verifies the signature on the challenge token, thereby authenticating the new key pair, and then proceeds to register the new Sovrin identifier on the Sovrin ledger.

6. The trust anchor signs a receipt message for the registration with the trust anchor’s own private key and returns it to the Sovrin client.

7. The Sovrin client verifies the trust anchor’s signature by checking the Sovrin ledger to verify the trust anchor’s Sovrin identity

6 of 13

Bootstrapping Watt’s DID at Energinet

Watt’s Cloud Agent

Sovrin Trust Anchor

Sovrin Ledger

2-4, 6-7 DID registration process

… 5. Anchored Verinym written to the ledger by TA - associating the Legal � Identity of SEAS-NVE and its Watts service to its public DID

0. App/Service Provider enrolment - done through onboarding service, �results in a bootstrapped enterprise wallet

“VAT proof”

SEAS-NVE (company behind Watts)

1. Authenticate the company (through a delegated onboarding service user) to TA

Meanwhile something must have happened in Denmark:

7 of 13

Creating a Connection between A and W

Watt’s Cloud Agent

Sovrin Ledger

�Alice’s Edge

Agent

�DID of Alice

3. Send newly created DID for purpose of intended connection with Alice

2. TA writes and signs � Pseudonym DID to ledger

(Public agent-to-agent communication protocol is WIP)

Trust Anchor

Pre-generated DID request to be written to ledger

8 of 13

Service issues a Credential with AccessDelegation+CustomerID* to Alice

Alice’s Edge Agent

Sovrin Validator Node

Issuer �with authority

Issuer’s �Revocation

Accumulator at Ledger

Customership Claim Definition at Ledger

1. Claim offer (optional, could be in slide 5 along with bootstrapping)

2. Claim request

3. Providing the Claim

Prerequisite: existing Sovrin Connection between Alice and Elering

0. Claim definition write

‘Alice is Elering’s customer with attribute

customerID:xxxxxxxxxx’

9 of 13

Authorisation Claim

{

"@context": [

"https://w3id.org/credentials/v1",

"https://example.com/credentials/v1",

"https://w3id.org/security/v1"

],

"type": [

"Credential",

"DelegatedAuthorityCredential",

"CustomerIdentityCredential"

],

"claim": {

"id": "TaVE1pAaummu3wfbWtVbyu",

"claim": {

"authorizedscopes": ["electricity_metering_data",”read_access”],

"customerid": "192873465"

}

},

"issuer": "VJkTdbQZTRnJneZAR245n6",

"issued": "2018-04-04",

"credentialStatus": {

"revocation": "http://example.com/revocation/c73fcffb-5cb0-4bc4-b97c-816048166cbf"

},

"signature": {

"type": "Ed25519Signature2018",

"creator": "VJkTdbQZTRnJneZAR245n6#key1",

"created": "2018-04-04T12:18:44.202Z",

"domain": null,

"nonce": "c73fcffb-5cb0-4bc4-b97c-816048166cbf",

"signatureValue": "SeZ0fqLYteuVBa7WI27dQcJPy0lS0CC3vuyvqsa9AqXDUVfX91hKSwgpwUnn9l7l0EBBcPz6CqDkI1gzmAfMBw=="

}

10 of 13

Piggybagged Authz(user) Proof?

Alice’s Edge Agent

Watt’s

Cloud Agent

Issuer’s �Revocation

Registry at Ledger

(1. Proof offer from claim holder)

2. Proof request - ‘Please give us, Watts, access to your electricity providers’ customer IDs and �[SCOPE, WHY, REQUESTED TIME SPAN] related to as an Authz Credential proof’

3. Provide a proof based on the Delegate Authority issued by Elering

5. Validating non-revocation

of the Proof

Claim Definition at Ledger

4. Claim definition check

Claim ‘piggybagging’ is not defined in any claim exchange mechanisms (Sovrin, W3C) - except Delegated Authority VC idea by Stephen Curran.�

Why? In order to convey Alice’s read access delegation within the ‘Authz Claim’ towards a service endpoint (at Elering, see next slide)

11 of 13

A issues Delegated Authority VC to W

Alice’s Edge Agent

Watt’s

Cloud Agent

Issuer’s �Revocation

Registry at Ledger

1. Proof request - ‘Please give us a, claim that tells we have access to your electricity providers’ s � Data [SCOPE, READ_ACCESS, PURPOSE, REQUESTED TIME SPAN]’

2. Providing DA_VC [SERVICE, SCOPE, CUSTOMER ID,READ_ACCESS, SUBJECT, TIME SPAN] signed with Alice’s DID linked with her Elering connection

Issuer

Claim Definition at Ledger

3. Claim definition check?

Alice’s DID linked to her Elering customership is used as the signing key

12 of 13

Watts’ Data Request to Elering

Elering’s

Cloud Agent

Watt’s

Cloud Agent

Issuer’s �Revocation

Registry at Ledger

1. Request to Elering’s data access service endpoint: ‘Please give us, Watts, access to customer data � [proof built out of Alice’s Delegated Authority VC]’

5. Providing authorized API key / token + customerID of Alice

Issuer

3. Validating non-revocation

of the Authz Claim

Claim Definitions at Ledger

2. Claim definition check

4. Check the customerID linked to the proof’s signing DID

13 of 13

Revoking Delegated Authority VC - WIP

Alice’s Edge Agent

Alice’s Revocation

Accumulator [WHERE?]

1.

2.

3.

4.

0. Updating the status of Rev Accum with a ZKP mechanism

Watt’s

Cloud Agent