## 5 Gaia-X-Med: Our Solutions
### Contract Negotiation  
XFSC [19] enables authorization through a _Policy Engine_ that, once deployed and configured, allows Providers to set certain rules to handle incoming requests from Consumers. We have decided to approach the topic of _authorization_ by using _digital contracts_ as a base. Contracts are only briefly touched upon in the Gaia-X architecture itself; stating that while they form an important part of the ecosystem, their implementation details are outside of scope of the architecture [24]. We had three initial requirements for our digital contracts: they should be machine readable, able to be digitally signed by involved Participants, and tamper-proof. We found that the W3C Verifiable Credentials standard, which was already being used in the project for enabling Gaia-X Credentials, fulfilled all of these requirements:  
* they are formatted as JSON-LD and are furthermore validated against schemata, so they are _machine readable_;
* they can be _digitally signed_ with cryptographic keys, which also effectively renders them _immutable_;
* additionally, they can be bundled by anyone into _Verifiable Presentations_, which can also be signed individually from the Verifiable Credentials within. This provides an excellent method for allowing a neutral third party to \"notarize\" a collection of Credentials. A Gaia-X-Med Contract passes through four steps, as shown in Figure 9. The content of a Contract comprises two parts; first, a static, free-form (non-machine readable) non-negotiable text part which the Consumer has to agree to. The other part is defined through the _Contract Template_, which is a _JSON Schema_ ([[https://json-schema.org/](https://json-schema.org/)]([https://json-schema.org/](https://json-schema.org/)) (accessed on 5 December 2024)) object embedded inside a Service Offering's Credential. Through the Contract Template, a Provider can offer configurable parameters for the Service to the Consumer, which allows them to negotiate certain aspects of the Contract. For example, a web hosting service could have a configurable amount of data storage. When visiting the Catalog web application and picking the \"Negotiate contract\" option for a Service they wish to consume, the Consumer user is presented with the Service's Contract Template rendered into a form, as well as the static contract terms to which they have to give their explicit agreement. The data from the submitted form are bundled and  
Figure 9: How a Contract is formed in four steps. The signed terms and identities of both Consumer and Provider, as Verifiable Credentials, as well as a _Negotiation Credential_ containing negotiation metadata, are bundled by the federation-wide Negotiation Service into a Verifiable Presentation, which is signed as a whole, resulting in the finalized Contract. signed into a _Contract Offer_ (as a Verifiable Credential) and sent to the federation-wide Negotiation Service, which acts as a notary between the Consumer and the Provider. It creates a Verifiable Presentation containing the Consumer's Contract Offer and adds its own signature, creating the _Notarized Contract Offer_, which it then forwards to the Provider. At the Provider's end, a service called the _Contract Service_ listens for incoming Notarized Contract Offers from any whitelisted Negotiation Service. Once an offer arrives, it too performs some routine checks including re-confirming the authenticity of the Consumer making the offer and validating that the offer aligns with the Contract Template. It then forms a response to the offer. By default, all valid offers from valid Participants are accepted; however, a Provider is also able to extend the Contract Service's negotiation routine with programmatic rules which, based on the Consumer's identity and the content of the offer, result in one of two additional outcomes:  
* The offer is _denied_--for example, a Provider can make the decision to not accept offers coming from Consumers having a certain Claim; e.g., restricting the Service to only Consumers from research organizations.