2023-02-08 Trust & functional brainstorm

This live meeting was scheduled to get a first sense of direction. 2 subjects were on the agenda: how can one vendor trust the authorizations of another vendor within the same organisation context? And, what feature would allow authorizations to be used by multiple vendors.

Trust

The general direction that was decided on is to have a default level of trust between vendors. Vendors qualify their application and the care organisation only uses qualified applications. If a care organisation uses two vendors for a use case and both are qualified then those vendors automatically trust eachother within the context of that use case. Vendors will not require additional configuration or trust regarding that use case. This does mean that the care organisation has to authorize a vendor for a certain use case.

Functional solution

The main direction of the discussion is towards adding a functional identifier to an organisation credential and then use that identifier in the credential subject of a verifiable credential.

This changes the flow for requesting an access token. The requester will have to send both the authorization credentials and the organisation credential in the request. The combination of both credentials would satisfy the security constraints.

The issuer of the authorization credential will also have to monitor the network for any new organisation identifiers that match. When noticed, the DID that has received that functional identifier as subject will also have to receive an authorization credential.

Using a combination of organisation credential and authorization credential would allow the credential holder to use the authorization credential at a different verifier than the issuer. The verifier can validate the given credentials. How the verifier can check that one of its customers has the same functional identifier as the issuer is to be researched.