Proposal for NIM 2.0 Multiple Identity Provider User Experience and PK-INIT

[Jeffrey Altman]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070807/11bd0fdc/attachment.bin