Secure Sharing of High Integrity Documents

Full Title

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.

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.

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.

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.