User Apps with Identifiers - Revision history

Tomjones: /* References */

2021-01-22T19:11:13Z

References

← Older revision		Revision as of 19:11, 22 January 2021
Line 54:		Line 54:

	==References==		==References==
	* A related problem is [		* A related problem is described in the [[Over 21 with Proof of Presence Use Case]].

	[[Category: Concept]]		[[Category: Concept]]
	[[Category: Identifier]]		[[Category: Identifier]]

Tomjones: /* References */

2021-01-22T19:10:10Z

References

← Older revision		Revision as of 19:10, 22 January 2021
Line 54:		Line 54:

	==References==		==References==
			* A related problem is [

	[[Category: Concept]]		[[Category: Concept]]
	[[Category: Identifier]]		[[Category: Identifier]]

Tomjones: /* Unsolved Problem */

2021-01-13T05:36:40Z

Unsolved Problem

← Older revision		Revision as of 05:36, 13 January 2021
Line 37:		Line 37:
	# TBD on how the user gets control back to the app that called it.		# TBD on how the user gets control back to the app that called it.
	# In OIDC the AuthN Request goes from the RP to the OP, presumably as a redirected HTTPS GET from the user agent, which is captured by the Web App. Since the packet was encrypted for the OP, how can the Web App decrypt the data?		# In OIDC the AuthN Request goes from the RP to the OP, presumably as a redirected HTTPS GET from the user agent, which is captured by the Web App. Since the packet was encrypted for the OP, how can the Web App decrypt the data?
			# A large number of solutions that will not all be accommodated in [[Relying Party]] web sites without some sort of discovery.

	===Hybrid App Solutions===		===Hybrid App Solutions===

Tomjones: /* Solutions */

2021-01-13T05:35:14Z

Solutions

← Older revision		Revision as of 05:35, 13 January 2021
Line 49:		Line 49:
	# The browser records all authentications as a part of existed password storage and know what to do the next time a web site asks for creds.		# The browser records all authentications as a part of existed password storage and know what to do the next time a web site asks for creds.
	# The credential manager (credman) enables credential control in the DOM.		# The credential manager (credman) enables credential control in the DOM.
			# First party manifests.
	# etc. etc. etc.		# etc. etc. etc.

Tomjones: /* Problems */

2021-01-13T05:33:09Z

Problems

← Older revision		Revision as of 05:33, 13 January 2021
Line 15:		Line 15:
	## Companies like Verizon that have web sites with different names like: aol.com and yahoo.com.		## Companies like Verizon that have web sites with different names like: aol.com and yahoo.com.
	## Companies like Amazon that operating in different parts of the world under different legal regimes like: amazon.com and amazon.co.uk.		## Companies like Amazon that operating in different parts of the world under different legal regimes like: amazon.com and amazon.co.uk.
			## Research and education consortia like Internet2 that have thousands of organizations and millions of users.

	Two major category of app are considered along with a hybrid that lies between the two.		Two major category of app are considered along with a hybrid that lies between the two.

Tomjones: /* Problems */

2021-01-13T05:31:53Z

Problems

← Older revision		Revision as of 05:31, 13 January 2021
Line 12:		Line 12:
	## the appropriate Authentication Assurance Level (AAL) aka proof of presence and control by the user.		## the appropriate Authentication Assurance Level (AAL) aka proof of presence and control by the user.
	## the appropriate Federation Assurance Level (FAL) aka follows the federation rule and regulations. (optional)		## the appropriate Federation Assurance Level (FAL) aka follows the federation rule and regulations. (optional)
			# The peculiarities of the existing browsers have been backed into multi-site federations that are being adversly affected by changes now working their way though the W3C process, including:
			## Companies like Verizon that have web sites with different names like: aol.com and yahoo.com.
			## Companies like Amazon that operating in different parts of the world under different legal regimes like: amazon.com and amazon.co.uk.

	Two major category of app are considered along with a hybrid that lies between the two.		Two major category of app are considered along with a hybrid that lies between the two.

Tomjones: /* Hybrid App Solutions */

2021-01-13T05:26:52Z

Hybrid App Solutions

← Older revision		Revision as of 05:26, 13 January 2021
Line 36:		Line 36:
	===Hybrid App Solutions===		===Hybrid App Solutions===
	* The app works with a website that can present information about user choices at all times.		* The app works with a website that can present information about user choices at all times.
	* For an example, in the ~~solid~~ project, a user stores personal data in "pods" (personal online data stores) hosted wherever the user desires.		* For an example, in the [https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) Solid project], a user stores personal data in "pods" (personal online data stores) hosted wherever the user desires.
	====Unsolved Problem====		====Unsolved Problem====
	# Who pays for hosting the PODS		# Who pays for hosting the PODS

Tomjones: /* Solutions */

2021-01-13T05:19:04Z

Solutions

← Older revision		Revision as of 05:19, 13 January 2021
Line 42:		Line 42:

	==Solutions==		==Solutions==
			Lots of solutions have been proposed to the problems listed above, but all of them require changes from the browsers.
			# The browser records all authentications as a part of existed password storage and know what to do the next time a web site asks for creds.
			# The credential manager (credman) enables credential control in the DOM.
			# etc. etc. etc.

	==References==		==References==

Tomjones: /* Web App Solutions */

2021-01-13T05:16:04Z

Web App Solutions

← Older revision		Revision as of 05:16, 13 January 2021
Line 28:		Line 28:
	* Also known as a Progressive Web App or PWA.		* Also known as a Progressive Web App or PWA.
	* The user on a web browser can click on a POST button provided by the RP. The POST is to the URL of the site that loaded the Web App service broker on the user's device. The browser can direct that POST to the Web App for processing. Eventually the Web App will respond to the user's browser with the AuthZ code (or token) for redirection as a GET to RP, which results in the response from the RP with a new page that puts the user back in control.		* The user on a web browser can click on a POST button provided by the RP. The POST is to the URL of the site that loaded the Web App service broker on the user's device. The browser can direct that POST to the Web App for processing. Eventually the Web App will respond to the user's browser with the AuthZ code (or token) for redirection as a GET to RP, which results in the response from the RP with a new page that puts the user back in control.
	* The app is only available when running on a smartphone, but the web address will respond if the if app is not running.		* The app is only available when running on a smartphone, but the web address will (should?) respond if the if app is not running.
	====Unsolved Problem====		====Unsolved Problem====
	# Each app has its own URL which corresponds to the site where it was loaded. The RP needs to know which app are loaded in order to redirect the request to the app for authentication.		# Each app has its own URL which corresponds to the site where it was loaded. The RP needs to know which app are loaded in order to redirect the request to the app for authentication.

Tomjones: /* Native App Solutions */

2021-01-13T05:13:54Z

Native App Solutions

← Older revision		Revision as of 05:13, 13 January 2021
Line 18:		Line 18:
	* The app is loaded from a trusted app store and has full access to the features of the device.		* The app is loaded from a trusted app store and has full access to the features of the device.
	* If the smart phone browser is available, (the assumption is that) it will be able to start the app.		* If the smart phone browser is available, (the assumption is that) it will be able to start the app.
			* The [[Relying Party]] web site will present options to the user with each one having a redirect URL. The special URL "openid://" is reserved to start a native app that can act as a SIOP - Self-issued OpenID Provider as described in section 7 of the OIDC specification.
	====Unsolved Problem====		====Unsolved Problem====
	# The redirection code (e.g. openid://) can be registered, or hijacked) by any app that the user downloads.		# The redirection code (e.g. openid://) can be registered, or hijacked) by any app that the user downloads.
	# The RP needs to enable the OpenID with one button (among many others) that redirects to the app for authentication.		# The RP needs to enable the OpenID with one button (among many others) that redirects to the app for authentication.
	# Once the app have been invoked it requires special code to return control to the user in the same context (browser tab.)		# Once the app have been invoked it requires special code to return control to the user in the same context (browser tab.)
	# The [[Relying Party]] web site will present options to the user with each one having a redirect URL. The special URL "openid://" is reserved to start a native app that can act as a SIOP - Self-issued OpenID Provider as described in section 7 of the OIDC specification.

	===Web App Solutions===		===Web App Solutions===