Improve structure of UraCredential

[stevenvegt]

In #3221 a new UraCredential is proposed. I think the structure of the credential can be improved.

An uraCredential models the membership of a care organisation with the UZI Registry.

In a JSON-LD document every object is a node in a graph with relations to embedded objects.

ThecredentialSubject node is the Care Organisation and can be modeled as an schema:Organization which has a field memberOf. This field can be used to point the membership with the UZI registry.
The membership itself can be modeled with the
schema:ProgramMembership.

The schema.org schema's do not always fit nicely and an alternative is to model our own schema's or look at other schema's. Let's discuss. I personally prefer a bit awkward schema.org schema's above custom ones.

classDiagram
    direction
    VerifiableCredential <|-- UraCredential
    UraCredential --> Organization
    Organization --> ProgramMembership

    class VerifiableCredential {
        Identifier id
        Identifier issuer
    }
    class Organization{
      +Identifier id
      +String legalName
      +Membership memberOf
    }
    class ProgramMembership{
      + String programName
      + String membershipNumber
      + String 
    }
    class UraCredential {
        Organization: credentialSubject
    }

Loading

See this playground link:
https://tinyurl.com/29blhotl

Such a credential will look something like this:

{
  "id":"did:nuts:123#demo-uracredential",
  "type": [
    "VerifiableCredential",
    "NutsUraCredential"
  ],
  "issuer":"did:tdw:cibg-issuer",
  "credentialSubject": {
    "@id":"did:nuts:123",
    "@type":"Organization",
    "legalName": "De Regenboog",
    "memberOf": {
      "@type": "ProgramMembership",
      "membershipNumber": "12345",
      "programName": "UZI Register Abonnee"
    }
  }
}

[reinkrul]

It now looks like a credential that specifies a legal organization that can be a member of multiple programs, but then "URACredential" might be too narrow? But at the same time, interpreting credentials will become harder if they're less defined (URACredential vs OrganizationMembershipCredential) because I think you want to express your trust model around issuer/VC type combinations.

This way, you have an additional validation step that NutsUraCredential only contains a memberOf entry for the UZI program. Which you can specify in a Presentation Definition, but I'd assume a "URACredential" only says something about the UZI URA.

[woutslakhorst]

we discussed this credential as: "let's not spend too much time on it" because:

• requirements are unknown
• nuts context should not define it
• will probably change in the future, no matter what you propose now (see point 1)
• discussion would just be based on personal preference not requirements (see point 1)

[bramwesselo]

what should be done to include (enable authentication for) Dutch suppliers and, let's say, Belgium and Germany healthcare providers? I have the feeling they are current excluded by the UraCredential.