Difference between revisions of "Notice-centric ID"
From MgmtWiki
(→References) |
m (→Context) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
==Context== | ==Context== | ||
* The assumption on this page is that the user is trying to establish a long-term association with a web site to the mutual benefit of both and that the communications channel that best delivers value to the user needs to be oriented to the way that the user likes to receive notices of events from the web site. | * The assumption on this page is that the user is trying to establish a long-term association with a web site to the mutual benefit of both and that the communications channel that best delivers value to the user needs to be oriented to the way that the user likes to receive notices of events from the web site. | ||
| − | * It has become obvious that traditional methods of establishing identity have been focused on an Identifier Provider (IdP). This has created privacy and user tracking problems that have been difficult to mitigate. The most common method in 2020 is [[OpenID Connect]] using one of the | + | * It has become obvious that traditional methods of establishing identity have been focused on an Identifier Provider (IdP). This has created privacy and user tracking problems that have been difficult to mitigate. The most common method in 2020 is [[OpenID Connect]] using one of the [[Social Media]] sites like Facebook or Google. |
* A solution is needed that is more oriented to the user and their interactions with their mobile device than is possible with existing identity paradigms. | * A solution is needed that is more oriented to the user and their interactions with their mobile device than is possible with existing identity paradigms. | ||
| Line 13: | Line 13: | ||
* [[OpenID Connect]] understood this problem from the start and included section 7 for [[Self-issued Identifier]]s. Unfortunately the browser environment made thiis solution untenable and so it has never (by 2020) been successfully deployed outside of closed networks with multiple IdPs. | * [[OpenID Connect]] understood this problem from the start and included section 7 for [[Self-issued Identifier]]s. Unfortunately the browser environment made thiis solution untenable and so it has never (by 2020) been successfully deployed outside of closed networks with multiple IdPs. | ||
* Users have their own preferred, idiosyncratic methods of communications that are comfortable for them. These methods will depend more on user preferences than on industry or governmental policies. For example, a user may have two different credit cards that have different notification parameters so that every transaction creates a notice for the card used in suspicious venues, like online purchases. | * Users have their own preferred, idiosyncratic methods of communications that are comfortable for them. These methods will depend more on user preferences than on industry or governmental policies. For example, a user may have two different credit cards that have different notification parameters so that every transaction creates a notice for the card used in suspicious venues, like online purchases. | ||
| + | * In 2022 European countries, in particular, began to understand that the very act of requiring notices exposed the user. On 2023-07-22 Frances CNIL (data protection authority) issued a draft that applies to mobile applications. It aims to clarify the rules and obligations for the professionals involved in the mobile app ecosystem, such as app publishers, developers, SDK providers, OS providers and app store providers. It also provides practical guidance and checklists for each of these actors to help them comply with the data protection regulation. The draft recommendation covers various topics, such as the scope of application, the roles and responsibilities of each actor, the specific recommendations for each actor, and the glossary of terms.<ref>CNIL, https://www.cnil.fr/sites/cnil/files/2023-07/projet_recommandation_applications_mobiles.pdf</ref> The goal seems to be to provide the user with some alternate path for notifications to travel, other than through the smartphone's operating system. | ||
==Solutions== | ==Solutions== | ||
| Line 18: | Line 19: | ||
# The user is asked to provide an email or SMS phone number to use as the identifier. This is common today and preloads the notification with the user. | # The user is asked to provide an email or SMS phone number to use as the identifier. This is common today and preloads the notification with the user. | ||
# The user choses to use the web site to hold their notices so that they can be read in private. This is common in healthcare and finance. Some sites will also ask for a means to let the user know that a message has been posted, which the user must then authenticate to retrieve. | # The user choses to use the web site to hold their notices so that they can be read in private. This is common in healthcare and finance. Some sites will also ask for a means to let the user know that a message has been posted, which the user must then authenticate to retrieve. | ||
| − | # The web site is part of a family of site which are bound as a First-party site aggregation (see wiki page on [[Identifier use in Browsers]]). This is also know as a federation identity server and functions in many ways like the IdP option above. It does require a | + | # The web site is part of a family of site which are bound as a First-party site aggregation (see wiki page on [[Identifier use in Browsers]]). This is also know as a federation identity server and functions in many ways like the IdP option above. It does require a [[Single Sign-On]] ID for all the sites in the first-party list or in a site federated to a federation authority. |
The issue of more that one user on a notification channel is not considered here as that situation can already exist with share user accounts as is common in families that bind the account to streaming media services. | The issue of more that one user on a notification channel is not considered here as that situation can already exist with share user accounts as is common in families that bind the account to streaming media services. | ||
| Line 36: | Line 37: | ||
==References== | ==References== | ||
<references /> | <references /> | ||
| − | * See the wiki page on [[ | + | ===Other Materiel=== |
| + | * See the wiki page on [[Google Voice]] for a concrete example just such an [[Identifier]]. | ||
| + | * See the wiki page on [[Data Controller Options]]. | ||
* See the wiki page on [[User Consent]] which is a structure that tells the user what data is held. This [[Identifier]] is a first effort at providing a comprehensive ecosystem with [https://github.com/OpenNotice/ConceptualArchitecture Open Notice] oriented to users' choice. | * See the wiki page on [[User Consent]] which is a structure that tells the user what data is held. This [[Identifier]] is a first effort at providing a comprehensive ecosystem with [https://github.com/OpenNotice/ConceptualArchitecture Open Notice] oriented to users' choice. | ||
Latest revision as of 21:52, 23 September 2023
Contents
Full Title or Meme
The problem of giving notice to Subjects about issues is addressed before the user is asked to provide any personal information.
Maybe it would be more attractive to call this a Privacy-enforcing ID?
Context
- The assumption on this page is that the user is trying to establish a long-term association with a web site to the mutual benefit of both and that the communications channel that best delivers value to the user needs to be oriented to the way that the user likes to receive notices of events from the web site.
- It has become obvious that traditional methods of establishing identity have been focused on an Identifier Provider (IdP). This has created privacy and user tracking problems that have been difficult to mitigate. The most common method in 2020 is OpenID Connect using one of the Social Media sites like Facebook or Google.
- A solution is needed that is more oriented to the user and their interactions with their mobile device than is possible with existing identity paradigms.
Problems
- User Identity is immediately obvious from any social IDs. For example in Facebook there is a a requirement to link any Facebook ID to a real person.
- OpenID Connect understood this problem from the start and included section 7 for Self-issued Identifiers. Unfortunately the browser environment made thiis solution untenable and so it has never (by 2020) been successfully deployed outside of closed networks with multiple IdPs.
- Users have their own preferred, idiosyncratic methods of communications that are comfortable for them. These methods will depend more on user preferences than on industry or governmental policies. For example, a user may have two different credit cards that have different notification parameters so that every transaction creates a notice for the card used in suspicious venues, like online purchases.
- In 2022 European countries, in particular, began to understand that the very act of requiring notices exposed the user. On 2023-07-22 Frances CNIL (data protection authority) issued a draft that applies to mobile applications. It aims to clarify the rules and obligations for the professionals involved in the mobile app ecosystem, such as app publishers, developers, SDK providers, OS providers and app store providers. It also provides practical guidance and checklists for each of these actors to help them comply with the data protection regulation. The draft recommendation covers various topics, such as the scope of application, the roles and responsibilities of each actor, the specific recommendations for each actor, and the glossary of terms.[1] The goal seems to be to provide the user with some alternate path for notifications to travel, other than through the smartphone's operating system.
Solutions
- This proposed method for a web site to comply with Notice regulations is to create a Notice-centric ID. In this type of Identifier the issue of notification is to be addressed before the user is asked for personal data. So the notice channel to be established is addressed by the Identifier. Several options are considered that should cover the large majority of use cases.
- The user is asked to provide an email or SMS phone number to use as the identifier. This is common today and preloads the notification with the user.
- The user choses to use the web site to hold their notices so that they can be read in private. This is common in healthcare and finance. Some sites will also ask for a means to let the user know that a message has been posted, which the user must then authenticate to retrieve.
- The web site is part of a family of site which are bound as a First-party site aggregation (see wiki page on Identifier use in Browsers). This is also know as a federation identity server and functions in many ways like the IdP option above. It does require a Single Sign-On ID for all the sites in the first-party list or in a site federated to a federation authority.
The issue of more that one user on a notification channel is not considered here as that situation can already exist with share user accounts as is common in families that bind the account to streaming media services.
User Experience
As described above, this experience is oriented to websites that expect to create a long-term relationship to the user.
- User navigates to a site that entices them to register to acquire some attractive benefit.
- The site tells the user what attributes they will need to provide to be registered.
- The user consents to create a binding to the site.
- The Registration Ceremony starts by establishing a notification channel to the user that has an Identifier associated with it.
- The user is asked to create some simple pin or biometric method (think Microsoft Hello) to identify them selves to the service.
- This is for refreshing an existing TLS connection, not for creating a new connection after the old one is torn down.
- The user is asked to create a strong authentication factor with some device like a smartphone or yubi key.
- Notice that self-issued IDs fall into this category. This has the effect of changing some high assurance IdP into authentication providers. For example, DIDs fall into this category.
- The account is created, the user may then be asked for additional information
References
Other Materiel
- See the wiki page on Google Voice for a concrete example just such an Identifier.
- See the wiki page on Data Controller Options.
- See the wiki page on User Consent which is a structure that tells the user what data is held. This Identifier is a first effort at providing a comprehensive ecosystem with Open Notice oriented to users' choice.
