Consent to Create Binding - Revision history

Tomjones: /* Appendix */

2020-12-23T01:29:11Z

Appendix

← Older revision		Revision as of 01:29, 23 December 2020
Line 100:		Line 100:
	There are others creating a similar result.		There are others creating a similar result.
	* Session ID		* Session ID
	* [https://identity.foundation/peer-did-method-spec/ Peer DID] for a Decentralized Identifier.		* [https://identity.foundation/peer-did-method-spec/ Peer DID] for a Decentralized Identifier Method.


	==References==		==References==

Tomjones: /* References */

2020-12-23T01:27:41Z

References

← Older revision		Revision as of 01:27, 23 December 2020
Line 96:		Line 96:
	#Signature<blockquote>MANDATORY - using the above key.</blockquote>		#Signature<blockquote>MANDATORY - using the above key.</blockquote>
	#Encryption<blockquote>MANDATORY??? - using the Subject's key.</blockquote>		#Encryption<blockquote>MANDATORY??? - using the Subject's key.</blockquote>

			==Appendix==
			There are others creating a similar result.
			* Session ID
			* [https://identity.foundation/peer-did-method-spec/ Peer DID] for a Decentralized Identifier.


	==References==		==References==

Tomjones: /* Consent to Create Binding Request */

2020-05-07T23:45:55Z

Consent to Create Binding Request

← Older revision		Revision as of 23:45, 7 May 2020
Line 65:		Line 65:
	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.		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.
	#Identifier of the message<blockquote>Protocol dependent - may have message identifier, version number, unique sequence number, nonce or state.</blockquote>		#Identifier of the message<blockquote>Protocol dependent - may have message identifier, version number, unique sequence number, nonce or state.</blockquote>
	#Issuer (aka Organization or Audience)<blockquote>MANDATORY - URI OF the CSP (Audience of the request). This would be the entity that supplies a public key when encryption is required.</blockquote>		#Issuer (aka Organization or Audience)<blockquote>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.</blockquote>
	#Subject (aka Grantor)<blockquote>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.</blockquote>		#Subject (aka Grantor)<blockquote>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.</blockquote>
	#Subject Role<blockquote>MANDATORY - this is the relationship between the subject and the owner of the information (e.g. patient). Typically will be self or guardian.</blockquote>		#Subject Role<blockquote>MANDATORY - this is the relationship between the subject and the owner of the information (e.g. patient). Typically will be self or guardian.</blockquote>

Tomjones: /* Consent Receipt with Binding */

2020-05-07T23:43:32Z

Consent Receipt with Binding

← Older revision		Revision as of 23:43, 7 May 2020
Line 86:		Line 86:
	#Binding Statement (aka [[Consent Receipt]] or [https://tcwiki.azurewebsites.net/index.php?title=Entity_Statement Entity Statement])<blockquote>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.</blockquote>		#Binding Statement (aka [[Consent Receipt]] or [https://tcwiki.azurewebsites.net/index.php?title=Entity_Statement Entity Statement])<blockquote>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.</blockquote>
	#Issuer (of this receipt aka Organization)<blockquote>MANDATORY This the entity that the subject is forming a binding with. It may be a brand name rather that a legal name.</blockquote>		#Issuer (of this receipt aka Organization)<blockquote>MANDATORY This the entity that the subject is forming a binding with. It may be a brand name rather that a legal name.</blockquote>
	#Role of Issuer<blockquote>MANDATORY - this is the role(s) that the ~~issue~~ takes. (eg CSP, Identifier Provider, Data Controller)</blockquote>		#Role of Issuer<blockquote>MANDATORY - this is the role(s) that the issuer takes. (eg CSP, Identifier Provider, Data Controller)</blockquote>
	#Legal Name<blockquote>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.</blockquote>		#Legal Name<blockquote>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.</blockquote>
	#Subject<blockquote>MANDATORY - this is the identifier supplied by the user. This receipt is bound to this identifier.</blockquote>		#Subject<blockquote>MANDATORY - this is the identifier supplied by the user. This receipt is bound to this identifier.</blockquote>

Tomjones at 20:03, 18 April 2020

2020-04-18T20:03:33Z

Tomjones: /* Full Title */

2020-04-18T20:00:45Z

Full Title

← Older revision		Revision as of 20:00, 18 April 2020
Line 1:		Line 1:
	==Full Title==		==Full Title==

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

	===Goals===		===Goals===

Tomjones: /* Registration Ceremony */

2020-04-18T19:59:23Z

Registration Ceremony

← Older revision		Revision as of 19:59, 18 April 2020
Line 59:		Line 59:
	* At the end of the registration ceremony it is expected that a notification channel will be open from the website to the user to meet the requirements of the GDPR or CCPR.		* At the end of the registration ceremony it is expected that a notification channel will be open from the website 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]].		* 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 website 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===		===Consent to Create Binding Request===

Tomjones: /* Registration Ceremony */

2020-04-18T19:57:30Z

Registration Ceremony

← Older revision		Revision as of 19:57, 18 April 2020
Line 58:		Line 58:
	* 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 website, 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 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 website, 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].
	* At the end of the registration ceremony it is expected that a notification channel will be open from the website to the user to meet the requirements of the GDPR or CCPR.		* At the end of the registration ceremony it is expected that a notification channel will be open from the website 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]].

	===Consent to Create Binding Request===		===Consent to Create Binding Request===

Tomjones: /* References */

2020-03-27T21:34:37Z

References

← Older revision		Revision as of 21:34, 27 March 2020
Line 100:		Line 100:

	[[Category:Binding]]		[[Category:Binding]]
			[[Category:Consent]]
	[[Category:Profile]]		[[Category:Profile]]
	[[Category:Health]]		[[Category:Health]]
	[[Category:Trust]]		[[Category:Trust]]
	[[Category:Privacy]]		[[Category:Privacy]]

Tomjones: /* Consent to Create Binding Request */

2020-03-06T00:10:47Z

Consent to Create Binding Request

← Older revision		Revision as of 00:10, 6 March 2020
Line 76:		Line 76:
	#Subject Public Key<blockquote>MANDATORY - must be included directly or by reference.</blockquote>		#Subject Public Key<blockquote>MANDATORY - must be included directly or by reference.</blockquote>
	#Signature<blockquote>MANDATORY - using the above key.</blockquote>		#Signature<blockquote>MANDATORY - using the above key.</blockquote>
	#Encryption<blockquote>MANDATORY~~???~~ - 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.</blockquote>		#Encryption<blockquote>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.</blockquote>

	===Consent Receipt with Binding===		===Consent Receipt with Binding===

← Older revision		Revision as of 20:03, 18 April 2020
Line 8:		Line 8:
	* 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.		* 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).		* 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 ~~website~~ would be permitted to retain any user information without first receiving a signed consent form like the included.		* 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===		===Scope===
	* This specification applies only to ~~websites~~ that have determined that they need to acquire explicit consent from individuals.		* 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.		* 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.
			* The term service provider as used here is nearly equivalent to the website term used through out this wiki.

	===Status===		===Status===
Line 56:		Line 57:
	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.		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===		===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 ~~website~~, 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 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].
	* At the end of the registration ceremony it is expected that a notification channel will be open from the ~~website~~ to the user to meet the requirements of the GDPR or CCPR.		* 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]].		* 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 ~~website~~ 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.		* 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===		===Consent to Create Binding Request===