PAWS Meeting 2006-10-30
      Discussion of Central Login for PAWS Adaptive applications
Overview
Centralized login is an analog of .Net Passport. There exists a unified storage of identities (here user identities) that applications refer to and rely on when it comes to registration of new users and authentication o existing.
Motivation for the centralization of a login
- a lot of users use multiple applications but have separate logins for them
- maintaining user identities at the site of each application is costly and ineffective
Note
User identity is not user model/profile, user application specific data about user is not a part of identity
User Identity fields
Incorporating group and group membership information has been postponed till further more thorough discussion.
Planned course of action
- developers should provide their user identity data for future merger
- identity data should be retrieved from Central User Identity Store and not from a local application
- conflicts in user names should be resolved in an organized fashion when needed
- interface of interaction with User Identity store to be presented later
    Overview
Centralized login is an analog of .Net Passport. There exists a unified storage of identities (here user identities) that applications refer to and rely on when it comes to registration of new users and authentication o existing.
Motivation for the centralization of a login
- a lot of users use multiple applications but have separate logins for them
- maintaining user identities at the site of each application is costly and ineffective
Note
User identity is not user model/profile, user application specific data about user is not a part of identity
User Identity fields
- Mandatory fields
 - Name: Last, Given
 - Login
 - Password
 - Recommended
 - gender
 - Optional
 - Organization/Affiliation
 - City + State (Region outside U.S.)
 - ZIP (Postal code)
 - Country
 - Comments (How did you hear about us, etc)
 
Incorporating group and group membership information has been postponed till further more thorough discussion.
Planned course of action
- developers should provide their user identity data for future merger
- identity data should be retrieved from Central User Identity Store and not from a local application
- conflicts in user names should be resolved in an organized fashion when needed
- interface of interaction with User Identity store to be presented later
