Consent to Create Binding

Full Title

The definition of a message to carry initial consent and a method for notification from a subject to any digital Service Provider.

Goals

• The high level goal is the establishment and maintenance of a relationship (binding) between the subject and one organization.
• The immediate goal is for the subject to receive a consent receipt and authorization 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).
• The long term goal is that no service provider would be permitted to retain any user information without first receiving a signed consent form like the included.

Scope

• This specification applies only to service providers that have determined that they need to acquire explicit consent from individuals.
• It is just the first interaction to create user context within the larger user experience of Consent Management of the user with some digital entity. (See also Vendor Relationship Management).
• The term service provider as used here is nearly equivalent to the website term used through out this wiki.

Status

• This page is a work in process towards a work item proposal.
• The Kantara Distributed Assurance Specification is a draft proposed specification that includes a consent to create a binding with a Credential Service Provider.

Justification

1. User consent only matters where there is an ongoing relationship between two entities.
   1. Ongoing could be only for the duration of a session, but all current IDEF profiles use cases are longer than that.
   2. The penultimate relationship in the digital age is between a user's agent and a web site - that is the one addressed in all current IDEF profiles.
2. Before the user user (via their agent) consents to sharing, the web site MUST display credentials of its own so the user can understand the identity of it (in the full meaning of identity)
   1. this is a brand relationship (as opposed to a legal entity identity) for all of the users that are targeted by IDEF profiles.
3. Consent to Create Binding (registration of a user) is required before meaningful consent can be given, because it is only after registration that the user can expect to receive notification from the web site.
   1. Governmental legal notices could side step this requirement, but that is really ineffectual from a user's perspective.
4. The first and mandatory consent granted by the user during registration is some sort of (1) identifier (2) authentication method and (3) email or sms phone number. (these could all be pseudonymous).
   1. Often other claims are requested by the web site during registration, these other claims should be in accord with legal regulations.
5. Once a relationship is established other claims can be requested by the web site, and optionally granted by the user via the agent. It is this stage that most other specifications address.
   1. claims MUST be user directed rather than legal directed, which seems to be consonant with the spirit of the GDPR and other privacy regulations that discuss usability.

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

• The NIST 800-63-3 document site
• Levels of assurance from NIST 800-63-3 are described here

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

• Remote Attestation Use Case shows the steps that a user can follow to use the Phone as Health Care Credential with a NIST AAL2 (authentication assurance level 2).

Life-cycle

• The question here is how long the user information will be retained in the database of the recipient. For example, biometric data might be acquired from the user for identity proofing, but not retained for use on subsequent transactions.

1. User Data acquired from the user.
2. User Data retained after the transaction is complete.

• There are several time scopes that might be of interest. Note that based on the purpose (aka context) different user attributes will be retained for different time frames.

1. Session based - data is not retained after the the HTTPS session is terminated.
2. Cookie based - data is not retained by the recipient, but it is included on the user's device and will be returned to the recipient if the user reconnects.
3. Transaction based - data is retained until the transaction is complete. This can be short or long-term depending on the life of the transactions. For example, a 2-year warrantee would require some data to be retained for 2 years.
4. Relationship based - data is retained until the user terminates the relationship.
5. Legal based - data is retained as long as the law determines.

Solution

This particular use case relates to the interchange between the subject and a trust authority. A similar interchange would be used between the subject and a relying party.

Registration Ceremony

• A part of establishing an enduring relationship between two entities on the web requires that each be known to the other is some meaningful sense. In the case of the service provider, there are multiple solutions which started with HTTPS and are currently undergoing a process of improvement. In the case of the user the needs for identification and authentication proofing vary substantially based on the context. One of the level two assurancances is defined in the companion Distribute Assurance Specification.
• At the end of the registration ceremony it is expected that a notification channel will be open from the service provider to the user to meet the requirements of the GDPR or CCPR.
• In general registration will require the ability to notify the user of changes, breaches, etc. That capability requires information from the user which is supplied in a Consent to Create Binding.
• Typically a service provider will request additional information from the user for its own purposes. That should not be confused with the necessity for a notification binding as is described below.

