Consent to Create Binding - Revision history

Tom: /* Registration Ceremony */

2025-09-30T21:55:23Z

‎Registration Ceremony

Tom: /* Justification */

2025-09-30T21:53:03Z

‎Justification

Tom: /* Consent to Create Binding Request */

2023-05-26T22:41:50Z

‎Consent to Create Binding Request

Tom: /* Justification */

2023-04-27T17:54:10Z

‎Justification

Tom: /* Scope */

2023-04-27T17:52:08Z

‎Scope

Tom: /* References */

2022-02-01T22:56:14Z

‎References

Tom: /* References */

2022-02-01T22:41:31Z

‎References

Tom: /* Lifecycle */

2021-12-20T17:43:14Z

‎Lifecycle

Tom: /* Lifecycle */

2021-12-20T17:41:30Z

‎Lifecycle

Tom: /* Life-cycle */

2021-12-20T17:41:13Z

‎Life-cycle

@@ Line 68: / Line 68: @@
 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 [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations Distribute Assurance Specification].
+* A part of establishing a relationship over some time 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 assurances is defined in the companion [https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations 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]].

@@ Line 24: / Line 24: @@
 ## Ongoing could be only for the duration of a session, but all current IDEF profiles use cases are longer than that.
 ## 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.
-# 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)
+# Before the 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)
 ##  this is a brand relationship (as opposed to a legal entity identity) for all of the users that are targeted by IDEF profiles.
 # [[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]].

@@ Line 83: / Line 83: @@
 #Grants<blockquote>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.</blockquote>
 #Device Statement<blockquote>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.</blockquote>
-#Identity Proof<blockquote>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.</blockquote>
+#Identity Proof<blockquote>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.</blockquote>
 #Purpose of Use (aka reason)<blockquote>MANDATORY for any level of assurance greater than level one in any of the 3 categories of assurance.</blockquote>
 #ACR<blockquote>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. </blockquote>

@@ Line 23: / Line 23: @@
 # User consent only matters where there is an ongoing relationship between two entities.
 ## Ongoing could be only for the duration of a session, but all current IDEF profiles use cases are longer than that.
-## 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.
+## 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.
-# 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)
+# 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)
 ##  this is a brand relationship (as opposed to a legal entity identity) for all of the users that are targeted by IDEF profiles.
-# [[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.
+# [[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]].
 ## Governmental  legal notices could side step this requirement, but that is really ineffectual from a user's perspective.
 # 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).
-## Often other claims are requested by the web site during registration, these other claims should be in accord with legal regulations.
+## Often other claims are requested by the [[Web Site]] during registration, these other claims should be in accord with legal regulations.
-# 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.
+# 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.
 ## 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.

@@ Line 13: / Line 13: @@
 * 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 Manager|Vendor Relationship Management]]).
-* The term service provider as used here is nearly equivalent to the website term used through out this wiki.
+* The term service provider as used here is nearly equivalent to the [[Web Site]] term used through out this wiki.
 ===Status===

@@ Line 114: / Line 114: @@
 ==References==
 * [https://www.globalsign.com/en/blog/what-is-a-certificate-signing-request-csr/ 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.\
@@ Line 121: / Line 122: @@
 [[Category: User Experience]]
 [[Category: Consent]]
-[[Category:Health]]
+[[Category: Health]]
-[[Category:Trust]]
+[[Category: Trust]]
-[[Category:Privacy]]
+[[Category: Privacy]]

@@ Line 118: / Line 118: @@
 * [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf 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.
-[[Category:Binding]]
+[[Category: Binding]]
-[[Category:Consent]]
+[[Category: User Experience]]
-[[Category:Profile]]
+[[Category: Consent]]
 [[Category:Health]]
 [[Category:Trust]]
 [[Category:Privacy]]

@@ Line 61: / Line 61: @@
 # Session based - data is not retained after the HTTPS session is terminated.
 # 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.
-# 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.
+# 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 might enable some data to be retained for 2 years.
 # Relationship based - data is retained until the user terminates the relationship.
 # Legal based - data is retained as long as the law determines.

@@ Line 59: / Line 59: @@
 # 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.
-# Session based - data is not retained after the the HTTPS session is terminated.
+# Session based - data is not retained after the HTTPS session is terminated.
 # 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.
 # 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.

@@ Line 54: / Line 54: @@
 * [[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===
+===Lifecycle===
 * 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.
 # User Data acquired from the user or other sources, whether sanctioned by the user or not.