Resource Server

Full Title or Meme

In the context of Identity Management a Resource Server will be a web based server that contains data whose release is controlled by a Subject.

Goal of this Document

This document is designed to put the terms used in IETF standards for Authorization protocols in terms that apply to the maintenance of user's private data, especially data held in sensitive industries like health and finance.

Context

• In the most common case of interest, the Subject will be a natural person that controls access to data that might belong to that person, or be considered to the Personal Information pertaining to that Subject.
• The resource server will have a strong binding to the resource owner, called the Subject here.
• Existing OAuth standards were created before attention was given to the fact that most of the data dispensed to clients was, in fact, [[IDEF Glossary PERSONAL INFORMATION|Personal Information]. This page will focus on the control of that data by the Subject, even after the transfer has been completed.
• The resource server will be covered by one one more privacy regulations which will be established by the jurisdiction of the subject.
• There will exist a record locator identifier associated with the Subject's information on the Resource Server.
• Any resource consumer can request information from from theResource Server using an Authorization from an Authorization Server that has received Consent from the Subject.
• An Identifier Provider will provide authentication of the Subject's ownership of the data indicated by the record locator.
• Since the Subject's [[IDEF Glossary PERSONAL INFORMATION|Personal Information] will wind up on the client, a similarly purposed record locator will be established with the client so that it could be controlled by the Subject and subsequently provided to some subsequent Trusted Third Party. In that case the client will become the Resource Server.

Problems

• In order to provide resource consumers with access to restricted resources, the resource owner provider some sort of credential to the resource consumer (aka the owner's client).
• Since the credential provided to the client will transit the public web, it must be protected ins some manner that will prove to the Resource Server with proof of the Subject's Consent and that the client presenting the credential was exactly the one intended by the Subject to receive the information.
• The current assumption that a client can ask for user data without strongly identifying itself to the subject will eventually lead to the subject losing control of their [[IDEF Glossary PERSONAL INFORMATION|Personal Information] if data ever winds up on a server that is not operating under a trust framework where the user data is protected.

Solutions

• The solution presented here is one described in OAuth 2.0 and expanded in anticipation of more robust protocols to come from the IETF.
• The Identifier Provider purpose is authentication of the Subject. In the case of self-issued identifiers, that function could equally well be on the Subject's device or in the cloud. Either should work equally well.
• Similarly the Authorization Server can be in the cloud, associated with the Resource Server or in the Subject's device without impacting the protocol in any way.
• From the point of view of the subject where [[IDEF Glossary PERSONAL INFORMATION|Personal Information] is transfered from the Resource Server to some server acting as client, then there will be no difference after the transfer as the client could be the Resource Server in another transaction with another server, which would then also appear as a Resource Server to the Subject at a minimum with respect to access of data on that server by the Subject.
• Before any data is transferred to a client, that client must prove that it is operating under regulation that will protect the Subject's information.

Special Consideration for Healthcare

• The use case of the data flowing from the primary EHR to the user and then to the referred EHR is described in the wiki page Patient Choice. There is a diagram of the data flows for patient-in-control on the wiki page Trustworthy Healthcare Ecosystem. This page is primarily focused on the back channel access of PHI (what is call code flow in OpenID specs).
• In the case of any server operation with protect health information,all servers must be registered as certified to protect healthcare data in the jurisdiction of the patient. This registration must be freely available for query by the patient's device prior to the transfer of any data.
• Both the Resource Server and client will be considered to contain an Electronic Health Record that is subject to the rules of the local jurisdiction.

The following diagram shows the transfer of protected health information (PHI) in a back channel flow of data from one EHR (the Resource Server) to another (the client). Here the affinity of the IdP and AP (Authorization Provider) is not shown as they can be in a separate server, part of the patient's agent on a smart phone or in the HIE (Health Information Exchange) cloud. The Identity and Access Management (IAM) flows are shown in simplified form in red dashed lines. They are considered to typically occur between the request for access from the client until access is granted by the Resource Server.

Special Consideration for Finance

• All parties to a financial transaction must tracked by the authorities in the jurisdiction where anti-money laundering regulations apply.