[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [higgins-dev] Higgins v1 bug status - Parity assignment summary
- From: "Jim Sermersheim" <jimse@xxxxxxxxxx>
- Date: Thu, 03 Jan 2008 16:59:00 -0700
- Delivered-to: firstname.lastname@example.org
I'd like to understand more clearly what the requirements for 1, 2, and 3 below so I can enter defects and track them.
#1 is the most unclear to me. I'm confused on two points: a) What qualifies something as "user data" versus "account data"? b) Where would we place things that qualify as "account data".
I think #1 proposes that anything which is used as a credential is termed "account data". However, when I authenticate to certain systems (for example, when I call my bank), I'm, asked for my name, a pin, and also my mailing address and details about recent transactions. What I'm saying is that sometimes what appears to be "user data" can be used in conjunction with what appears to be "account data" to satisfy an authentication request.
Beyond that though, there are non-credential kinds of information that are often stored about subjects which would also seem to be "account data". dateLastVisited, defaultCookieTimeout, airlineFederationToken, backgroundImage, could all possibly be seen as "account data". Or could be seen as "user data" depending on the criteria I guess.
I'll ask about #2 and #3 in other messages
IdAS subjects already have attributes and metadata. Do you propose that we begin using metadata for certain things
>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 12/24/07 4:49 AM >>>
> This 211945 is, I believe, the resolution to the thread started by SergeyL.
Really, #211945 concerns only JNDI CP implementation, but we proposed to make changes to IdAS interfaces. T
he main proposals are:
1. separate user data from IdAS data (from user account data like username/password, PPID hash etc.);
2. add some methods to IdAS (more likely to IContext) to be able to manage user accounts;
3. (optional) simplify/standardize user credentials management.
Now the same digital subject contains as user data attributes (profile data, for example) as " #cardKeyHash" (contains PPID hash and is used for authentication with self-signed card) attribute. We think we need to have some "user account" stucture (IUserAccount in my proposal), which will contain authentication materials of user. May be it can be DigitalSubject instance, if Jim will insist on this, but there should be some conditions/rules for such stucture (one instance per user account, some default attributes like username/password/ppid hash, etc.).