owned this note
owned this note
Published
Linked with GitHub
### DID Document
```sh
"serviceEndpoint": [
{
"profile": "https://trustoverip.org/profiles/trp/v2",
"uri": "https://my-tr-service/"
}
]
```
### Profile
```sh
{
"@context": ["https://trustoverip.org/contexts/v2/profile"],
"id": "trp-v2-profile",
"response_schema": "swagger",
"body": {
swagger doc
}
}
```
### TRP
```
https service
```
### Architecture
```mermaid
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.
```mermaid
graph TD
subgraph TrustRegistryType
Profile1[TRP]
Profile2[TEDocument]
end
```
* Namespacing issue
```sh
"serviceEndpoint": [
{
"type": "Trust Registry",
"profile": "https://trustoverip.org/profiles/trp/v2",
"uri": "https://my-tr-service/"
}
]
```
```sh
"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:
```sh
{
"@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:
- https://www.w3.org/ns/did/v1
- https://trustoverip.org/profile/v2
### Example
An example of the expected data format is provided below:
```json
{
"@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.
```mermaid
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.
```js
{
"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.
-
```json
{
"$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
```jsonld
{
"$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
```mermaid
graph LR
subgraph Profile Document
Metadata[Metadata]
Proofs[Proofs]
end
```
Google Drive
Gist
Clipboard
Sign in with Wallet
