Kevin Koch wrote: > Can you please clarify the implementation note on page 4? I read it as the > identity providers will send lists of all the identities to anybody who > asks. That could be a lot and mostly irrelevant.
Identity Providers will provide NIM with the list of all identities just as it does today. However, today there is only one identity provider for Kerberos v5. > WRT figure 2 on page 4: the current NIM shows a list of the identities. > Figure 2 implies that the list will not be shown unless you click a drop > down. I'm not sure I consider that progress. Is my interpretation wrong? The application window shows a list of identities. This proposal does not describe the application window. It describes the "Obtain New Credentials" dialog. > WRT the Options note on page 4: guessing the users' preferences will ensure > that some of them are dissatisfied. Can the position/sorting style be > customizable? There are a variety of ways that positioning can be determined. We will be implementing a model similar to the Windows Start Menu in which identities that are more often or more recently used are displayed closer to the top of the list. It would be possible for a fixed list manually sorted by the user to be implemented. Someone would have to provide funding or development resources for that work. > Do the tabs in the Obtain New Credentials Advanced mode dialog on page 5 > take you to settings like or identical to the those currently available > under Identity Configuration? If so, the tabs should be removed. Obtaining > Credentials and Configuration Settings are separate. The tabs are the same tabs that exist today in the Advanced settings of the "Obtain New Credentials" dialog. The dialogs are extremely similar to the configuration options. Forcing users to go to a separate configuration panel in order to set things up before obtaining their credentials provides a user experience that is confusing and painful. A user that wants to obtain a specific AFS token as part of their authentication, or wishes to obtain renewable tickets with a 30 day lifetime need to be able to do so from the "Obtain New Credentials" dialog. That is where they are when they say to themselves "I need these credentials to be usable through a NAT." > The Creating New Identity dialog on page 8 should not be titled "Obtain New > Credentials." It should be a modal dialog whose parent is the Obtain New > Credentials dialog. If it is used to create a new identity, then when the > Create New Identity dialog is closed, the Obtain New Credentials dialog > should be updated with the new entry. This is a wizard. There is only one dialog. The user is taken through the flow of control to perform the required steps necessary to satisfy the user's goal. > I think it would be clearer to call the above-mentioned dialog "Define New > Identity," since the identity has already been created on the KDC. While either "define" or "create" would be appropriate to an entry in a KDC that pre-exists. It would not be the appropriate language to describe the creation of a local key store, or of a procedure that generates a public key pair and registers the user dynamically in a realm or other authentication name space. Besides, the action that the user is performing is creating a new entry in the NIM database. "Create" is an appropriate verb. > Any other dialogs that aren't identical to the existing NIM should be added > to the document so they can be reviewed. As described, this document is only about the "Obtain New Credentials" dialog. That is where there are significant changes from the existing NIM. Jeffrey Altman P.S. - Your response is not timely. It has been six weeks since the proposal was originally distributed and three weeks since it was reviewed at the "Symposium On Usable Privacy and Security". At this point coding is underway and there is not enough time between now and the delivery date for discussions of redesign. MIT has already given its approval on this development effort and I expect that MIT will accept it.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
