Mobile Driver's License Criteria - Revision history

Tomjones: /* 2 Privacy generally */

2021-06-09T16:56:28Z

2 Privacy generally

← Older revision		Revision as of 16:56, 9 June 2021
Line 150:		Line 150:
	# The person in possession and presenting the mDL is not the subject. (Or, in other words, the physical holder of the device is not the "holder" of the DL.)		# The person in possession and presenting the mDL is not the subject. (Or, in other words, the physical holder of the device is not the "holder" of the DL.)
	# The rights granted to the subject using the mDL are improperly diverted (e.g. drugs or alcohol).		# The rights granted to the subject using the mDL are improperly diverted (e.g. drugs or alcohol).
			# Profiling of the user by the issuing authority is not in scope of the spec, but should be at least addressed by federal regulations. For example, if every access of the database by a police officer were recorded, the behavior of the holder could be incorrectly inferred or used against the holder. This weakness could be mitigated by the use of a trusted third party that would validate all requests by verifiers and pass them anonymously to the issuing authority to assure that the license was still valid. The actual validity of the license MUST not be released to any location other thay traffic officers and courts. This point does NOT apply to the expiry date on a certificate or license document.

	===3 Industry Standards ===		===3 Industry Standards ===

Tomjones: /* 2 Privacy generally */

2021-06-02T05:22:09Z

2 Privacy generally

← Older revision		Revision as of 05:22, 2 June 2021
Line 138:		Line 138:
	### Various branches of DHS: FEMA, ICE, TSA, etc.		### Various branches of DHS: FEMA, ICE, TSA, etc.
	# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.		# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.
	# The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted at rest.		# The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted-at-rest.
	# The data link between the smartphone and verifier can be intercepted. Encryption is called for in the standard.		# The data link between the smartphone and verifier can be intercepted. Encryption-in-motion is called for in the standard.
	# The verifier maintains all the data sent to it against applicable privacy guidelines.		# The verifier maintains all the data sent to it against applicable privacy guidelines.
	# The verifier uses holder data without informed consent (e.g. facial recognition)		# The verifier uses holder data without informed consent (e.g. facial recognition)

Tomjones: /* 2 Privacy generally */

2021-06-02T05:21:12Z

2 Privacy generally

← Older revision		Revision as of 05:21, 2 June 2021
Line 139:		Line 139:
	# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.		# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.
	# The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted at rest.		# The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted at rest.
	# The data link between the smartphone and verifier can be intercepted.		# The data link between the smartphone and verifier can be intercepted. Encryption is called for in the standard.
	# The verifier maintains all the data sent to it against applicable privacy guidelines.		# The verifier maintains all the data sent to it against applicable privacy guidelines.
	# The verifier uses holder data without informed consent (e.g. facial recognition)		# The verifier uses holder data without informed consent (e.g. facial recognition)

Tomjones: /* 2 Privacy generally */

2021-06-02T05:20:11Z

2 Privacy generally

← Older revision		Revision as of 05:20, 2 June 2021
Line 138:		Line 138:
	### Various branches of DHS: FEMA, ICE, TSA, etc.		### Various branches of DHS: FEMA, ICE, TSA, etc.
	# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.		# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.
	# The storage of the mDL on the smartphone is not secure and other apps can get access to the data.		# The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted at rest.
	# The data link between the smartphone and verifier can be intercepted.		# The data link between the smartphone and verifier can be intercepted.
	# The verifier maintains all the data sent to it against applicable privacy guidelines.		# The verifier maintains all the data sent to it against applicable privacy guidelines.

Tomjones: /* 2 Privacy generally */

2021-06-02T05:18:26Z

2 Privacy generally

← Older revision		Revision as of 05:18, 2 June 2021
Line 137:		Line 137:
	### Paramedics (or physicians) on duty.		### Paramedics (or physicians) on duty.
	### Various branches of DHS: FEMA, ICE, TSA, etc.		### Various branches of DHS: FEMA, ICE, TSA, etc.
	# The ~~link~~ between the mDL and the verifier is unencrypted and ~~leaks~~ data.		# The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.
	# The storage of the mDL on the smartphone is not secure and other apps can get access to the data.		# The storage of the mDL on the smartphone is not secure and other apps can get access to the data.
	# The data link between the smartphone and verifier can be intercepted.		# The data link between the smartphone and verifier can be intercepted.

Tomjones: /* 2 Privacy generally */

2021-06-01T16:28:19Z

