Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

APAC Meeting

...

Screenshots/Diagrams (numbered for reference in notes above)

#1

### 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: 
    * It MUST be a struct with the following properties:
        * If adding a Profile definition, service endpoint array 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
```
{
  "metadata": {
  
  },
  ""
}
```

Cosanna : Pan Canadian TR might be able to help. 

## Non-normative chaining and container problem
* Trust on First Use


Decisions

  • Sample Decision Item

...