InnovationQ will be updated on Sunday, April 29, from 10am - noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Uncommitted Access for Semi-Identified Users

IP.com Disclosure Number: IPCOM000130106D
Original Publication Date: 2005-Oct-11
Included in the Prior Art Database: 2005-Oct-11
Document File: 1 page(s) / 25K

Publishing Venue



Disclosed is a method to allow users to work during the password reset process: Have a "semi-identified" state for users. Users in this state can read information and write it. When they write, however, the information is not updated in the main database. Instead, it is cached in special "change pending" tables. Once the user is finally authenticated, then he/she can approve of the changes done and commit them.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

Uncommitted Access for Semi -Identified Users

The three requirements for information security are confidentiality, integrity, and availability. When a user forgets his/her password, that user is typically denied access to the system until the password can be reset. This protects confidentiality and integrity, at the price of availability. In some applications, confidentiality is not as big a requirement as integrity and availability are. For example, an online bulletin board site expects EVERYBODY to be able to read the information, even if only some people are allowed to change it.

To provide some availability during the password-reset process, create a semi-authenticated state. When users are in that state (the security subsystems thinks it knows who they are, but the password-reset process is not completed), allow them access to the application under the following conditions:

1. Preferences are handled normally.
2. Reading information is allowed as anonymous users. That is, only information anonymous users are allowed to read is accessible.
3. Writing information is allowed, but it goes to a "changes pending" table, rather than the normal database tables.

Once the user is authenticated completely, the user gets a list of changes they attempted to perform. They can then commit the changes or back out of them. This will allow the users to work during the password-reset process.