diff --git a/RFC Documents/RFC053/README.md b/RFC Documents/RFC053/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..718e7f65fab3fe9c54ac0bdcd23039cd2f0237c9
--- /dev/null
+++ b/RFC Documents/RFC053/README.md	
@@ -0,0 +1,106 @@
+# RFC053: Allow Service Consumers without PKI certificate
+
+## Background and rationale
+
+In the framework it is currently defined that Service Consumers must have a valid PKI certificate (on [Admission](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission), in the table under Admission Criteria, Adhering Parties must have a Qualified e-seal, optional for Entitled Parties).
+
+In machine-to-machine use cases, this makes sense, as the Service Consumer will always request data from the Service Provider itself, using the PKI certificate for acquiring an access token and relying on delegations provided by Entitled Parties as proof for access to data.
+
+Whenever a Service Consumer (organisation, represented by a human using an iSHARE Identity Provider) is not using a machine-to-machine interface to access a service (data) provided by the Service Provider, the data itself is being accessed by an intermediate party, acting on behalf of the actual Service Consumer. The actual Service Consumer (using the service of the intermediate party) is not formally onboarded as Service Consumer and therefore not obliged to comply with the legal context of the transaction, for instance with license usage requirements. This leaves room for the intermediate party to provide it's own ("platform") service, supporting the access of data to parties that should actually be considered Service Consumers. And in this way it hinders the Entitled Party in achieving data sovereignty.
+
+## Proposed change
+
+### Purpose
+
+This RFC intends to resolve this by
+
+- Lowering the entry barrier for Service Consumers, by allowing Service Consumers to onboard without a PKI certificate
+
+thereby
+
+- Empowering Entitled Parties to even better achieve data sovereignty
+- Limiting the power of platform as intermediary services
+- Decreasing possible liability issues for platforms
+
+### Description and principles
+
+The solution direction is that Service Consumers can onboard more easily if they do not require API access. Once onboarded, the Service Consumers can make use of Authorisation Registries to formally register legally binding authorisations. Those authorisations can be used by Service Providers as proof for executing a service transaction (providing data). The Entitled Party can in such a way be sure that the Service Consumer to which the authorisation is provided is legally bound to license under which the data is provided. The intermediate party, providing a service to the Service Consumer to consume the data, can use this authorization to access the service at the Service Provider and provide the service to the Service Consumer.
+
+This change does require that, instead of proving their authenticity with a PKI certificate, Service Consumers are onboarded using a recognised organisation identity provider. In The Netherlands for instance [eHerkenning](https://www.eherkenning.nl/) can fulfil this. The required [level of assurance](https://www.eherkenning.nl/en/levels-of-assurance) for onboarding with eHerkenning is 3, for further usage 2+.
+
+Formally the Service Consumers will have the same role and role name. The difference between the two types of Service Consumers can be derived from the response in the [/parties endpoint](https://dev.ishare.eu/ishare-satellite-role/parties).
+
+### Example use cases
+
+- In DVU an Entitled Party can create an authorisation for another party. That authorisation is stored in the Authorisation Registry and used to request the data by the platform that is provided by RVO. The party to which the authorisation is provided however, is not formally registered as Service Consumer and its legal obligations are limited. This is acceptable for now, given the nature of the data, but could become a problem in the future when more sensitive data would be shared using DVU.
+- When a Service Consumer requests a physical service, such as access, its unlikely that the client will consume an API at that point. Its also not likely (and desired) to share a PKI certificate with many potential clients. In combination with the role of the identity provider it would make sense to request access to the service by an intermediate party on behalf of the Service Consumer, in line with the above described solution principles.
+
+## Impact on the ecosystem
+
+The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role).
+
+| Formal role               | Technical impact  | Business / legal / functional / operational impact |
+| ------------------------- | ----------------- | -------------------------------------------------- |
+| Service Consumer          | Yes -> No PKI certificate required for all Service Consumers | Yes -> bound to stricter legal requirements, such as license |
+| Service Provider          | No                | Yes -> improved liability risk                     |
+| Entitled party            | No                | Yes -> improved data sovereignty                   |
+| Authorization Registry    | No                | No                                                 |
+| Identity Provider         | No                | No                                                 |
+| Identity Broker           | No                | No                                                 |
+| Data Space Administrator  | No                | No                                                 |
+| Satellite                 | Yes -> Allow Service Consumers to be added without certificate | No    |
+
+## Impact iSHARE Foundation (Scheme Owner)
+
+- The [iSHARE Trust Framework](https://framework.ishare.eu)
+  - Change the table [here](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission#admission-admissioncriteria) to reflect that Service Consumers must either provide a PKI certificate, or onboard using a recognised organisation identity provider.
+  - Add the requirement that a Service Consumer must be registered with a recognised organisation identity provider.
+  - Add a list of recognised organisation identity providers, starting with eHerkenning for Dutch companies.
+- The [developer documentation](https://dev.ishare.eu) (as an extension of the iSHARE Trust Framework)
+  - Clarify the usage of client_assertion in the previous_steps attribute of the [delegation mask](https://dev.ishare.eu/reference/delegation-mask) when requesting delegation evidence. It's not possible to provide a client_assertion by the Service Provider when the Service Consumer itself has not provided a client_assertion to the Service Provider. This is acceptable depending on the nature of the data that is shared.
+  - Change the [Create entitled party](https://dev.ishare.eu/ishare-satellite-role/create-entitled-party) endpoint so that also Service Consumers without certificates can be created through this endpoint. This will be a good time to change this separate endpoint into a POST operation on the [/parties](https://dev.ishare.eu/ishare-satellite-role/parties) endpoint thereby complying more with REST API design standards.
+- The OpenAPI definitions on [Swaggerhub](https://app.swaggerhub.com/search?owner=iSHARE)
+  - Change the [Create entitled party](https://app.swaggerhub.com/apis/iSHARE/iSHARE_Scheme_Specification/2.0#/iSHARE%20Satellite/%2Fep_creation) endpoint description.
+- Example implementation in [Postman Collections](https://dev.ishare.eu/demo-and-testing/postman.html)
+  - No changes
+- Code that is published on Github:
+  - [iSHARE Satellite reference implementation](https://github.com/iSHAREScheme/iSHARESatellite)
+    - Implement changed entitled party endpoint specification
+  - [eSEAL certificate procurement guide](https://github.com/iSHAREScheme/eSEALsGuide)
+    - No changes
+  - [iSHARE.NET service consumer core components](https://github.com/iSHAREScheme/iSHARE.NET)
+    - No changes
+  - [Python iSHARE package](https://github.com/iSHAREScheme/python-ishare)
+    - No changes
+  - [iSHARE code snippets](https://github.com/iSHAREScheme/code-snippets)
+    - No changes
+  - [Reference implementation for Authorization Registry](https://github.com/iSHAREScheme/AuthorizationRegistry)
+    - No changes
+  - [Reference implementation for Service Provider](https://github.com/iSHAREScheme/ServiceProvider)
+    - No changes
+- The implementation of the iSHARE satellite for iSHARE as the Scheme Owner on https://sat.ishare.eu and https://sat.uat.isharetest.net
+  - Deploy the new satellite
+- The [public website](https://www.ishare.eu)
+  - No changes
+- Internal documentation
+  - No changes
+- [Authorization Registry test implementation](https://ar.isharetest.net/)
+  - No changes
+- The [Conformance Test Tool](https://ctt.isharetest.net/admin/account/login), tests listed on https://ctt.isharetest.net/admin/test-cases
+  - If a CTT is available for iSHARE Satellites, it should implement the updated entitled party creation endpoint.
+- iSHARE test satellite (used for conformance testing): https://scheme.isharetest.net/
+  - No changes (this is iSHARE 1.0)
+- iSHARE test certificate authority: [EJBCA Public Web](https://ca7.isharetest.net:8442/ejbca/)
+  - No changes
+- [iSHARE Change Management documentation](https://changes.ishare.eu)
+  - No changes
+
+## Implementation
+
+### Release schedule
+
+Describe the foreseen release planning for this RFC. Should it be combined with other RFCs? What is the required release timeframe?
+
+### Communication
+
+Describe required communication topics and means.