Authorization Server - Revision history

Tomjones: /* Healthcare */

2020-04-17T17:55:46Z

Healthcare

← Older revision		Revision as of 17:55, 17 April 2020
Line 22:		Line 22:
	See the wiki page [[Patient Consent]] for details on getting permission to issue a token for health recous. The following flows follows the pattern from [https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rs-rpt-response User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization] provides consent to the [[Authorization Server]] in order to capture [[Patient Consent]]. The the context of healthcare, a requesting party could be, for example, a physician in a large EHR making a request for patient data via that EHR. That interaction is viewed as internal and not subject to standardization in this presentation. The resulting token (here called RPT) is passed from one EHR (here called the client) to another EHR (here called the [[Resource Server]]). An alternate flow would allows the RPT to be passed to an Health Information Exchange (HIE), The entire HIE infrastructure would then be considered to be the [[Resource Server]]. From the [[Authorization Server]] perspective, it receives an RPT and produces an Access Token, which grants or denies access per the user intent.		See the wiki page [[Patient Consent]] for details on getting permission to issue a token for health recous. The following flows follows the pattern from [https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rs-rpt-response User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization] provides consent to the [[Authorization Server]] in order to capture [[Patient Consent]]. The the context of healthcare, a requesting party could be, for example, a physician in a large EHR making a request for patient data via that EHR. That interaction is viewed as internal and not subject to standardization in this presentation. The resulting token (here called RPT) is passed from one EHR (here called the client) to another EHR (here called the [[Resource Server]]). An alternate flow would allows the RPT to be passed to an Health Information Exchange (HIE), The entire HIE infrastructure would then be considered to be the [[Resource Server]]. From the [[Authorization Server]] perspective, it receives an RPT and produces an Access Token, which grants or denies access per the user intent.
	# Client Requests Resource Without Providing an Access Token with a list of requested access indicating which requests are essential - the proposed solution is for the [[Resource Server]] to verify that the client is a HIPAA covered entity in the quickest possible manner. The client MUST know the patient's record location code at the resource server.		# Client Requests Resource Without Providing an Access Token with a list of requested access indicating which requests are essential - the proposed solution is for the [[Resource Server]] to verify that the client is a HIPAA covered entity in the quickest possible manner. The client MUST know the patient's record location code at the resource server.
	# Resource Server Responds to Client's Tokenless Access Attempt - with a list of its capability to respond to the to client's requests in a manner that the user can comprehend and that it can fulfill. ~~The URL~~ of the [[Authorization Server]] must be included.		# Resource Server Responds to Client's Tokenless Access Attempt - with a list of its capability to respond to the to client's requests in a manner that the user can comprehend and that it can fulfill. Some means of accessing the [[Authorization Server]] must be included.
	# Client generates a requesting party token (RPT) that gives the patient all of the information needed to make choice to consent, such as provider, purpose, etc.		# Client generates a requesting party token (RPT) that gives the patient all of the information needed to make choice to consent, such as provider, purpose, etc.
	# Client Requests Resource with the requesting party token (RPT) - this request is bound to the client by a JWS signed token		# Client Requests Resource with the requesting party token (RPT) - this request is bound to the client by a JWS signed token

Tomjones: /* Other Material */

2020-04-17T16:42:46Z

Other Material

← Older revision		Revision as of 16:42, 17 April 2020
Line 31:		Line 31:
	* D. Hardt, ''The OAuth 2.0 Authorization Framework'' IETF 6749 https://www.rfc-editor.org/rfc/pdfrfc/rfc6749.txt.pdf		* D. Hardt, ''The OAuth 2.0 Authorization Framework'' IETF 6749 https://www.rfc-editor.org/rfc/pdfrfc/rfc6749.txt.pdf

	~~===Other Material===~~
			[[Category:Authorization]]

Tomjones: /* Context */

2020-04-17T16:39:38Z

Context

← Older revision		Revision as of 16:39, 17 April 2020
Line 5:		Line 5:
	* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.		* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].
			* The physical and logical location of the [[Authorization Server]] is deliberately left open to allow for a wide range of solutions, including self-issued identifiers.
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian. Often abbreviated as the user.		* Resource owner or agent, for example a healthcare patient or a guardian. Often abbreviated as the user.

Tomjones: /* Context */

2020-04-17T16:36:18Z

Context

