FIELD The invention relates to an authorization decision method in a distributed environment.

BACKGROUND Contemporary Information technology (IT) environment is formed by a complex interconnected distributed network of heterogeneous devices. A main object that occurs in such an environment is to decide which entity is authorized on which resource to carry out which operation.

At present, an authorization decision is typically delegated to a trusted third party that is realized as a centralized entity known as authorization server. This partially results from the fact that resources have been managed and stored centrally.

In general, if a requestor asks a resource server via a client device for a resource, the resource server approaches an au ^¬ thorization server for an authorization decision either di- rectly or via a redirection through the client device. The au ^¬ thorization server utilizes policy storage to store policies declared by resource owners, and, optionally, a user data stor ^¬ age. The user data storage contains the previously collected requestor data that may be leveraged in some policy types, e.g. an adaptive access control.

With the evolution of IT and the arrival of Internet of

Things (IoT), the resources that need to be protected are of ^¬ ten connected to local devices such as physical devices, ve- hides, buildings, and other items. These items then repre ^¬ sent the resource servers as they really enable the access to the resources. The hardware of these devices is often not very powerful and often has poor connection capabilities. This is in contrast to the approach utilizing a centralized entity such as an authorization server which has high communication complexity.

A technique to address the lack of interoperability among de ^¬ vices dealing with identity establishment in a distributed network is the Fast Identity Online (FIDO) Standard launched in February 2013. The FIDO standard depends on an attestation principle, which guarantees a trust between components of the distributed architecture. However, FIDO standard proposes an authentication framework. The authentication is only one part of an authorization process. Further, transaction verification carried out by FIDO standard enables a resource owner to decide upon a transaction concerning a resource of the resource owner. FIDO standard does not deal with an authorization process which leads to a decision upon an action concerning the requestor being in- equivalent to the resource owner. Moreover, FIDO standard needs a centralized authentication server as a trusted entity to declare policies used in the authentication process. Such a policy is further necessary for any requestor trying to authenticate .

An authorization decision method with the features of the first part of claim 1 is known from US2017/063931A1

SUMMARY

The object of the present invention is to provide an improved authorization decision method in a distributed environment.

This object is met by a method according to claim 1. Pre- ferred embodiments are disclosed in the subclaims. An authorization decision method is carried out on a distrib ^¬ uted environment comprising a policy verification distributor holding policy verification data identifying a policy declared by a resource owner and applicable on a resource and a requestor and a policy definition distributor holding policy definition data about the policy. A requestor asks a resource server via a client for the resource and accompanies the re ^¬ quest with an authorization decision. The client approaches the policy definition distributor to get the policy definition data in order to decide whether a policy relevant for the resource and the requestor is available. The resource server approaches the policy verification distributor to get the policy verifica ^¬ tion data in order to verify the authorization decision.

According to an embodiment the resource owner transmits the policy verification data to a policy registrator in order to register a valid policy, the policy registrator performing an authorization action deciding whether the resource owner is allowed to declare the policy for the resource. Upon regis ^¬ tering the policy as valid the policy registrator transmits the policy verification data to the policy verification dis ^¬ tributor .

According to an embodiment as an initial step the requestor addresses the client to get the resource, as a subsequent step the client decides whether a policy relevant for the resource and the requestor is available based on the policy definition data from the policy definition distributor, as a subsequent step, if the policy is available, the client performs a deci ^¬ sion signing process, as a subsequent step the client sends the request for the resource and the signed decision to the re ^¬ source server, as a subsequent step the resource server per ^¬ forms a verification process based on the policy verification data received from the policy verification distributor, and as a subsequent step, if verification was successful, the re ^¬ source server sends the requested resource to the client. According to an embodiment, in order to perform the decision signing process the client sends a request for signing the de ^¬ cision to a requestor authentication module, wherein as a subsequent step the requestor authentication module returns the decision with a signature to the client, and wherein as a sub ^¬ sequent step the client signs the decision with the signature in an attestation process.

