Similar to https://github.com/decentralized-identity/credential-manifest/tree/main/test

have a set of tests that run examples/other documents against the JSON schemas to keep us honest!

https://hackmd.io/a50I9MlkRVOQJOYgf7b3hA

If we have a concept of endorsement, we must have a concept of revoking endorsement. How can I check that endorsement is always up to date without needing to consistently modify the Trust List itself?

The first draft strawman of the Trust List takes the position of schema-based trust lists. We have trusted_entities and then what they are trusted_for.

 "trusted_for": [
          {
            "name": "Person's Name",
            "description": "A person's name",
            "schemas": ["schema.org/name", "example.com/name-schema.json"]
          }
        ],
        "trusted_entities": [
            {
                "identifiers": ["did:test:1234"],
                "name": "Identifiers for Corporation A.",
                "description": "Corporation A is a universally recognized authority on names and date of birth"
            },
            {
                "identifiers": ["did:test:5678"],
                "name": "Identifiers for Corporation B.",
                "description": "Corporation B is a universally recognized authority on human credentials"
            },
        ]

This design works best when there are a set of entities (Issuers) that are all trusted for the same type of credentials, identified by a common set of schemas.

Instead, we can consider a model that trusts on a per-issuer basis. Meaning, for a given issuer, here is what I trust them for...

"trusted_entity": 
         {
                "identifiers": ["did:test:5678"],
                "name": "Identifiers for Corporation B.",
                "description": "Corporation B is a universally recognized authority on human credentials"
         },
 "trusted_for": [
          {
            "name": "Person's Name",
            "description": "A person's name",
            "schemas": ["schema.org/name", "example.com/name-schema.json"]
          },
          {
            "name": "Date of Birth",
            "description": "A person's date of birth",
            "schemas": ["schema.org/dob"]
          }
        ]

Should the specification allow this configurability, or take a stance on a schema or issuer based perspective?

How do we distinguish between the sentiment for issuers (e.g. as a bank, here is who I trust...)
and trusting an issuer for specific, schema-identified credentials?

additionally, how we we represent both positive and negative sentiment?
(e.g. I do not accept issuers who comply with x policy and I do accept issuers who comply with y policy)

Introspection/analysis of what entity is behind a DID, if they are authentic

Handling unified form to do group by topic and group by entity
https://hackmd.io/a50I9MlkRVOQJOYgf7b3hA?both

Can we launch a test suite and prove out interop in DIF, outside of DIF?

There's a gap not covered by the specification(s): how do I know someone is who they claim they are?

Here are some potential strategies:

1. By credentials they are issued, you can get a sense of who they are (e.g. a business license from a government)
2. Tie to an existing trust establishment (e.g. using a ./well-known file to tie control to a website)
3. A reputation system, which may include attestations and/or proof by others

I do not believe this needs to be an independent specification, though it may be worth coming up with a guiding document outlining possible approaches for determining the authenticity of a DID-party.

https://hackmd.io/a50I9MlkRVOQJOYgf7b3hA

A party identified in a Trust Establishment Document could be issued a Credential identifying their inclusion. How would this work?

Schemas for each of the formations.

In order to enable easy validation of the trust-establishment JSON, it would be helpful to add a signature by the author.

Proposal

This issues refers to examples in the examples published on the identity.foundation site

The signature attribute is created by signing the hash of the attributes:

• id
• version
• last_updated
• schemas
• participants
• roles

hashing process

To make the hashing process repeatable the steps are

• the attributes of all the objects are sorted alphabetically
• the JSON is stringified without line breaks and spaces
• the resulting string is used to create a SHA-256 hash

validity

In order to be deemed valid, the signature must be created by the DID in participants.author

https://hackmd.io/a50I9MlkRVOQJOYgf7b3hA

For Mike Ebert

Define what a trust topic is in more detail:

https://github.com/decentralized-identity/trust-establishment/blob/main/spec/spec.md?plain=1#L129

• Should these properties be supported in the data model?
• Should they be mandatory?
• How do they relate to versions?

I could easily see this as a critical joint item between the ToIP and DIF, but the idea here is that we need a complete and standard model to think about trust decisions. We should then align them with the specifications and make sure it's appropriately able to work with the model.

These may seem like vacuous and theoretical questions, but I think they have some real ramifications around how an actual implementation would look, and how technology can support these efforts, so I'm bringing it up here.

https://identity.foundation/trust-establishment/#publication-discovery points to how to discover Trust Establishment documents but I think leaves a lot of open questions about how this would actually work.

