Finalize DID document creation form

[xamcost]

Hi there! The goal of this issue is to decide the content of the form presented to prospective users to enroll in Sedimark, prior to the creation of their corresponding DID document and participant Verifiable Credential. We also need to decide for each field whether they are required or optional, and what restrictions should apply to them.

As of now, here are the features to be requested in the form:

• first name & last name, both required
• company, should be optional
• website, should be optional
• picture, should be optional. There is no intent to put a storage for this, so this field should be an URL pointing towards a picture (Not fully implemented yet).
• checkbox to agree terms and conditions of Sedimark platform.

Current state of the form:

[xamcost]

@psotres @telsaleh Hi guys! I would actually suggest adding in this form a contact email. That doesn't cost us anything, and that would enable prospective consumers to contact providers in case they have questions on the offering. What do you think ?

[psotres]

Sorry @xamcost, I think I missed this issue.

To be honest right now I don't really know where that data would be stored for the consumers to retrieve it. It seems to be related with https://github.com/Sedimark/mvm-participant-onboarding/issues/4. Maybe @mikeus9908 and @alby0x0c can provide some extra input about the enrollment flow.

[psotres]

Hi all,

We have been having some discussions between UC and LINKS about this. Long post here 😆

First, @mikeus9908 is still working on solving https://github.com/Sedimark/mvm-participant-onboarding/issues/3, which is needed to be able to fully define the enrolment flow and continue progressing with the participant onboarding sub-stream.

In parallel, we have been thinking about the information asked from participants and how consumers will actually retrieve it. TLDR: Participant identifiers are going to be their DID identifier URI (e.g. did:iota:lnk:0x2b7ac707e71eda93135e1a457718f2d87f387ff66d62c8084ef06301110086ef#W1lJ9vr23XhK8kV8YTu27njdBBwjtHG0AWoNveHGD18), and that is the only piece of provider-related information that is going to be included within the offering. It seems @telsaleh has defined the conccepts of publisher and creator in an offering. So far, we are 1005 sure DID's URIs will be the ones used for publishers (providers) because they will be the ones interacting in the SEDIMARK marketplace. Not sure about creators because they could not even be SEDIMARK participants.

Now the question becomes: how do consumers discover who is the provider? (as they can only start from the DID id, which is "a long hex string"). Again, from that string a DID document can be resolved (DLT booth exposes a method for that so the frontend does not need to cope with that). Let's take the DID example in Sedimark/dlt-booth#7, which is not the one used in SEDIMARK but it serves the purpose for this topic:

{
  "id": "did:web:did-server:company1",
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "@base": "did:web:did-server:company1"
    }
  ],
  "service": [
    {
      "id": "#identity-hub-url",
      "type": "IdentityHub",
      "serviceEndpoint": "http://company1:7171/api/identity/identity-hub"
    },
    {
      "id": "#dsp-url",
      "type": "DSPMessaging",
      "serviceEndpoint": "http://company1:8282/api/dsp"
    },
    {
      "id": "#self-description-url",
      "type": "SelfDescription",
      "serviceEndpoint": "http://company1:7171/api/identity/identity-hub/self-description"
    }
  ],
  "verificationMethod": [
    {
      "id": "#company1-key-1",
      "controller": "",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "publicKeyJwk": {
        "kty": "EC",
        "kid": "yy_d7lbBzYC8EC0NDdX-r4fyf9SLsl8ZzviM5EzWRS4",
        "crv": "P-256",
        "x": "WohdFPABfA3tv5jYqR_qPEpZDRjSjQaoh4PlHBLemlY",
        "y": "c6eeeLzV0m4HEioTUL59yREOqILPxpx5m-MNCTDO6nI"
      }
    }
  ],
  "authentication": [
    "#company1-key-1"
  ]
}

The example DID (which comes from dataspaces domain) is a web-based one, which is stored on the participant premises, so GDPR is not a problem. However, DID documents used in SEDIMARK are stored in the Registry (actually, in the Tangle). Thus, we don't want to open the discussion about GDPR in a shared DLT infrastructure. For that reason no private info should be stored in the DID (which is not the objective of the DID, but could be a possibility).

What we can do is to follow a similar approach and include a serviceEndpoint for retrieving the self-description, which will be provided by the participant itself. Whether a URL pointing to the participant domain should be considered to be private info or not is something I prefer not to think about 🤔.

Next question is how the self-description is formatted/presented. From the screenshot in #4 (comment), there are information there which is currently not included on the SEDIMARK VC. What do we do with that info? Remember, this serves the purpose of building a human readable participant profile. For M2M communication the DID URI is enough. For this reason we believe this should be deferred to 2025. Anyway, we have identified 2 options:

1. One approach would be to include an extra service endpoint in the DID document pointing to that info (self-description) together with its signature with the identity key (maybe a hash is enough as the only one able to modify the DID is its owner). That way the self-description could be validated by consumers to be sure it has not been tampered or modified without the participant consent. The info included on the self-description can be whatever we think is interesting, as it will be stored within the toolbox on participant premises and exposed in a public endpoint in a similar way as the self-listing.
2. The other one is to include that info on the SEDIMARK VC and enable a mechanism (also using service endpoints on the DID doc) for the consumer to be able to ask for a "public VP" of the provider and use selective disclosure from the SEDIMARK VC to generate that "public VP".

I personally like the second option a bit more as it uses more standard mechanisms, but it is more complicated to implement. Its counterpart is the fact that "getting a VP from the provider" to build its public human-readable profile is "strange", as VPs are supposed to be presented and not retrieved. Main difference, and the benefit of the second approach is the fact that the SEDIMARK issuer "has validated" such info (only theoretically, no real validation of the claims is performed by the issuer).

[xamcost]

Hi there! Following yesterday's meeting, I am putting here the properties we decided to ask in the participant registration form. They will be exposed publicly via a json document hosted on the participant's premises. These properties are:

Property	Required	Comments
First name	❌
Last name	❌
Username	✅	May be stored in the catalogue to ease search by providers
Email	❌	The main way to contact a provider so far, maybe we will add more later
Organization	❌
Picture	❌	A URL to a picture/logo
Homepage	❌	A URL to an organization or personal website

Optionally, we could consider a summary/short description and description fields, to leave the option to participants to write a small bio about them.

Feel free to suggest any addition/removal.

@telsaleh @juanrasantana Let us know if we can help translating these fields into their equivalent in known ontologies like foaf.