Resource Server: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 5: Line 5:
* 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.
* 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.
* The resource server will be covered by one one more privacy regulations which will be established by the jurisdiction of the subject.
* The resource server will be covered by one one more privacy regulations which will be established by the jurisdiction of the subject.
* 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.
* There will exist a record locator identifier associated with the [[Subject]]'s information on the [[Resource Server]].
* 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 the[[Resource Server]] using an [[Authorization]] from an [[Authorization Service]] that has received [[Consent]] from the [[Subject]].
* Any resource consumer can request information from from the[[Resource Server]] using an [[Authorization]] from an [[Authorization Service]] that has received [[Consent]] from the [[Subject]].

Revision as of 02:44, 13 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

  • 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, 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 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.
  • 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 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.

References