← Older revision		Revision as of 16:36, 17 April 2020
Line 6:		Line 6:
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian. Often ~~abreviated~~ as the user.		* Resource owner or agent, for example a healthcare patient or a guardian. Often abbreviated as the user.
	* Requesting party - some person or service that wants access to user data.		* Requesting party - some person or service that wants access to user data.
	* Client - code that makes the request for user data, for example a physician requests patient data via an EHR. The fiction here is that this code acts as the user's client.		* Client - code that makes the request for user data, for example a physician requests patient data via an EHR. The fiction here is that this code acts as the user's client.
	* [[Resource Server]] - the endpoint where the client asks for access to the user data, this could very well be a large infrastructure, or just a request to a user's smartphone.		* [[Resource Server]] - the endpoint where the client asks for access to the user data, this could very well be a large infrastructure, or just a request to a user's smartphone.
	* [[Authorization Server]] - the endpoint where the request for user data arrives and the access token is generated.		* [[Authorization Server]] - the endpoint where the request for user data arrives and the access token is generated. It will also handle refresh requests so long as the user allows it.

	==Problems==		==Problems==

Tomjones: /* Actors */

2020-04-17T16:32:45Z

Actors

← Older revision		Revision as of 16:32, 17 April 2020
Line 6:		Line 6:
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian.		* Resource owner or agent, for example a healthcare patient or a guardian. Often abreviated as the user.
	* Requesting party - some person or service that wants access to user data.		* Requesting party - some person or service that wants access to user data.
	* Client - code that makes the request for user data, for example a physician requests patient data via an EHR. The fiction here is that this code acts as the user's client.		* Client - code that makes the request for user data, for example a physician requests patient data via an EHR. The fiction here is that this code acts as the user's client.

Tomjones: /* Context */

2020-04-17T16:30:41Z

Context

← Older revision		Revision as of 16:30, 17 April 2020
Line 4:		Line 4:
	==Context==		==Context==
	* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.		* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party ~~request~~ into a grant that matches the internal structure of user data held by the [[Resource Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party token into a grant that matches the internal structure of user data held by the [[Resource Server]].
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian.		* Resource owner or agent, for example a healthcare patient or a guardian.

Tomjones: /* Context */

2020-04-17T16:29:47Z

Context

← Older revision		Revision as of 16:29, 17 April 2020
Line 4:		Line 4:
	==Context==		==Context==
	* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.		* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party request into ~~the~~ a grant that matches the internal structure of user data held by the [[Resource Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party request into a grant that matches the internal structure of user data held by the [[Resource Server]].
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian.		* Resource owner or agent, for example a healthcare patient or a guardian.

Tomjones: /* Context */

2020-04-17T16:28:51Z

Context

← Older revision		Revision as of 16:28, 17 April 2020
Line 4:		Line 4:
	==Context==		==Context==
	* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.		* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user.		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user. Note, however, that the [[Resource Server]] may actually participate in converting the requesting party request into the a grant that matches the internal structure of user data held by the [[Resource Server]].
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian.		* Resource owner or agent, for example a healthcare patient or a guardian.

Tomjones: /* Context */

2020-04-17T16:26:48Z

Context

← Older revision		Revision as of 16:26, 17 April 2020
Line 4:		Line 4:
	==Context==		==Context==
	* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.		* The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an [[Authorization Server]] is just the source of the tokens that are sent to the [[Resource Server]] to give it the authority it needs to provide access to the protected asset.
	* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]].		* For the purposes of Identity Management this wiki will focus on the use of the [[Authorization Server]] as the source of a digital version of user consent that is understood by both the requesting party and the user.
	===Actors===		===Actors===
	* Resource owner or agent, for example a healthcare patient or a guardian.		* Resource owner or agent, for example a healthcare patient or a guardian.

Tomjones: /* Problems */

2020-04-17T16:22:12Z

Problems

← Older revision		Revision as of 16:22, 17 April 2020
Line 13:		Line 13:

	==Problems==		==Problems==
	* There are a wide range of attacks on the web to try to illegitimately acquire access to protected resources. Nearly all of the complexity associated with an [[Authorization Server]] protocol is to mitigate those threats.		* There are a wide range of attacks on the web to try to illegitimately acquire access to protected resources. Nearly all of the complexity associated with an [[Authorization Server]] protocol is to mitigate those threats while maintaining user control of their own data.

	==Solutions==		==Solutions==