Credential Aggregation - Revision history

Tom: /* References */

2024-08-11T15:43:12Z

‎References

Tom: /* Taxonomy */

2022-09-12T22:44:16Z

‎Taxonomy

Tom: /* Solutions */

2022-09-12T22:43:15Z

‎Solutions

Tom: /* Problems */

2022-05-26T03:47:25Z

‎Problems

Tom: /* Problems */

2022-05-26T03:46:19Z

‎Problems

Tom: /* Problems */

2022-05-26T03:45:15Z

‎Problems

Tom: /* Problems */

2022-05-26T03:42:02Z

‎Problems

Tom: /* REAL ID */

2022-02-18T05:41:05Z

‎REAL ID

Tom: /* Consent */

2022-02-18T02:03:41Z

‎Consent

Tom: /* Problems */

2021-12-18T22:03:12Z

‎Problems

← Older revision		Revision as of 15:43, 11 August 2024
Line 63:		Line 63:
	[[Category: Authentication]]		[[Category: Authentication]]
	[[Category: Authorization]]		[[Category: Authorization]]
		+	[[Category: Use Case]]

@@ Line 20: / Line 20: @@
 * [[Claim]] as defined in NIST or SAML publications is just a statement the user makes about themselves. Sometimes this is confused with attribute.
 * [[Verified]] can applied to [[Credential]]s, [[Presentation]]s or [[Attribute]]s.
-* [[Digital Presentation]] is a data minimized collection of user attributes from one or more credentials.
+* [[Digital Presentation]] is a [[Data Minimization|data minimized]] collection of user attributes from one or more credentials.
 * [[User Experience]] or presentation of options to the user for their consent.
 * [[OpenID_Connect#Identity_Token|Identity Token]] is generated by an [[Authentication]] process like [[OpenID Connect]].

@@ Line 40: / Line 40: @@
 * Any successful solution cannot make life more difficult for the user. [[Credential Aggregation]] is proposed for the gym access use case.
 * As a general rule the user's entire credential data contents should not be passed to any [[Relying Party]] whether in-person or on-line.
-* Data minimization requires that most presentations of user data be extracted from the credential depending on the purpose of use.
+* [[Data Minimization]] requires that most presentations of user data be extracted from the credential depending on the purpose of use.
-* Presentation apps are likely to exist based on the needs of the [[Relying Party]] and will need to be able to acquire data from all sorts of credentials. In some cases these will be delivered to the user with the [[Smartphone]].
+* Presentation apps are likely to exist based on the needs of the [[Relying Party]] and will need to be able to acquire data from all sorts of credentials. In some cases, these will be delivered to the user with the [[Smartphone]].
 * Since many of the wallets are not configurable to talk to other apps on the [[Smartphone]], it is expected that most presentation apps will be provided as [[Progressive Web App]]s. In many cases these apps will be from the [[Relying Party]] or a [[Federation]] of Relying Parties. This solution allows the [[Relying Party]] to ensure that the data provided is sufficient to act as an access token, perhaps with some biometric evaluation, which could be performed within the [[Smartphone]] itself.
 * Once a user has an access token on the Smartphone, it is very helpful for the user to be able to verify that the access token will work before travelling to the gym. Such a verification endpoint should always be available to the holder of the credential and/or the [[Access Token]].
@@ Line 48: / Line 48: @@
 * To meet the principle that user's must be aware that data is only to be used for the purpose intended several conditions will be crucial.
 # The user can see the purpose of use display on a consent screen.
-# There maybe a list of data elements displayed to the user, but this in not a good [[User Experience]].
+# There may be a list of data elements displayed to the user, but this in not a good [[User Experience]].
 # In cases like healthcare it is not likely that the user would even understand what most of the data elements were and the list would be very long.
 # One possible solution is a government approved list of purposes. It is likely that industry groups would be tasked to create the lists for approval.

@@ Line 35: / Line 35: @@
 * Other credentials, like the [[Smart Health Card]] (shc:) are completely independent of the wallet and are accepted by existing [[Smartphone]]s updates as of 2021-11-24. In some cases the shc is stored in a health app rather than in the wallet.
 * When multiple credentials are needed at one site (like the gym in this case) it is likely that the user (in 2021) will need to open separate web apps or wallets for each credential. Not a very user-friendly process when trying to carry your gym bag and get past the receptionist.
-* There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses<ref>Noah Farmer ''ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad'' (2022-05-17) Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad</ref>, so we must assume that this will become a favor identity spoofing technique.
+* There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses<ref>Noah Farmer ''ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad'' (2022-05-17) Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad</ref>, so we must assume that this will become a favorite identity spoofing technique.
 ==Solutions==

@@ Line 35: / Line 35: @@
 * Other credentials, like the [[Smart Health Card]] (shc:) are completely independent of the wallet and are accepted by existing [[Smartphone]]s updates as of 2021-11-24. In some cases the shc is stored in a health app rather than in the wallet.
 * When multiple credentials are needed at one site (like the gym in this case) it is likely that the user (in 2021) will need to open separate web apps or wallets for each credential. Not a very user-friendly process when trying to carry your gym bag and get past the receptionist.
-* There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses<ref>Noah Farmer ''ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad'' (2022-05-17 Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad</ref>, so we must assume that this will become a favor identity spoofing technique.
+* There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses<ref>Noah Farmer ''ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad'' (2022-05-17) Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad</ref>, so we must assume that this will become a favor identity spoofing technique.
 ==Solutions==

@@ Line 56: / Line 56: @@
 * The REAL ID is issued as a [[Credential Aggregation]] indicator. These the REAL ID process can be viewed as a prototype of a [[Policy-Based Access Control]] method.
 * The following is an example of the aggregation template use by the State of Washington.
 ==References==

@@ Line 26: / Line 26: @@
 ==Problems==
 * In the real world only a few sites ask to make copies of your credentials and collect more data than they need in the process.
 ** This is changing now that scanners can capture a driver's license card and turn it into a digital representation.