According to an embodiment the ownership of the resource is represented during the initial registration of resource by knowledge of a unique identifier connected to the resource, subsequently by knowledge of a cryptographic primitive pro ^¬ tecting bound to the identifier.

According to an embodiment the resource server approaches the policy verification distributor for the last record of policy verification data with respect to the resource identifier, wherein in response the policy verification distributor transfers the record in a trusted manner. According to an embodiment the requestor approaches the pol ^¬ icy definition distributor for the record of policy definition data with respect to the resource identifier and a re ^¬ questor identifier, wherein in response the policy definition distributor may transfer the record in a trusted manner.

According to an embodiment a blockchain-based implementation of the policy declaration process of the policy registrator and the policy verification distributor is carried out. According to an embodiment a trusted computation is carried out .

According to an embodiment, a requestor authentication module and/or the client include a trusted platform module.

The authorization decision method is in particular suitable for the world of IoT in which a system design is decentralized to a high degree. In such a distributed environment, the data privacy is a main issue. With respect to the data re ^¬ lated to the requestor, IoT devices generally collect private user data for an evaluation. However, the originator of the data i.e. the requestor would like to have control over these data. According to the authorization decision method the policy stored on the policy server references the user data, while these data are stored and processed locally under the originator's control only. With respect to the policy data, these policy data may contain private information. The au ^¬ thorization decision method prevents the policy data to be read by anybody but the resource owner and the requestor. Devices of a distributed environment are often constrained in both ways, in communication capability and computational power. The authorization decision method employs a protocol designed to reduce the number of transferred messages that are necessary to establish the authorization decision. Moreo- ver, the protocol relaxes the communication constraints by switching from synchronous mode to asynchronous mode. In con ^¬ sequence, there is no demand for powerful real-time-employed centralized entities. The dynamicity within a distributed environment, namely changes in the set of devices, makes it difficult to manage a consistent trust throughout the system. The authorization de ^¬ cision method addresses the trust demands by relaxing the real-time inter-device trust establishment. In addition, the protocol provides the trust in the authorization decision as implicit for both parties, i.e. the requestor and the re ^¬ source server.

According to an embodiment blockchain technology is not only used for a requestor registration and for a policy declaration during the establishing phase, but also for an evaluation and for a protocol process. The properties of a trusted database according to authoriza ^¬ tion decision method may be blockchain-based . The implementa ^¬ tion can be built over an Ethereum framework as it would enable to capture the implementations specifics. Ethereum is a decen ^¬ tralized framework for distributed applications based on blockchain technology. Ethereum abstracts from the specific blockchain implementation, such as Bitcoin, and provides a full Turing state machine.

The trusted computation of the authorization decision according to the authorization decision method is done by the re ^¬ questor. In contrast to the Ethereum approach which lets peers connected into the system to do the trusted computation, there is no loss of the locality in the computation.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is explained in greater detail below on the ba- sis of preferred exemplary embodiments with reference to Fig ^¬ ures, in which:

Figure 1 shows an authorization decision process architec ^¬ ture,

Figure 2 shows a policy retrieval process,

Figure 3 shows a policy declaration process, and Figure 4 shows a resource request process, wherein Figure 4A contains a first part and Figure 4B contains a second part.

DETAILED DESCRIPTION Figure 1 presents the basic principles for an authorization decision process architecture. The following entities with roles and competencies are involved: A resource owner is the originator of a policy applicable on a resource. A policy registrator ensures the trust in a process of regis ^¬ tering a valid policy.

A policy verification distributor ensures the trust in data distributed to enable to identify the valid policy.

A policy definition distributor possesses information about the declared policy.

A requestor initiates an action.

A resource server manages an access to at least a resource.

A client is a tool for the requestor to approach the re ^¬ source .

A requestor authentication module represents the requestor's identity.

All of the entities can have multiple instances in a single system.

Figure 1 further presents the data exchange paths between the various entities. The authorization decision process is di ^¬ vided in two sections: A policy declaration and retrieval process covering steps A.l, A.2, A.3, B.l and B.2 of Figure 1, and a resource request process covering steps 1 to 9 and an optional authenticate step of Figure 1.

