Table of Contents

About

The Workday DID method specification conforms to the requirements specified in version 0.13 of the DID Specification, published on May 27th of 2019 by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, please see the DID Spec and the DID Primer.

Abstract

Workday offers a decentralized Credentialing Platform with a Blockchain based trust layer. A key component of the platform is the WayTo by Workday mobile app which allows the user to store verifiable identity documents, encrypted using their own personal encryption key, which is managed in the Trusted Execution Environment (TEE) of their mobile device. The mobile app can hold official documents, training certifications, verified accomplishments and other credentials. The user can choose what to share, and with whom to share it with. Users of the Workday Credentialing Platform will have a DID and a corresponding DID Document on a permissioned ledger, which credential verifiers can use to validate users’ cryptographic signatures, included in their credentials.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document was published by Workday Credentials as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as anything other than a work in progress.

This document is governed by the 1 March 2019 W3C Process Document.

The Workday DID Method

The Workday DID Method name is work

The Workday DID takes the following format:

did:work:<first 16-bytes of public key w/ b58 encoding>

Example:

did:work:123456789abcdefghi

CRUD Operation Definitions

Create

DIDs and DID Documents are created and signed where the private keys live. The mobile app creates DIDs and DID Documents for end-users during platform on-boarding. At this time a Data Encryption Key (DEK) is created, and encrypted by an asymmetric key stored in the mobile device’s Trusted Execution Environment (TEE). Any user invited to the Workday Credentialing Platform can establish DIDs and DID Documents.

The DID Documents are cryptographically signed and sent to the Workday Credentialing Platform, where their signatures are checked and subsequently stored on the blockchain ledger. The ledger contains smart contracts that verify that the DID Documents are well-formed, that there are no ID conflicts, and checks the cryptographic signature against the rest of the DID Document, before writing it to the ledger.

Read

A GET request to the https://credentials.id.workday.com/v1/did/{did} endpoint with a DID returns the DID Document corresponding to this DID. Behind the scenes, the Workday Credentialing Platform queries the ledger and returns the DID Document, if it exists.

Update

In the current implementation, DID Documents are immutable, and cannot be updated. Future enhancements will enable support for key rotations, revocations, and service changes.

Deactivate

In the current implementation, DID Documents are immutable, and cannot be deactivated. Future enhancements will enable key removal, i.e. revocation.

Workday DID Document

A valid Workday DID will resolve to a DID Document with the contents shown in the example below:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:work:9aBf2zrfPnoclHeoWiXvcw",
 
  "publicKey": [{
    "id": "did:work:9aBf2zrfPnoclHeoWiXvcw",
    "type": "Ed25519VerificationKey2018",
    "owner": "did:work:6sYe1y3zXhmyrBkgHgAgaq",
    "publicKeyBase58" : "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
 
  "authentication": [
    "did:example:abc123#key"
  ],
 “proof”: [
    {“creator”: “did:work:abc123#key”, …}
],
  "service": [{
    "type": "Schema",
    "serviceEndpoint": "did:work:6sYe1y3zXhmyrBkgHgAgaq;schema=17de181feb67447da4e78259d92d0240;version=1.0"
  }]
}

Security Considerations

The Workday Credentialing Platform uses a permissioned distributed ledger, which, by design, handles the following security risks:

Before writing the DID Document to the ledger, its signature is verified, and the ledger’s smart contract will guarantee that there are no ID conflicts.

The ledger is permissioned, with read and write access restricted to the members of the network. Furthermore, communications between the mobile device and the platform happen in an encrypted manner over HTTPS.

DID Documents can be resolved by sending an HTTP GET request to a non-authenticated endpoint. Technically such an exposed endpoint could be victim of Distributed Denial-of-Service (DDOS) attacks, however, the Credentialing Platform leverages cloud provider based DDOS remediation tools and defenses to prevent such attacks.

After on-boarding in the mobile app, users can set up a passphrase based recovery key which can be used to recover the user’s key and access to their data in case of a lost device, for instance. The passphrase is derived using Password-Based Key Derivation Function 2 (PBKDF2), which is a key derivation function with a sliding computational cost, used to reduce vulnerabilities to brute force attacks. It is crucial that the user keeps this passphrase confidential, as anyone with access to this passphrase and the user’s email inbox, can recover on behalf of the user.

The Credentialing Platform leverages AWS Key Management Service (KMS) to perform client encryption of all Private Key material used in association with the ledger. AES256 with GCM mode is used to encrypt all sensitive values. AWS KMS is protected by IAM Rules and AWS Account management. AWS KMS Customer Master Keys (CMK) can be rotated if this system is inadvertently misconfigured.

Privacy Considerations

The Workday Credentialing Platform and its accompanying mobile app work together in a process designed to create and manage DIDs and DID Documents in a way to maintain a user’s privacy and reduce correlation risk.