More on the privacy enhancement project (now PEOFIAMP)

When I wrote the previous post (US$1.5M project to bolster the privacy and security of the cyberspace), the English name of the project was not yet determined. Now we have one.

Privacy Enhancement for Open Federated Identity/Access Management Platforms (PEOFIAMP).

Here is some more details translated from Japanese research prospectus. (Note, this is only the OpenID Connect portion. There is a mirror of it exept 2-4 for SAML, which is led by Professor Nakamura as well.)

2) The research and development on the privacy respecting attribute federation over OpenID Connect

(R&D Topics)

2-1) Registration of Attribute Server to the Authorization Server

Once the user starts to use multiple attribute servers, the method for the user to easily select and register such servers on the authorization server (controller, or PDP, Policy Decision Point) becomes an issue. For example, if the user wants to hand his health information over to some medical services, he needs to be able to select and tell which personal medical record service he is using. This has to be very easy to do.

For this purpose, there has to be a user interface that make is easy for the user to select the appropriate server through the search with the term he understands. As the result, meta-data gets transferred from the attribute server to the authorization server, making it possible for the user consent at the PDP/Authorization Server to be implemented. This R&D project develops such server.

Similar initiative is underway at the UMA WG in Kantara Initiative. However, unlike the UMA WG that deals with both push and pull model, this R&D concentrates on Pull model making the implementation more light-weight.

2-2) Privacy Enhancement at the attribute servers

2-2-1) Avoidance of calling home problem through the user of aggregated claims model

The purpose of this research is to make it possible for the attribute federation to be done without telling the attribute providers where the user has provided the attributes. For example, in the real world, even if a student shows his student I.D. to a shop to receive the academic discount, the university would never know the fact. This research topic aims to achieve the same in the online use cases. This is sometime referred to as the avoidance of “calling home problem”.

This is achieved by not showing which service provider the attribute assertions are sent to the attribute servers when the attributes are transmitted based on the user authorization. Note that not all the service providers are eligible in receiving such attributes from the consumer protection point of view. The method to provide such consumer protection is a topic to be discussed under this research item. Having an attribute proxy that maintains the white list of the service provider is one way to solve it.

In OpenID Connect, there is a mode of operation at the authorization server called “aggregated claims mode”. When using this mode, the attributes/claims provided by the attribute servers are cached at the attribute provider service of the authorization server called “UserInfo Endpoint” effectively making it a privacy enhancing proxy.

2-2-2) Avoidance of individual attribute and rules disclosure through attribute computation at the proxy

Using such proxies, it also becomes possible to fulfill such requirement as a) the attribute server wants to hide the individual attribute values and b) the service provider may want to hide the authorization rules when it makes an authorization decision based on the attributes/claims provided,

For example, let us think of a hypothetical case of a company (a service provider) wants to provide a shortcut in the recruitment process for the student with a sum of English and Mathematics score over a certain limit. In such a case, if the “proxy” obtains the attributes from the attribute provider and computes the result that is sought by the service and provides it, it can be achieved.

2-2-3) Providing used counts by the entity through partially anonymous or multiply pseudonymous identities

When it comes to enhancing the privacy, using the service only through a partially anonymous or multiply pseudonymous (using multiple pseudonymous accounts) identities is a very powerful tool. This however causes an issue when a service’s nature is such that that each entities can receive the service only a limited number of times. Since the user is essentially anonymous (unlinkable), the service provider cannot build the necessary count. This hinder the service provider’s ability to provide such limited offers.

In this research project, we will explore the methods to build such counts.

2-3) Privacy protection against the proxy

Although the privacy enhancing proxy solves one problem, the calling home problem to the attribute providers, it yet causes another problem of a proxy essentially learning everything. In this sub-item, we will explore the methods to minimize this impact, i.e., avoidance of “proxy leaning too much problem.” This can be decomposed into two problems. “Problem of proxy learning too much about the user” and “Calling home problem to the proxy.”

2-3-1) Problem of proxy leaning too much

By encrypting the assertion by the key that the proxy does not have, it is possible to avoid proxy leaning what is being transmitted. However, using the key of the destination server would cause the attribute server learning where the attributes are being sent.

In this R&D project, a method to achieve encryption without revealing the identity of the destination is being explored.

2-3-2) Calling home problem to the proxy

The other problem that we have in the proxy model is that if the user uses a same proxy all the time, the proxy will have a very good idea of where the user is going even though it cannot look into what is being sent. This R&D project seeks to find a method to mitigate this issue as well.

2-4) Methods to provide similar capabilities to non-web systems

In the web servers, due to the exploding numbers of user credentials and the resulting security issues, so called “No Password” initiatives has been underway and becoming popular. However, other protocols like SMTP, IMAP etc. still finds common “username/password” model the prevailing model. Propegating the model found in the web to these protocols will improve the situation which is much affected by ID theft etc.

To this end, this project will develop a method and implementation to such protocols like SMTP and IMPA etc. to use the same access token model as in the case of Web.

 

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.