Resource Server: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 3: Line 3:


==Context==
==Context==
* Existing OAuth standards were created before attention was given to the fact that most of the data dispensed to clients was, in fact, [[Personal Information]]. This page will focus on the control of that data by the [[Subject]], even after the transfer has been completed.
* 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]].
* 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.
* The resource server will have a strong binding to the resource owner, called the [[Subject]] here.

Revision as of 22:35, 12 April 2020

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.

Context

  • Existing OAuth standards were created before attention was given to the fact that most of the data dispensed to clients was, in fact, Personal Information. This page will focus on the control of that data by the Subject, even after the transfer has been completed.
  • 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.
  • 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 Service 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 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.

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.

References