Consent to Create Binding

From IDESG Wiki
Revision as of 21:24, 15 October 2019 by Tomjones (talk | contribs) (→‎Solution)
Jump to navigation Jump to search

Full Title

The definition of a message to carry consent from a subject to a Credential Service Provider.

Goals

  • The goal is for the subject to receive a certificate in response to this message which meets the security requirements of the intended purpose.
  • Ensure solid binding to a secured user's key by requiring user to have private components of the key well secured before this message is created.
  • For healthcare the intended purpose is to bind the subject to the identity proofing document (IAL2) and validate the user agent as being in compliance with any health care regulation or code of conduct (AAL2).

Status

This page is a work in process towards a work item proposal.

Context

In an environment where a subject is requesting the establishment of a binding between it's private key and a Provider of any identifier services, the implicit assumption has been that the action of the subject on the website is sufficient. In today's world of gathering a subject's most private information some better means of capturing subject consent is urgently needed.

Note that the first use case for this message was in the Health Care Profile.

Existing Methods

  1. While it is true that methods exist for individual subjects to acquire a certificate for signing emails and receiving encrypted email, the adoption of that method outside of th enterprise is essentially failed and will not be considered as a paradigm for this effort.
  2. The most common request today is for an SSL or EV certificate from a Certificate Authority (CA) which works reasonably well for what it is intended to do. While it is possible to set up a CA of your own, we will address the more common case of a CA that has been approved by the major browser vendors. Before the process begins the user selects a Distinguished Name for the site based on the rules established by the CA/B forum.
  3. A CSR is an encoded file that provides you with a standardized way to send the Certificate Authority your public key as well as some information that identifies your company and domain name. When you generate a CSR, most server software asks for the following information: common name (e.g., www.example.com), organization name and location (country, state/province, city/town), key type (typically RSA), and key size (2048-bit minimum).

NIST levels of Assurance

External Definitions used here

  • Credential Service Provider (NIST) = A trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers. A CSP may be an independent third party or issue credentials for its own use. While the CSP is expected to assure the identity of the subject, this page assumes that the identity proofing occurs in a separate service. In these respects the CSP is simply viewed as a function with the physical realization and co-location of services being entirely up to the implementation.

Problems

  • Exploits against highly sensitive or valuable content on the web. (aka ex-filtration of valuable content hosted on a web server.)

Use Cases

Solution

The following is the current understanding of what needs to be included in a Consent for Binding Request.

Identifier of the message

Protocol dependent - may have message identifier, version number, unique sequence number or nonce

Subject

MANDITORY - this is the identifier from the user that will be the subject of the binding. It serves nearly the same purpose as the the DN of the X.509 certificate. Whether this subject identifier is to be bound to a real world entity (like a human being) is to be determined by the purposes to which the resulting entity statement will be put.

Subject Role

MANDITORY - this is the relationship between the subject and the patient. Typically will be self or guradian.

Subject Contact and other information

OPTIONAL - although a contact email or mobile number might be a requirement during registration for notices.

Issuer (or is it Audience)

MANDITORY - URi OF the CSP (Audience of the request).

Consents

MANDITORY - applies to above subject information. This is purely opt-in. No reference denotes no consent.

Device Statement

MANDITORY for AAL2 and higher certifications. It is used by the CSP to verify the level of protection provided to the Private key of the certificate.

Identity Proof

MANDITORY - although this request might pass responsibility for proofing to the CSP if it is willing and able to provide proofing for the subject. The content of the proof might need to meet specific requirements in IAL2 and higher assurance credentials. This is an array so that more than one proofing document may be included. Note that the legal jurisdiction or address of the subject identifier may be part of this structure. Note that a request for proof that the user is not a robot (CAPTCHA or equal) would fall into this category. None would be an acceptable value for the element.

Purpose of Use

MANDATORY for any level of assurance greater than level one in any of the 3 categories of assurance. (aka reason)

ACR

OPTIONAL - this is only useful in the case where the Purpose is not adequate to establish the required levels of assurance of the resulting Entity Statement.

Issue Date

MANDITORY - Linux epoch date is default

Expiration Date

OPTIONAL - Linux epoch date is default

Subject Public Key

MANDITORY - must be included directly or by reference.

Signature

MANDITORY - using the above key.

Encryption

MANDITORY??? - using the CSP key.

Entity Statement

NOT PART OF REQUEST - this is the message returned by the CSP after the process has been completed. It is then made available to any legitimate request. It is signed by a well-known key belonging the the CSP.

References

Retrieved from "https://wiki.idesg.org/index.php?title=Consent_to_Create_Binding&oldid=13592"