I think it would be really helpful to ground this a little more in a real world deployment/network architecture with some use cases. There's a lot of questions I have around how publication discovery would work in practice, and it would be helpful for the specifications to dive into more details. I'm assuming if I'm having issues conceptualizing an implementation, others would benefit from as well.

A non-normative example is fine I think.

cc: @dtmcg

Do we really need all the formations (+ more that we aren't thinking of)? Or could one formation, like set oriented cover all of the use cases?

Pros:

• Ease of implementation from developer point of view
• Don't you have to implement all formations anyways? To be able to understand all/most trust documents that you want to read?

Con:

• Repetition of the statements

Meaning, 1000s of entities endorsing a single Trust List.
How is this discoverable/crawlable?
How are endorsements created/aggregated?

Trust is not normally a binary decision. Trust is better modeled as part of a continuum, in which some presentations are "more" trustworthy than others. My question is the following:

• What support around "levels" of trust should the TE specs provide? Is this within scope for the TE specs?
• If in scope and not sufficient: How would we enable the specifications to support better trust decisions which allow for a trust within a continuum. I think this relates to #43 as you may trust someone more or less based upon context.

Here's a toy example which we can play with:

Bob telling Alice's food preferences may be less trustworthy than John telling Alice's food preferences. But if Bob and Tom both say the same thing about Alice's food preferences, maybe they are more trust worthy in aggregate than John, if they agree. But Alice is probably the most credible source ( but I don't think even Alice would be 100% credible, as people do have personal bias ), so given a choice to trust Alice vs. John and Bob, you'd probably trust Alice.

I would tag this as a discuss label for now.

Remove sentiment, credentials, etc.

What is meant by a “formation”? Clarify wording in section 5.3

When we make a trust based decisions, we often think about it within a context. I.e. I know Bob, and Lucy, therefore I will trust John as an issuer. I think to move forward on this, we need to answer a few questions:

• what is the "context" of a trust decision and why does it matter?
• how would you model it?
• are the current specifications providing enough support to make context based decisions around trust?
• should the specifications support context based decisions around trust?

I would probably label this a discussion for now, to talk about at the next TE meeting.

How to represent JWTs?
Canonicalization issues?
JCS?

At least one example for:

• Topic Entity Oriented
• Entity Oriented
• Entity Topic Oriented
• Set Oriented

At the last call, on June 13, where I was not present, I heard of an interesting discussion around whether endorsements should be included inside of Trust Lists as Verifiable Credentials. Since I was not privy to all the discussion, and I have little context I'll share my initial thoughts, and welcome many more from all of you....

More broadly there seems to be a question of "staleness" meaning -- how long can a Trust List be accepted. Unwinding this thought, a Trust List can be accepted as long as all of its contents are valid. Valid means the document contains, at the point of usage, true statements from the perspective of the author(s) in addition to resolvable when referencing an external document—a Trust List full of schema URIs that are dead links cannot be seen as valid.

The initial draft strawman I've spent some time on does not answer these questions. It also does not include Verifiable Credentials at all. There are a number of downsides here, which I'll phrase as open questions:

1. How are Trust Lists hosted and published?
2. How are Trust Lists updated? We have a version field, but how can I make sure the version I'm looking at is the latest one?
3. How can I undo an endorsement?
4. Where are Trust Lists agreed upon and generated?
5. How do Trust Lists facilitate mass-endorsement? Meaning, 1000s of entities endorsing a single Trust List.

Some of these questions may be outside the scope of this specification, which really serves to define a data model. That said, I don't think the questions are outside the scope of the work item which really should have good answers. Maybe that comes in the form of an implementers guide.

Additionally, I'd like to set out some design principles I think are worth striving towards:

• Resolve as few documents as possible when using a Trust List. The ideal is resolving just the Trust List and gaining all information.
• Strive for longevity of Trust Lists. Acknowledging that updating and un-endorsing can be cumbersome, we must assume that Trust Lists will have some kind of permanence.
• Strive for minimal Trust Lists. Trust Lists should not be megabytes of data. They should be small, and quickly transmitted. All unnecessary information should be removed. This is a driving factor for making Trust Lists schema-based, instead of issuer-based -- though that option can be explored.

E.g. a number of DIDs (did:example:1, did:example:2) but different schemas apply to each (e.g. did:example:1 has schema A, did:example:2 has schema B).

Raised by @TelegramSam