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.

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

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