Secure Sharing of High Integrity Documents

Introduction

When documents from multiple sources are sent in response to a request, some means must be established to set the context of the documents so that the receiving process can determine how to process every element of the transmission as well as the consent of all parties to the sharing of private data.

Context

Existing authentication and access management functions are focused using

Use Case, Consent with Assurance

Consider the case of a user attempting to establish a connection with a site that they have never been registered that requires both consent of the user to store their personal data plus assurance of either the identity (IAL2) or authentication (AAL2) of the resulting connection. While it has been possible to do this using separate messages, the user experience requires separate actions by the user. The proposed solution for this is the following:

1. The user establishes an identifier, possibly with some attributes, like email or phone, that will authenticate an interchange session.
2. The user acquires some hardware device that can keep the user's credentials secure from attack.
3. The user agrees to share some private, sensitive information from a resource service to a new partner web site.
4. All sites that maintain the user's private, sensitive information are required to keep the information private.
5. The cost for any web site found disclosing user private information is too high for it to risk.
6. The user can grant consent for any site to:
   1. register the user and the notification back channel.
   2. acquire and use (for a limited time and limited scope) private, sensitive information.
7. Modify or remote any previously granted consent.
8. Be single enough for anyone with a smartphone and an 8th grade education can succeed.

Problems

OAuth 2.0 and OpenID Connect 1.0 have worked very well by focusing on the following limitations:

1. A single subject
2. A single source of data
3. A single requester of that data.
4. A single authenticator of the user identity
5. A single naming authority, the DNS to create unique addresses.
6. A single method to securely identify the sites at these addresses, PKI with HTTPS,
7. 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.

• 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

The solution described here works to allow messages that are:

1. based on json syntax
2. allow signed blobs in JWS format
3. composite messages consisting of headers, plain text data and signed JWS blobs.
4. 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 no reason to describe HTTPS encryption as it is in wide use already.