Secure Sharing of High Integrity Documents - Revision history

Tomjones: /* References */

2021-02-18T22:57:40Z

References

← Older revision		Revision as of 22:57, 18 February 2021
Line 43:		Line 43:
	[[Category:Privacy]]		[[Category:Privacy]]
	[[Category:Integrity]]		[[Category:Integrity]]
	~~[[Category:Confidentiality]]~~

Tomjones: /* Solution */

2020-03-01T02:22:48Z

Solution

← Older revision		Revision as of 02:22, 1 March 2020
Line 36:		Line 36:
	# composite messages consisting of headers, plain text data and signed JWS blobs.		# composite messages consisting of headers, plain text data and signed JWS blobs.
	# encryption of the composite message for one or more destinations (aka audiences).		# encryption of the composite message for one or more destinations (aka audiences).
	Note that the last piece could be provided by HTTPS, but that would not solve the problem of multiple signature sources or multiple destinations. In the development of this solution we will focus on the use of application level encryption as there is ~~not~~ reason to describe HTTPS encryption as it is in wide use already.		Note that the last piece could be provided by HTTPS, but that would not solve the problem of multiple signature sources or multiple destinations. In the development of this solution we will focus on the use of application level encryption as there is no reason to describe HTTPS encryption as it is in wide use already.

	==References==		==References==

Tomjones: /* Solution */

2020-03-01T02:22:09Z

Solution

← Older revision		Revision as of 02:22, 1 March 2020
Line 36:		Line 36:
	# composite messages consisting of headers, plain text data and signed JWS blobs.		# composite messages consisting of headers, plain text data and signed JWS blobs.
	# encryption of the composite message for one or more destinations (aka audiences).		# encryption of the composite message for one or more destinations (aka audiences).
	Note that the last piece could be provided by HTTPS, but that would not solve the problem of multiple ~~signatures~~ or multiple destinations. In the development of this solution we will focus on the use of application level encryption as there is not reason to describe HTTPS encryption as it is in wide use already.		Note that the last piece could be provided by HTTPS, but that would not solve the problem of multiple signature sources or multiple destinations. In the development of this solution we will focus on the use of application level encryption as there is not reason to describe HTTPS encryption as it is in wide use already.

	==References==		==References==

Tomjones: /* Solution */

2020-03-01T02:21:33Z

Solution

← Older revision		Revision as of 02:21, 1 March 2020
Line 36:		Line 36:
	# composite messages consisting of headers, plain text data and signed JWS blobs.		# composite messages consisting of headers, plain text data and signed JWS blobs.
	# encryption of the composite message for one or more destinations (aka audiences).		# encryption of the composite message for one or more destinations (aka audiences).
			Note that the last piece could be provided by HTTPS, but that would not solve the problem of multiple signatures or multiple destinations. In the development of this solution we will focus on the use of application level encryption as there is not reason to describe HTTPS encryption as it is in wide use already.

	==References==		==References==

Tomjones: /* Problems */

2020-02-29T23:36:56Z

Problems

← Older revision		Revision as of 23:36, 29 February 2020
Line 25:		Line 25:
	# A single naming authority, the DNS to create unique addresses.		# A single naming authority, the DNS to create unique addresses.
	# A single method to securely identify the sites at these addresses, PKI with HTTPS,		# A single method to securely identify the sites at these addresses, PKI with HTTPS,
	# Simple messages that is protected as a single whole for both encryption and signing.		# Simple messages that are protected as a single whole for both encryption and signing.
	FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.		FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.
	*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.		*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.

Tomjones: /* Use Case, Consent with Assurance */

2020-02-29T23:34:43Z

Use Case, Consent with Assurance

← Older revision		Revision as of 23:34, 29 February 2020
Line 15:		Line 15:
	## acquire and use (for a limited time and limited scope) private, sensitive information.		## acquire and use (for a limited time and limited scope) private, sensitive information.
	# Modify or remote any previously granted consent.		# Modify or remote any previously granted consent.
			# Be single enough for anyone with a smartphone and an 8th grade education can succeed.

	==Problems==		==Problems==

Tomjones: /* Use Case, Consent with Assurance */

2020-02-29T23:33:41Z

Use Case, Consent with Assurance

← Older revision		Revision as of 23:33, 29 February 2020
Line 11:		Line 11:
	# All sites that maintain the user's private, sensitive information are required to keep the information private.		# All sites that maintain the user's private, sensitive information are required to keep the information private.
	# The cost for any web site found disclosing user private information is too high for it to risk.		# The cost for any web site found disclosing user private information is too high for it to risk.
			# The user can grant consent for any site to:
			## register the user and the notification back channel.
			## acquire and use (for a limited time and limited scope) private, sensitive information.
			# Modify or remote any previously granted consent.

	==Problems==		==Problems==

Tomjones: /* Solution */

2020-02-29T23:30:14Z

Solution

← Older revision		Revision as of 23:30, 29 February 2020
Line 26:		Line 26:

	==Solution==		==Solution==
			The solution described here works to allow messages that are:
			# based on json syntax
			# allow signed blobs in JWS format
			# composite messages consisting of headers, plain text data and signed JWS blobs.
			# encryption of the composite message for one or more destinations (aka audiences).

	==References==		==References==

Tomjones: /* Problems */

2020-02-29T23:27:18Z

Problems

← Older revision		Revision as of 23:27, 29 February 2020
Line 19:		Line 19:
	# A single authenticator of the user identity		# A single authenticator of the user identity
	# A single naming authority, the DNS to create unique addresses.		# A single naming authority, the DNS to create unique addresses.
	# A single method to securely identify the sites at these addresses, PKI with HTTPS.		# A single method to securely identify the sites at these addresses, PKI with HTTPS,
			# Simple messages that is protected as a single whole for both encryption and signing.
	FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.		FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.
	*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.		*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.

Tomjones: /* Problems */

2020-02-29T23:25:50Z

Problems

← Older revision		Revision as of 23:25, 29 February 2020
Line 22:		Line 22:
	FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.		FIDO and Web Authentication have extended this by inserting a separate step where the data requester asks for additional assurance from the user in a separate interchange.
	*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.		*While the above limitations will likely continue to apply to a very large number of Web interchanges, more and more interchanges require richer message structures. This document only addresses these richer information environments.
			*While user's all want to keep their private, sensitive information private, they are simply not capable of doing so with out simple to use secure tools.

	==Solution==		==Solution==