2 Privacy generally

← Older revision		Revision as of 16:28, 1 June 2021
Line 148:		Line 148:
	## One way would be for a set of standard profiles to be created and deployed.		## One way would be for a set of standard profiles to be created and deployed.
	## That would make it easier for the agency to get the right set of data for the situation.		## That would make it easier for the agency to get the right set of data for the situation.
	# The person presenting the mDL is not the subject.		# The person in possession and presenting the mDL is not the subject. (Or, in other words, the physical holder of the device is not the "holder" of the DL.)
	# The rights granted to the subject using the mDL are improperly diverted (e.g. drugs or alcohol).		# The rights granted to the subject using the mDL are improperly diverted (e.g. drugs or alcohol).

Tomjones: /* 2 Privacy generally */

2021-06-01T16:22:31Z

2 Privacy generally

← Older revision		Revision as of 16:22, 1 June 2021
Line 129:		Line 129:
	* Research on the User Experience of the privacy of their data is important. There is an on-going experience with current roll-outs. These experiments need to be mined for both good and bad user experiences.		* Research on the User Experience of the privacy of their data is important. There is an on-going experience with current roll-outs. These experiments need to be mined for both good and bad user experiences.
	* User notifications of consents and breaches need to be honest and timely to maintain user trust in the product. In many cases the user understanding of the trust level will be more important than the reality.		* User notifications of consents and breaches need to be honest and timely to maintain user trust in the product. In many cases the user understanding of the trust level will be more important than the reality.
			* BLE and Wifi used for device initiation can be used to track the physical location of that device over time. A sufficiently long path can be used to identify an individual person.
	# The verifier is presumed to be unworthy to access user data until it is recognized by the user’s device.		# The verifier is presumed to be unworthy to access user data until it is recognized by the user’s device.
	## The user may decide which verifiers are trusted. It would be helpful to the user to not need to make this choice more than once so that they do not experience cognitive overload and automatically accept any site asking.		## The user may decide which verifiers are trusted. It would be helpful to the user to not need to make this choice more than once so that they do not experience cognitive overload and automatically accept any site asking.

Tomjones: /* 2 Privacy generally */

2021-06-01T16:19:52Z

2 Privacy generally

← Older revision		Revision as of 16:19, 1 June 2021
Line 124:		Line 124:
	what privacy concerns or benefits may arise from mDL transactions, and how DHS should address those in the REAL ID context.		what privacy concerns or benefits may arise from mDL transactions, and how DHS should address those in the REAL ID context.
	* Reader can ask for all user data under false pretenses - reader can be attacker - issuer can collect behavior of user in the real world by where mDL is used.		* Reader can ask for all user data under false pretenses - reader can be attacker - issuer can collect behavior of user in the real world by where mDL is used.
	* PII Data on a open channel must be encrypted		* PII Data on a open channel must be encrypted, access to the keying material must be protected.
	* Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.		* Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.
	* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)		* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)

Tomjones: /* 2 Privacy generally */

2021-06-01T16:15:19Z

2 Privacy generally

← Older revision		Revision as of 16:15, 1 June 2021
Line 126:		Line 126:
	* PII Data on a open channel must be encrypted		* PII Data on a open channel must be encrypted
	* Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.		* Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.
	* Only NFC should be used as eavesdropping on BLE is too easy and well-known.
	* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)		* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)
	* Research on the User Experience of the privacy of their data is important. There is an on-going experience with current roll-outs. These experiments need to be mined for both good and bad user experiences.		* Research on the User Experience of the privacy of their data is important. There is an on-going experience with current roll-outs. These experiments need to be mined for both good and bad user experiences.

Tomjones: /* 2 Privacy generally */

2021-05-24T22:42:10Z

2 Privacy generally

← Older revision		Revision as of 22:42, 24 May 2021
Line 125:		Line 125:
	* Reader can ask for all user data under false pretenses - reader can be attacker - issuer can collect behavior of user in the real world by where mDL is used.		* Reader can ask for all user data under false pretenses - reader can be attacker - issuer can collect behavior of user in the real world by where mDL is used.
	* PII Data on a open channel must be encrypted		* PII Data on a open channel must be encrypted
	* Any party to the transaction, most specifically the U.S. government can track users if there a many ~~cases~~ where ID is requested.		* Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.
	* Only NFC should be used as eavesdropping on BLE is too easy and well-known.		* Only NFC should be used as eavesdropping on BLE is too easy and well-known.
	* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)		* Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)