Policy Declaration and Retrieval Process

The resource owner declares at least a policy applicable on a resource and a requestor. This means that a single policy is held in a single point of time for a single resource and a single requestor.

The resource owner transmits policy verification data to the policy registrator (step A.l) . The policy registrator ensures the trust in the process of registering the valid policy, in ^¬ cluding some form of authorization of the request for the registration. The processing of the policy registrator includes an authorization action deciding whether the resource owner can actually declare the policy for the resource.

After registering the policy as valid, the policy registrator transmits the policy verification data to the policy verifi ^¬ cation distributor (step A.2). The policy verification dis- tributor ensures the trust in data distributed to enable to identify the valid policy.

The authorization decision step of the policy registrator can self-apply using the infrastructure implementing the authori- zation decision method shown in Figure 1. In such case, the policy registrator is both a requestor and a client. The pol ^¬ icy verification distributor is a resource server, while simultaneously using itself as a source of policy identifiers. There must be already publicly declared initial policies in the policy definition distributor dealing with the registration action.

The policy registrator and the policy verification distribu ^¬ tor may be coupled and may occur as a single entity providing multiple tasks. The policy registrator basically decides, which policy will be permitted to be later distributed by the policy verification distributor. Any policy is applicable at the point of time, when it becomes distributed by any of the instance of the policy verification distributor.

The policy verification distributor transfers the policy ver ^¬ ification data to any resource server asking for them (step A.3)

The resource owner additionally transmits policy definition data to the policy definition distributor (step B.l), so that the policy definition distributor possesses an information about the declared policy. The policy definition distributor is not required to be trusted and provides simply a distribu ^¬ tion of the policy throughout the system. The existence of policy definition distributor aims on performance require- ments.

The policy definition data are sent by the policy definition distributor to any requestor asking for them via the client device (step B.2) . This may be done without an authentication or authorization action. In the case the policy is perceived as secret information, there has to be an authentication action before sending the policy to the client device. In the latter case, the policy definition distributor has to be trusted .

To achieve the anonymity of the requestor during the request ^¬ ing for a resource, the policy verification data gotten from the policy verification distributor mustn't be linkable with the policy definition data gotten from policy definition dis- tributor. The policy verification data may be represented by a digital signature key pairs. The digital signature algo ^¬ rithm used must ensure the unlinkability between the public and private key. In the case, the anonymity of the requestor is an unwanted feature, the key pair can be replaced by a simple identifier. This approach makes the initial policy declaration process less computationally demanding. A random identifier generation may be used instead of a public key generation.

Resource Request Process The requestor may carry out an authentication process with a requestor authentication module having the function of presenting endpoint requestor's identity. The requestor may be registered in a public repository.

As an initial action the requestor addresses the client as a mediator to get the resource (step 1) . In succession the client obtains the policy definition data relevant for the resource and the requestor from the policy definition distributor (step B.2) . According to Figure 1 the policy data are encrypted.

Then, the encrypted policy is send to the requestor authentica ^¬ tion module for decryption (step 2) . The decrypted policy is retransmitted to the client (step 3) . This relaxes the trust constraints in the client. If the client is trusted to a de- gree, that it is able to operate as the requestor authentica ^¬ tion module, the decryption can be done by the client itself.

Then the client decides whether a policy relevant for the re ^¬ source and the requestor is available and counts the decision (step 4) .

After the decision has been made, the client either directly informs the requestor about a deny decision (step 5.1) or performs a decision signing process. In order to perform the deci- sion signing process the client sends a request for signing the decision to the requestor authentication module (step 5.2). The requestor authentication module returns the decision with a signature to the client (step 6) . Subsequently, (step 7) , the client signs decision with the signature in an attestation pro- cess. As in the case of policy decryption, the client can server, in case of appropriate trust, as both requestor authentication module and client.

