changed 2 years ago  
Linked with GitHub

DID Document

"serviceEndpoint": [
    {
        "profile": "https://trustoverip.org/profiles/trp/v2",
        "uri": "https://my-tr-service/"
    }
]

Profile

{
  "@context": ["https://trustoverip.org/contexts/v2/profile"],
  "id": "trp-v2-profile",
  "response_schema": "swagger",
  "body": {
    swagger doc
  }
}

TRP

https service

Architecture

graph TD
    DIDDocument --> Profile -->|Describes| ServiceInteraction[Service Interaction]

from our pre-meeting [somewhat related] discussion… this is the recent document that does a good job summarizing Digital Identity Standards from ENISA (not ETSI): https://www.enisa.europa.eu/publications/digital-identity-standards/@@download/fullReport

https://diacc.ca/wp-content/uploads/2023/03/PCTF-Trust-Registries-Component-Overview_Draft-Recomendation-V1.0r.pdf

https://www.aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation-Guidelines-Version-1-2_final.pdf

https://www.aamva.org/identity/mobile-driver-license-digital-trust-service

Differences between Service Endpoint Type Vs. Profile

  • Differences in scope.

    • Profiles are more specific about what implementation of service endpoint is available whereas type field is more of a class of service endpoints.
    ​​​​graph TD
​​​​    subgraph TrustRegistryType
​​​​        Profile1[TRP]
​​​​        Profile2[TEDocument]
​​​​    end
    • Namespacing issue
"serviceEndpoint": [
    {   
        "type": "Trust Registry",
        "profile": "https://trustoverip.org/profiles/trp/v2",
        "uri": "https://my-tr-service/"
    }
]

"serviceEndpoint": [
    {   
        "type": "Trust Registry",
        "profile": "https://eutrustlist.com/protocols/v2",
        "url": "https://"
    }
]

Service Endpoint Struct

  • It MUST be either an array or a single struct:
    • The struct MUST have the following properties:
      • An HTTPS resolvable JSON Profile document. See profile document section for more details.
      • It MUST have a URI, which descibes the endpoint address of the interaction.

An Example is seen below:

{
  "@context":[
      "https://www.w3.org/ns/did/v1",
      "https://trustoverip.org/profile/v2"
  ],
  ...
  "service": [{
    "id":"did:example:123#trust-registry",
    "type": "TrustRegistry", 
    "serviceEndpoint": {
        "profile": "https://trustoverip.org/profiles/trp/v2",
        "uri": "https://my-tr-service/"
    }
  }]
}

Profile Definitions

  • 2 goals

    • Description: string match.

    • Normatively describe interaction

{
  "@context": "<>"
  "metadata": {
      "id": <>, 
      "title": <>,
      "schema": <>,
      "description": <>,
      "tags": <>,
      "creator": <>,
      "version": <>
  },
  "definition": {
  
  }
}
  • Why need json-ld. What's the purpose longer term?
  • uniqueness important.

Cosanna : Pan Canadian TR might be able to help.

Non-normative chaining and container problem

  • Trust on First Use

Data Format Specification

The data structure described in this specification MUST adhere to the following rules:

  1. It MUST be a single struct.
    • It MUST have the following properties:
      • profile: An HTTPS-resolvable JSON Profile document. Refer to the "Profile Document" section for detailed requirements.
      • uri: It MUST include a URI property, which describes the endpoint address of the interaction.

Profile Document

The Profile document referred to above MUST be in JSON format and must be accessible via an HTTPS-resolvable URL. This document SHOULD adhere to the context and schema defined by minimally the following JSON-LD contexts:

Example

An example of the expected data format is provided below:

{
  "@context":[
      "https://www.w3.org/ns/did/v1",
      "https://trustoverip.org/profile/v2"
  ],
  ...
  "service": [{
    "id": "did:example:123#trust-registry",
    "type": "TrustRegistry", 
    "serviceEndpoint": {
        "profile": "https://trustoverip.org/profiles/trp/v2",
        "uri": "https://my-tr-service/"
    }
  }]
}

Profile Specification

The profile specification is a structured JSON document that comprehensively outlines a service endpoint's set of capabilities.

It consists of three primary sections:

  1. Profile Metadata: Used to describe higher level information about the profile.
  2. ~API Descriptors: Used to describe specific details about how to connect to the service.~
  3. Proofs: Used to ensure that the data has not been tampered with.
graph LR
    subgraph Profile
        ProfileMetadata[Profile Metadata]
        APIDescriptors[API Descriptors]
        Proofs[Proofs]
    end
  • Schema <–> Capabilities
  • Feedback: Object separation from apis.

Profile Metadata

