Difference between revisions of "Notice-centric ID"
From MgmtWiki
(→User Experience) |
(→User Experience) |
||
| Line 23: | Line 23: | ||
# The user consents to create a binding to the site. | # 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 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 connection. | + | # 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. | # 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. | ## 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. | ||
Revision as of 16:36, 16 February 2021
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.
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 notice, in some form, is required.
- 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.
Problems
- User Identity is immediately obvious from any social IDs. For example in Facebook there is a a requirement to like 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.
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 and considered.
- 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 function in many ways like the IdP option above. It does require a single sign in ID for all the site is 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
- 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
- See the wiki page on User Consent which is a structure that tells the user what data is held. This receipt is the first effort at providing Open Notice capabilities to users.