Then the client sends both the request and signed decision to the resource server (step 8) . After receipt of the request and the signed decision the resource server performs a verification process based on the policy verification data received from the policy verification distributor (step A.3) and the public at ^¬ testation data. If verification was successful, the resource server sends the requested resource to the client (step 9) . In Summary, the requestor (real-world entity initiating the action, represented in the protocol by the requestor' s authenti ^¬ cation module) asks the resource server for the resource and accompanies the request with the authorization decision (step 8 and step 9) . The client utilizes the policy definition distrib- utor to gain the policy definition data declared by the re ^¬ source owner (Step B.2) . This step may be done asynchronously. The resource server further utilizes the policy verification distributor to get the policy verification data to verify the decision (Step A.3). This step may also be done asynchronously.

Figures 2 to 4 show embodiments of different process section of the authorization decision process. In the Figures res_id represents a unique identifier connected to a resource, req_id represents a requestor identifier, K+ represents a public key and K- represents a private key for used asynchro ^¬ nous cryptography algorithm. K_pol{n} represents a policy key relevant to policy n which enables verification. K_ch{n} rep ^¬ resents a change key relevant to policy n, which enables to invalidate the previous policy, e (K+req, data) represents encryption of data using the public key of the requestor. s(K-ch{n}, data) represents a signature of data using the private change key.

The initial transfer of resource ownership from the physical to the digital environment is represented by the ownership of the unique identifier res_id connected to the resource. The value of the identifier must be agreed upon between the re ^¬ source owner and the resource server. The identifier may be unchangeable, i.e. static from the origin of the resource, or may be changeable to enable an out-of-bounds reset mechanism. Figure 2 depicts an embodiment of the policy retrieval pro ^¬ cess, wherein the policy verification distributor transfers the policy verification data to the resource server and the policy definition distributor sends the policy verification data to the requestor.

According to Figure 2 the resource server approaches the pol ^¬ icy verification distributor for the last record of data with respect to the resource identifier res_id (step 1) . In re- sponse the policy verification distributor sends back the record in a trusted manner. In the case of using public key cryptography as the trust ensuring mechanism, the record is signed by the private change key K-ch (step 2) . Further, according to Figure 2 the requestor asks the policy definition distributor for the record of data with the resource identifier res_id and the requestor identifier req_id (step 3) . In response the policy definition distributor transfers the policy record. The transfer does not need to be provided in a trusted manner as the used policy is checked by the resource server during the verification phase.

Figure 3 shows a blockchain-based Implementation of the pol ^¬ icy declaration process. Due to its decentralized, transac- tional approach, blockchain technology is a choice for imple ^¬ mentation of both the policy registrator and the policy verification distributor.

Figure 3 depicts the initial policy declaration (step 1 to step 4), followed by an update of the policy (step 5 to step 7) . The process sequence of Figure 3 is as follows:

Step 1 presents the transmission of the resource identifier res_id from the resource server to the resource owner. Step 1 may be performed with any protocol leading to the state that the resource server and the resource owner both know the re ^¬ source identifier res_id but no further untrusted entity learn it. Step 2 presents the initial registration process of policies initiated by the resource owner by means of blockchain tech ^¬ nology. The resource identifier res_id registers the resource for protection by an authorization mechanism, K+_chl registers a new protection mechanism preventing illegal change of policy 1. K+poll represents the verification data of policy 1 (without a reference to the relevant requestor) . Likewise, K+pol[i] represents the verification data of policy [i].

Step 3 presents a validation process performed by an entity working with blockchain.

In Steps 4.x policy definition data are transferred from the resource owner to the policy definition distributor. Step 4.1 shows the transfer of policy definition data of policy 1 and Step 4.2 shows the transfer of policy definition data of pol ^¬ icy 2. As there can be multiple policy definition distribu ^¬ tors, the resource owner can decide, where to send the regis ^¬ tration. E.g., in case the resource owner knows that the pol ^¬ icies will only locally be leveraged e.g. inside a smart home, the resource owner can send the policy to some local server .

Step 5 represents update of the policy - the private key K-chl is used for signing the data to enable verification of this action. In case the signing algorithm does not enable to read the signed values, the message has to explicitly add the plain form of the signed data. The message contains the cur ^¬ rently valid set of policy verification data K+pol{n}. A new public key K+ch2 for the next change of policies is declared, if necessary for the used signature scheme. This enables a simple form of verification in step 6. The en ^¬ tity verifying the data retrieves the last occurrence of change of policies for the given resource identifier res_id which contains the currently valid change public key and checks the signature against this key. Steps 7.x represent distribution of new policies to the policy definition dis ^¬ tributor similarly to steps 4.x.

The policy registrator competency (authorization of policy declaration) implemented by the blockchain is limited to the resource ownership evaluation - there is no fine-grained au ^¬ thorization about what kind of policies can resource owner declare. The initial policy declaration is secured by the se ^¬ crecy of the resource identifier res_id which is shared only between resource owner and resource server. After the decla ^¬ ration, the resource identifier res_id is made public, and the protection of the policy declaration is passed to the knowledge of the private key K-ch. The policy declaration protocol enables the blockchain to be public (hence any entity has read/write permissions) , as the necessary trust is achieved by the protocol and blockchain properties . As of the policy retrieval, as shown in Figure 2, based on a blockchain-based implementation the blockchain is used for the role of the policy verification distributor.

With respect to the server-based implementation there can be many variants of the used authorization mechanisms, network topology, etc. It is, however, important to notice, that a general server-based solution, in contrast to blockchain based, enables to achieve finer granularity in deciding what policies may be declared by what resource owners. The re- source owner can send the policies unencrypted to policy reg ^¬ istrator (as it is a trusted entity) that decides whether they are allowed and subsequently encrypts them. To work correctly, a trusted computation of the authorization decision has to be carried out. Namely, the resource server must have means to verify that the decision is the correct one with respect to the up-to-date policies. To achieve this, there are multiple ways. As an embodiment in Figure 4 which is divided in two parts, i.e. Figure 4A with steps 1 to 8 and Figure 4B with steps 9 to 13, details with respect to a pro ^¬ tocol using an attestation principle is shown.

The attestation principle enables any party possessing neces ^¬ sary information to verify that the received message was pro ^¬ cessed by a given algorithm running on a given type of hardware. This is achieved typically by the presence of a trusted platform module (TPM) , secure bootstrapping, etc. The use of an attested Hard- and Software is presented to the relying party by the signature of the message sent.

The trusted platform module provides a degree of security based on hardware and software security measures that is ap ^¬ propriate for working with respective resources. The typical trusted platform module would contain at least a secure in ^¬ ternal CPU and storage. In the embodiment two trusted plat ^¬ form modules are employed at the requestor side of the proto- col.

The trusted platform module of the requestor authentication module has the function of presenting endpoint requestor' s identity. It contains requestor's private key and is able to sign any message without publishing it. It may also enable to store requestor relevant policies and by this speed up the process of policy retrieval for often used resources, if re ^¬ questor works with different clients. The module also con ^¬ tains the attestation key protected by it. The trusted platform module of the client provides the at ^¬ tested authorization decision algorithm. The algorithm evaluates all the necessary data and provides a decision about the authorization of requested operation. The algorithm itself is out of scope of this document, however, it is identified by the attestation key, protected by the trusted platform module itself .

There is a trust established between the two trusted platform modules. The attestation principle should be used with re ^¬ spect to trusted platform module. Moreover the trusted plat ^¬ form modules can be merged into a single trusted platform module. In such a case, the implementation must ensure all the security features are preserved with respect to the com- munication out of the bounds of the relationship between the requestor authentication module and the client.

Step 1 shown in Figure 4 represents the initial action of the requestor that utilizes the client as a mediator to get the resource. The client needs to obtain the policy relevant for given resource and requestor, which is performed in steps 2 to 4.

In the depicted scenario of Figure 4, the policy is retrieved by the requestor authentication module from the policy definition distributor. The policy definition distributor is asked (step 2a) and then resend the encrypted policy to re ^¬ questor authentication (step 2b) . However, other options may be valid. For example the client trusted platform module can cache the policy.

In any case, the requestor authentication module has to be used for policy decryption (step 3) and for signing of the decision. This relaxes the trust constraints in the client trusted platform module, as we prevent the impersonation at ^¬ tack. In the signing process, appropriate method for preven ^¬ tion of replay attack should be used, such as timestamping, or use of a nonce. If the client trusted platform module is trusted to the extension we know the impersonation attack is impossible, the policy private key can be exposed to client trusted platform module and the communication complexity de- creased.

After the decision has been made, the client trusted platform module either directly informs the requestor about the deny decision (step 6. a) or sends the request for signing the re- quest identifier (possibly hash) and the decision with the policy private key and attestation key of the requestor au ^¬ thentication module (step 6.b), to which it gets the response (step 7) . Subsequently, in step 8 the client trusted platform module signs the received signature with its private attesta- tion key to witness the used Hard- and Software. Then the client trusted platform module sends both the request and signature to the resource server (step 9) . If the two trusted platform modules are merged, only a single signature with at ^¬ testation key is necessary.

The resource server receives the request and the signed deci ^¬ sion, and performs the verification. This may require the up ^¬ date of the knowledge of the currently valid policies (step 10 and step 11) . The update is invoked according to the re- source server's security policy that determines, whether re ^¬ source server needs to have all the time the freshest policy data, or whether e.g. certain refresh rate is sufficient.

Subsequently, the resource server verifies the attestation and policy signatures. This process is equivalent to the pro ^¬ cess to verify the valid policy and the valid authorization algorithm.

If verification was successful, the resource server sends the requested resource (step 13. a) back to the client, otherwise it sends the request for refreshment of policies (step 13. b) . Step 13. b can also contain the actual policy definition that is considered valid by the resource server, if the resource server possesses (or may simply get) this information.

The verifiable computing e.g., based on the homomorphic en- cryption is a different approach to ensuring the valid algo ^¬ rithm was used for policy evaluation. It enables to relax the security conditions put on the client. The verifiable compu ^¬ ting enables the relying party to trust the authorization de ^¬ cision, without the need of knowledge about the way the deci- sion was achieved. Moreover, the homomorphic encryption based verifiable computing does not disclose the information used in the computation, which brings yet another advantage. This way, the client actually does not need to be a trusted plat ^¬ form module and the attestation signature is exchanged for the verifiable computing assurance.

The following advantages may be achieved:

The resource owner and the requestor (including the trusted platform modules utilized) are the only ones that knows the relevant policies.

The resource server can verify that the correct policy and evaluation mechanism was used for computation of the deci- sion.

The resource server is aware of the requestor giving the con ^¬ sent to the use of the policy. The resource server does not know the identity of the reques ^¬ tor. More precisely, there is no way for the resource server to learn that identity from the data accessed by resource server e.g. policy verification data. The requestor knows the authorization decision and cannot be fooled by the resource server. The requestor performs an authentication with respect to the client .

If the blockchain-based implementation is used, it can be utilized together with the audit records of the requests for forensic purposes.

The requestor-relevant data, e.g., biometrics do not need to be sent to any third party for an authorization evaluation.

Even if resource server does not synchronize the current state of the policies stored in the policy verification dis ^¬ tributor, it can verify that the decision was valid at a given time in the past (which may be sufficient, e.g., if we know the policies may change only once a day) .

Depending on a use case, the communication complexity may de ^¬ crease. The client may avoid a request if the client knows that the authorization decision is deny. The communication of the resource server to the policy verification distributor can be switched from synchronous to asynchronous.

The computational effort is distributed between the reques ^¬ tors .

Example Embodiments

Use case: Wearable e.g. a smart watch

• requestor - athletic club trainer

· client and requestor authentication module - trainer' s smart device

policy registrator, policy verification distributor - public blockchain service

policy definition distributor - athletic club server resource owner - athletic club member

resource server - member' s smart phone

resource - smart watch The invention enables to cover the authorization decision method right from the moment the device was assembled, by as ^¬ signing it with a resource identifier res_id that is stored in the very device and unchangeable. The resource identifier res_id should be auto-generated and unknown for the vendor so as the customer who buys the device is the first one to know it, hence, being the only resource owner.

We further assume that the smart watch was bought by an ath ^¬ letic club member who synchronizes it with the member's smart phone. Because the watch is a quite simple device, the phone serves, next to other functions, as a resource server with respect to the watch. The bound between the resource and re ^¬ source server determines the security of the system. There ^¬ fore, at least some form of authentication of the resource server with respect to the resource should be in place. The member needs to give a trainer a permission to read her heartbeat, for which the watch have a sensor, but only during the training hours, and with high confidence it is the trainer who is downloading the data. The member uses a public blockchain service to register the policy verification data and the athletic club server to register the relevant policy definition data (as there is no need to store it in a more public storage) .

During the training, the trainer opens the app for seeing the team member heartbeats. The app learns the resource identi ^¬ fier res_id through a short-range communication means, and lets the client trusted platform module in the same device download the policies from the club server (for given re ^¬ source identifier res_id and requestor currently using the device - the trainer) . The client trusted platform module asks the trusted platform module of the requestor authentica- tion module on the same device to decrypt the policies and subsequently computes the decisions. If there is a device for which there is currently no permission given to the trainer, the action of reading for this device is immediately disap ^¬ proved without any communication with this device. With re ^¬ spect to the policies set for member's watch as a resource, the client trusted platform module checks, whether the time is in the interval of training hours and whether the identity requesting is truly the trainer. For example, it can communicate with the trusted platform module of the requestor au ^¬ thentication module which may enable the physical authentica ^¬ tion via fingerprint. Typically, on a single device the trusted platform modules of the client and the requestor au ^¬ thentication module may be a single trusted platform module, so that the communication is provided internally. If the pa ^¬ rameters are confirmed, the decision to permit is made and sent to the member's smart phone.

The smart phone uses a public service providing the data about the attestable hard- and software. The smart phone learns from these data and the signature of the decision, that it can trust the decision with some degree of confi- dence . If the confidence is enough for the resource server, it sends back the resource, in present case a stream of heartbeat data.

Use case: Smart home

· requestor - family member son

• client and requestor authentication module - mobile de ^¬ vice with trusted platform module

• resource server, policy registrator, policy verification distributor, policy definition distributor - smart home server

• resource owner - family member father

• resource - garage door

In this embodiment, there is a family member e.g. father hav- ing the rights to administer the access policies to all the smart home equipment. The administration may be done via a web-based administration tool. The policies are stored on the smart home server. The smart home server authorizes the poli ^¬ cies and serves as both policy verification distributor during the propagation of the data to all the endpoint devices (e.g., thermostat, garage door, etc.), and policy definition distributor during the propagation of the data to the requestors' clients. As in this environment the dynamicity of the policy changes is very low, the changes in the resource-spe ^¬ cific policies may infrequently be propagated to the devices, e.g., once a day .

Assuming that the son coming back home after spending a year abroad. The father uses the administration tool from his of ^¬ fice to set up the rights for the son to be able to open the garage door. The son returns the next day and wants to park his car. He uses his mobile phone with an application being able to communicate with the smart home network via a short- range communication means and try to open the door. The application finds out it has no policies for this action and contacts the server to download the policies. Subsequently, the authorization decision is computed and sent together with the request for opening to the server. The server verifies the decision according to the refreshed policies and opens the door. The requestor, i.e. the son is represented in the IT world by information (private keys) stored securely at the trusted platform module of his mobile device.

The son parks every day. The son's mobile device does not need to refresh the policies since the policies are still valid. One day, the son argues with his parents and is thrown out of the house. The father removes all son's access rights. The next day, when the son wants to park again, his mobile device evaluates the old policies and sends the request with the allow decision, but the server responds with invalid state and suggestion to refresh the policies. The mobile de ^¬ vice downloads the fresh policies and verifies the denial de ^¬ cision. This invention has been described with respect to exemplary embodiments. It is understood that changes can be made and equivalents can be substituted to adapt these disclosures to different materials and situations, while remaining with the scope of the invention. The invention is thus not limited to the particular examples that are disclosed, but encompasses all the embodiments that fall within the scope of the claims.