The Metadata section provides essential information about the profile document.

{
    "id": <>,
    "type": <>,
    "creationDate": <>,
    "lastUpdatedDate": <>,
    "previous": <>,
    "description": <>,
    "short_description": <>,
    "docs_url": <>,
    "version": <>, 
    "tags": <>,
    "creator": <>
}

API Descriptors

Proofs

The Proofs section specifies the proof mechanisms and the associated details required to verify the profile's authenticity.

At minimum, one proof mechanism and its evaluation specifics MUST be provided to ensure the verifiability of the profile.

{
    "metadata": {
        "id": <>,
        "type": <>,
        "creationDate": <>,
        "lastUpdatedDate": <>,
        "previous": <>,
        "description": <>,
        "short_description": <>,
        "docs_url": <uri-to-docs>,
        "version": <>, 
        "tags": <>,
        "creator": <>
    },
    "definitions" : { // proposal: leave it out entirely for now. 
        "capabilities?services?" : {}
        // describes the interactions with the service. 
    },
    "proof": {
        // proofing stuff here
    }
}
  • Sam Curren:
    • Shoudn't restrict the string match.
    • Problem with DIDComm protocol definitions:
      • No: for two reasons
        • Complicated.
        • Human readable documentation for what the protocol is for.
        • Considering now to walk to the space.
        • Take: Baby steps of understanding.
  • Darrell:
    • What are the services that are useful.
    • Talk to the DID for the TR and make sure things are lining up.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "metadata": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "description": "The decentralized identifier representing the profile in the format of a did".
        },
        "name": {
          "type": "string",
          "description": "the human readable name of the profile"
        },
        "previous": {
          "type": "string",
          "description": "Reference to previous version of the data."
        },
        "description": {
          "type": "string",
          "description": "A detailed description of the data."
        },
        "short_description": {
          "type": "string",
          "description": "A short description of the profile."
        },
        "validity_period": {
            "type": "string",
            "format": "date",
            "description": "combined date-time string representing the date and time the credential becomes valid, which could be a date and time in the future.",
        }
        "docs_url": {
          "type": "string",
          "format": "uri",
          "description": "URL to documentation for the data."
        },
        "version": {
          "type": "string",
          "description": "The version of the data. Suggested to use semver."
        },
        "tags": {
          "type": "array",
          "items": { "type": "string" },
          "description": "Tags associated with the data."
        }
      },
      "required": [
        "id",
        "description",
        "short_description",
        "docs_url",
        "tags"
      ],
      additionalProperties: true
    },
    "definitions": {
      "type": "object",
      "description": "Defines capabilities or services related to the data.
    },
    "proof": {
      "type": "object",
      "description": "Proofing-related information."
      // You can add properties related to proofing here.
    }
  },
  "required": ["metadata", "definitions", "proof"],
  "additionalProperties": false
}

Proof must be done similar to https://www.w3.org/TR/vc-data-model/#proofs-signatures

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "metadata": {
      "type": "object",
      "properties": {
        "@context": {
          "type": "string",
          "format": "uri",
          "description": "The JSON-LD context URI."
        },
        "id": {
          "type": "string",
          "description": "The unique identifier of the profile."
        },
        "name": {
          "type": "string",
          "description": "The human-readable name of the profile."
        },
        "previous": {
          "type": "string",
          "description": "Reference to the previous version of the data."
        },
        "long_description": {
          "type": "string",
          "description": "A detailed description of the profile."
        },
        "short_description": {
          "type": "string",
          "description": "A short description of the profile."
        },
        "validity_period": {
          "type": "string",
          "format": "date-time",
          "description": "Combined date-time string representing the date and time the credential becomes valid, which could be a date and time in the future."
        },
        "docs_url": {
          "type": "string",
          "format": "uri",
          "description": "URL to documentation for the profile."
        },
        "version": {
          "type": "string",
          "description": "The version of the profile. Suggested to use semver."
        },
        "tags": {
          "type": "array",
          "items": { "type": "string" },
          "description": "Tags associated with the profile."
        }
      },
      "required": [
        "@context",
        "id"
      ],
      "additionalProperties": true
    },
    "definitions": {
      "type": "object",
      "description": "Defines capabilities or services related to the profile."
      // You can add additional properties to describe capabilities or services here.
    },
    "proof": {
      "type": "object",
      "description": "Proofing-related information."
      // You can add properties related to proofing here.
    }
  },
  "required": ["metadata", "definitions", "proof"],
  "additionalProperties": false
}

Check out cheqed DLR

graph LR
    subgraph Profile Document
        Metadata[Metadata]
        Proofs[Proofs]
    end
Select a repo