Different power constraints for mandators and mandatees

[anarosa-es]

The class "Power" of the RPaM Ontology has several attributes and is related to classes "Mandator" and "Mandatee" by associations. However, I cannot see how this model supports scenarios where a Mandator tranfers a power to a Mandatee and the transfered power has different constraints than the original one.

For instance, the mandator can have a power with 1.000.000€ of financial threshold but when he/her transfers that power to a Mandatee grants the power with 10.000€ of financial threshold. The same situation can happen regarding to geospatial and time constraints.

[eprocurementontology]

Version 1.1.0 (see branch 1.1.0) does, in principle, cover the situation you describe. One good way of illustrating how would be to provide an example of implementation of a Mandate. We'll try to come up with such an example the soonest, so we can start discussing whether the model supports or not the situation.

It would be great also if you could provide an example of how the ES REA Data Model satisfies this situation. Could you provide one, please?

[anarosa-es]

Thanks for the response. I'm afraid that I can only see one branch, the master branch.

In REA there is not such problem because we have a far much simplier model. For us, a "power" is a combination of "public organization"+"public service"+"formality"+("restriction"), and it is only regarding to powers that can be granted to a mandatee.

"Formality" of a public service is a short list of formal interactions between the person (agent) and the public body that processes the public service during such process (being notified, paying a taxes or fees, collecting money, withdrawing/resigning, and others).

You can grant a power either for any public service offered by one particular public organization (at any level of the organization chart), or for a particular public service offered by a public unit, or for a particular formatility. Restrictions on formatilies are been under development.

We are writing a description of our systems for granting representation that I will share with all of you.

[paulakeen]

Please see how we propose to define and manage mandator and mandatee constraints in these files:

1. The list of Power User Constratint (PUC) in the spread-sheet;
2. How the Conceptual Data Model defines the properties mandatorConstraint and mandateeConstraint in the EAP file;
3. The examples Mandates-Dataset-example-1.ttl, eMandateRequest-example-1.ttl and eMandateResponse-example-1.ttl;
4. Some basic SPARQL queries are also provided to test the consistency of the Mandate model (it uses the Mandates-Dataset-example-1.ttl;
5. The T-Boxes for the Ontology, Request and Response are now available in the folder 03-Syntax_Bindings/OWL-DL-TTL/;
6. An UBL-2.3 NDR conformant model and artefacts (documents) are currently being developed to offer the possibility of exchanging the eMandateRequest and the eMandateResponse documents as UBL-2.3 XML instances. These developments will be stored in the folder 03-Syntax_Bindings/UBL-2.3-NDR-based.

[penzespetra]

We collected some aspects of constraints for mandators, mandatees and mandates based on the Hungarian practice. In Hungary, the Client Setting Register (www.rendelkezes.gov.hu) keeps records on the individuals’ dispositions related to the e-administration and makes them ascertain to the entitled persons. The objective of the service is to allow citizens - and later progressively organizations as well - to create their dispositions in particular as regards the identification and contact modes, as well as to use other electronic services, and concerning eMandates: provision and query of authorizations. Administrative dispositions – among them eMandates - can only be created by natural persons who are major of age and subject to one of the personal basic registers (i.e. personal data and address register, central registry of residents without Hungarian nationality, personal register of non-resident natural persons using electronic administration in Hungary). That may improve with the use of eIDAS authentication.

Regarding constraints of creation of mandates, majority – in recent phase – means age above 18 years, however according to the Civil Code in certain cases natural persons under 18 years must be regarded as major if they are married, which provide them with acting capability. On the other side, age above 18 years, does not mean automatically full capability of acting. For example, natural persons under tutorial control, e.g. mentally disabled people or addicted people. These constrains are not general, they are defined according to cases by the Court. Because of GDPR, service providers can not know these data automatically.

In Hungary, for the authentication of natural persons current name, birth date, birth place, and mothers’ name must be provided, not only the name and age, therefore these data must be provided for the natural person Mandator and Mandatee, as well. These data are necessary for the authentication and can be obtained from certain registries based on the identification numbers of identification documents according to GDPR. Identification of legal persons in Hungary is a two-step process, where first a natural person identifies her/himself and after verifies its representation power by giving the identification number of the legal person. The service provider examines whether the given identification number can be linked to the authenticated natural person. This identification number in practice, is the tax number. However, legal persons can be different kinds (e.g. companies, NGOs, public organizations), and are registered in different registries (which are in some cases are not electronic, e.g. churchs). Concerning representation of legal persons, the scope of the power must be examined, as well, for example representation can be independent or co-representation. In case of co-representation power, legal declaration only can be valid if the co-representing party verifies it.

Another important aspect in Hungary is there are certain mandates which need acceptance from the part of the Mandatee. Generally, a mandate is not a contract, because it is a type of one-side legal declaration, mandatee should not accept it.

[everis-rpam]

Super interesting! a lot of food-for-thought...thank you for the input.

(P.S. The link in your comment is not working: http://www.rendelkezes.gov.hu/ ...is the content also in English?).

[penzespetra]

Sorry, for the link: https://rendelkezes.gov.hu/rny-public/ There is a short description in English, the service is available in Hungarian.

[anarosa-es]

Does the overall model "Power" class represent a mandator's power or a representation power??

I see no need to model mandator's powers because this is not for registration purposes. Mandator's powers exist even without the existence of any mandate and if a mandate exists, then somehow the mandator's capability to grant some power by means of a mandate haven been already proven in the registration process.

So, I understand that the overall model "Power" class represents a representation power granted to a mandatee. Am I wrong?

[paulakeen]

My answers below:

1. The power of the mandator is the one that a service provider needs to check for the mandatee to be eAuthorised. Hence, this may refer to any "power".

2. Once granted to a mandatee, this power is the mandatee's "representation power".

3. Indeed, you're right, what it is necessary to register is the "empowerment act", i.e. the granting of the representation power onto the mandatee.

In conclusion:

The "Power" class represents two different things:

1. The mandator's power, with its own constraints, if any, and
2. The representation power granted to the mandatee, with its own constraints, if any;
3. In the case the mandator is a mandatee that received its powers from another mandate then the power of the mandator is a representation power, too, and a reference to the mandate where this power was granted should be provided, too (see latest version of the Conceptual Data Model, below, class "PowerSource");
4. In the case the mandator received the power "by law", then a reference to that legislation could also be indicated, too (which is also represented in the diagram below, via the class "Legislation").

[paulakeen]

Dear @penzespetra , after reflecting about your contribution above, we need to say this:

1. The Hungarian information requirements about natural persons has brought us to re-model the rpam:Agent model. We see the need to have a NaturalPerson so we can extend the foaf:Person with additional placeholders for the "Father Name" and "Mother Name", which is also a requirement in other EU MS countries (e.g. Spain) for an unambiguous identification of the Person. Thanks for that!
2. The considerations about the age and adultness is covered in principle by the foaf:age property.
3. The two-stage identification process for Legal Persons, first identification of the natural person based on specific types of identifiers would also be covered by the model and the identification policy (based on eIDAS). The identification of the relationship between the natural person and the legal person is proven via Mandate.
4. Altough we do not see the co-representation as an in-the-scope of the eAuthorisation, we think that the RPaM should provide a means to express that fact. So we have added an object property named "coRepresentative" that has as domain the "Mandatee" class and as range the "Mandatee" class. This should be sufficient to cover cases where two or more representatives need to present their mandate(s) together for a Legal Person to use a Service. This seems weird to us, as in the end a Service is ultimately used only by one single user (see diagram above, too).

Many thanks for your input!!!!