The FedID DID Document
FedID is based on Distributed Identifiers (DIDs). The use of DIDs bring many benefits, including providing individuals control over their online identity while giving organizations new way to interact with them. DIDs are also more secure than traditional usernames and passwords. They use public-key cryptography, which is more secure, and when used properly, any changes to the DID document will be immediately evident.
Most importantly for FedID, DIDs can be used to sign things, including within standards such as IEEE SA-P7012. FedID uses signatures for a multitude or purposes, including but not limited to:
- Adding a device to control a FedID, such as a mobile phone or tablet.
- Allowing services to interact with the FedID for login or data access.
- Delegating privileges from the FedID, such as agreement signing with JLINC.
The FedID DID Document is based on the JLINC format for decentralized identifiers. The below JSON document provides context of how data is stored in the FedID DID.
Key | Description |
---|---|
[R] | Required by the DID 1.0 spec |
[O] | Optional in the DID 1.0 spec |
[J] | Included in the JLINC DID spec |
{
"id": "did:jlinc:fedid.domain.ext:b938...", // [R] A person
"version": "2.42", // [O] DID version. 2.0 means JLINC v2 DID, first
// iteration. On any update to the DID, it
// increments to 2.1, 2.2, 2.3, etc. So this is
// the 42nd revision to this JLINC v2 DID.
"@context": [ // [O] Context URLs
"https://www.w3.org/ns/did/v1",
"https://didspec.jlinc.io/v2/ctx.jsonld"
],
"verificationMethod": [ // [O] Represent devices (FedID Apps) this DID is
// logged into and can sign from
{
"id": "did:jlinc:device:1bv...", // [R] Device ID
"type": "device", // [R] A device
"controller": "did:jlinc:fedid.domain.ext:b938...", // [R] The person that controls this entry
"key": "jsd...", // [J] Control key for this device (base64)
}
],
"service": [ // [O] Services this DID is connected to
{
"id": "did:jlinc:fedid.domain.ext:zHZ...", // [R] This is the DID's "home" instance
"type": "login", // [R] Identifies this service as the OIDC
// login provider
"serviceEndpoint": "https://fedid.domain.ext", // [R] URL to FIDC provider
},
],
"created": "2023-08-08T17:59:22.907Z", // [O] Created date
"updated": "2023-08-08T17:59:22.907Z", // [O] Updated date
"deactivated": false, // [O] If the DID is still active
"shortName": "MyUser@domain.ext", // [J] The DID's uesrname
"recoveryHash": "jsd...", // [J] Recovery hash
"capabilityDelegation": [ // [O] Services that can take actions/sign on behalf
// of the user. These provisions are only
// required for services that support and use
// the JLINC protocol
{
"id": "did:jlinc:fedid.domain2.ext:zHZ...", // [R] A service the user is using JLINC with
"type": "service", // [R] A JLINC Enabled Service
"controller": "did:jlinc:fedid.domain.ext:b938...", // [R] The person who controls this entry
"key": "B6a...", // [J] The service signing key (base64)
"archiveServers": [ "https://archive.jlinc.io" ], // [J] Where the service sends JLINC audits for
// this user
}
],
"signature": "Zml...=" // [J] Validating the chain of the DID on
// updates (base64)
}
Verification methods
Verification methods are the standard way for DIDs to house information used to sign challenges and other information to validate the user's identity when taking actions with services.
In FedID, they represent devices or apps where the user currently houses a secure, private key for these activities. These apps are used to sign challenges and other information to validate their identity when taking actions with services. Multiple devices are supported per FedID.
Services
Services are URLs that represent the endpoint of a service that a DID is utilizing. In FedID, services are used to define the "home" of this particular DID. Since a FedID can be migrated between providers, the username
is not always a valid source of truth. This is one of the main advantages of the FedID system. When a user migrates their DID, the login
service is updated to wherever the most recent version of their online identity exists.
Capability delegations
Lastly, capability delegations in Decentralized Identifiers (DIDs) refer to the ability to grant specific permissions or privileges to other entities or services on behalf of the DID owner.
These delegations are utilized by the JLINC protocol, and thus supported by FedID. For sites and services that offer up this capability, it can be used to track ownership of the user's data, enabling support for features such as ensuring content ownership, or even providing auditing capabilities for referencing or content use in AI training.
Features such as these enable a FedID to go beyond simply credentialing and sign-up on a site, and allow for connection between entities and digital relationships between those entities to occur.