Consent to Create Binding Request

The following is the current understanding of what needs to be included in a Consent for Binding Request. This set of requirements can be met by the format of the OpenID Connect 1.0 id_token. The security considerations might be somewhat different than that spec. Also the id_token is viewed as the final step of an authentication interchange; while this message includes a request for a response from the target.

1. Identifier of the message

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

2. Issuer (aka Organization or Audience)

   MANDATORY - URI OF the CSP (Audience of the request). This would be the entity that supplies a public key when encryption is required. Rather oddly, the issuer is the target of the message. That could be made less confusing.

3. Subject (aka Grantor)

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

4. Subject Role

   MANDATORY - this is the relationship between the subject and the owner of the information (e.g. patient). Typically will be self or guardian.

5. Context (aka trust_framework, may be multiple)

   MANDATORY - The trust authority that establishes the context.

6. Subject Attributes (aka Claims about Contact and other information)

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

7. Grants

   MANDATORY - applies to above subject information. This is purely opt-in. No reference denotes no consent. Note that the attributes granted may be part of this message or may be included by reference with an Authorization Code for access.

8. Device Statement

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

9. Identity Proof

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

10. Purpose of Use (aka reason)

    MANDATORY for any level of assurance greater than level one in any of the 3 categories of assurance.

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

12. Issue Date

    MANDATORY - Linux epoch date is default

13. Expiration Date

    OPTIONAL - Linux epoch date is default

14. Subject Public Key

    MANDATORY - must be included directly or by reference.

15. Signature

    MANDATORY - using the above key.

16. Encryption

    MANDATORY - but it can be provided by HTTPS - Note that the above items are all a part of the JWS - or signed JWT. Encryption exists above this JWS content and may include multiple JWT elements in a JSON object.

Consent Receipt with Binding

The Binding can consist of any sort of authorization or certificate that shows that binding of the user to the resources has been created or reconfirmed.

• n.b. The US Health care proposal has decided to separate the binding and consent receipt into two separate JWT/JWS signed jose documents that could be combined into a single JWT/JWE jose envelope for encryption.

1. Binding Statement (aka Consent Receipt or Entity Statement)

   Response to the REQUEST - this is the name, version or identity for message returned by the issuer 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 issuer.

2. Issuer (of this receipt aka Organization)

   MANDATORY This the entity that the subject is forming a binding with. It may be a brand name rather that a legal name.

3. Role of Issuer

   MANDATORY - this is the role(s) that the issuer takes. (eg CSP, Identifier Provider, Data Controller)

4. Legal Name

   OPTIONAL - this may be included if the Issuer is not a legal entity. It is required that a legal entity be responsible for the receipt.

5. Subject

   MANDATORY - this is the identifier supplied by the user. This receipt is bound to this identifier.

6. Claims

   OPTIONAL - this will be either the categories of claims granted, or the claims themselves.

7. Issue Date

   MANDATORY - Linux epoch date is default

8. Expiration Date

   OPTIONAL - Linux epoch date is default

9. Authority Hints

   OPTIONAL - List of federation authorities subscribed to by this issuer

10. Issuer's Public Key

    MANDATORY - must be included directly or by reference.

11. Signature

    MANDATORY - using the above key.

12. Encryption

    MANDATORY??? - using the Subject's key.

Appendix

There are others creating a similar result.

• Session ID
• Peer DID for a Decentralized Identifier Method.

References

• List of CSR contents. (X.509v3 Certificate Signing Request) which, unlike this consent, is not signed by the user (aka key owner).
• The Trustworthy Healthcare Ecosystem puts the CSP into context with the other components of the ecosystem.\
• IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1) Integration Profiles See Section 13.4 XUA Actors/Transactions and following for terms needed in SAML.