[abfab] Comments on draft-ietf-abfab-usability-ui-considerations-02

[Mark Donnelly <[e-mail]>]

Hey all:

My comments on draft-ietf-abfab-usability-ui-considerations-02 follow below.

Cheers,
--Mark


Section 3:
  * The paragraph on identity says:
      ----------------------------------------------------------------
      Note that in
      other contexts the usual use of "identity" would match our use of
      "user", whereas the usual use of "identifier" matches our use of
      identity
      ----------------------------------------------------------------
    If other contexts use the terms differently than this document, why
    not match those contexts?  Wouldn't that be less confusing?
  * Trust Anchor
    + This isn't a complete sentence:
      ----------------------------------------------------------------
      Typically a commercial CA to allow authentication via chain of
      trust, or a preconfigured non-commercial certificate (e.g.
      self-signed).
      ----------------------------------------------------------------
    + Does the identity selector deal with trust anchors for services
      at all?  If so, then this should be addressed in section 6.1,
      where no mention is made of storing the service's trust
      identity.

Section 4:
  * another downside of using the OS credentials for identity is that
    precludes the idea of authenticating oneself to the OS using ABFAB.

Section 5.1:
  * The second paragraph reads:
    --------------------------------------------------------------------
      Implementers may wish to keep such abstract
      concepts, or may wish to examine attempts to map to real world
      paradigms, e.g. the idea of using "Identity Cards" that are held
      in the user's "Wallet", as used by Microsoft Cardspace.
    --------------------------------------------------------------------
    The first half of that sentence seems to be missing a word, such
    as, "... keep such abstract concepts *hidden*..."

Section 5.3: Why does this section belong under section 5?

Section 6.1:
  * The explanation of why the identity selector MUST NOT store
    different identities that use the same NAI doesn't make a lot of
    sense to me.  I agree that duplicating the data would be bad in a
    data-normalization sense, but I don't see why you're saying that it
    would be dysfunctional as an IETF consideration.
  * "Credential" is defined here, but probably deserves an entry in
    section 3's terminology list.
  * Further, I think that saying, "the identity selector SHOULD store
    the credential" isn't descriptive of what we want to happen.  A
    better phrasing would be that, "the identity selector SHOULD allow
    a user to store the credential.  However, it MUST NOT store the
    credentials without confirmation from the user."
  * The trust identity that the selector stores is that of the Identity
    Provider, right?  This isn't at all clear from this definition.

Section 6.2:
  * Why is secure storage a SHOULD instead of a MUST?  I'd be happy to
    declare that selectors with world-readable storage are not
    following this standard.
  * Also, you might want to mention the Windows Credentials Manager.

Section 6.3:
  * Maybe call the process of putting a new ID in the selector
    "assertion"?  (feel free to ignore this one if you don't like it)

Section 6.3.2:
  * Why force users to enter an NAI into a website before downloading a
    trust anchor?  Why not give an option of downloading a trust anchor
    without any user information, and having the identity selector
    prompt the user for all missing bits of required information at
    import time?  This would prevent people who are eavesdropping on
    the website from learning user identities.

Section 6.4.1:
  * The document should list restrictions on modification of trust
    anchors.  For instance, manual modification of a trust anchor
    probably doesn't make any sense.  Semi-automated (re-do a leap of
    faith or something of the sort) modification of it might make
    sense, but needs to warn the user that their basis for trusting the
    system is changing.  Enterprise change pushes probably don't need
    any notifications.

Section 6.5:
  * Wouldn't it be possible for the desktop to attempt a validation of
    the password?  For instance, could there be a standard service -
    say, "identitymanager" - put in place for every client
    installation.  Then a user could attempt to authenticate to it, and
    determine if the password is incorrect.  Heck, maybe that service
    could be the process that writes the credential to the permanent
    store.

Section 7.1.1, point 1: Doesn't this point contradict section 7.1?

Section 7.1.2:
  * The implication here is that rules based association exists solely
    for enterprise-provisioned identities.  Why would that be
    restricted?
  * Also, this is missing a period at the end of the sentence.

Section 7.2:
  * What kind of authentication failure causes my local client to
    dissociate?

Section 7.5:
  * The identity selector could:
    + Display OS notifications (Windows system tray, Mac growler, Gnome
      notifications) when an identity is used - especially when the
      identity is used without any user prompt.
    + Keep a history of identity / service usage to display in the
      identity selector application windows
  * Could a list of open identity / service mappings be maintained?
    Could it be added to during GSS_INIT_SEC_CONTEXT,
    GSS_ACCEPT_SEC_CONTEXT, or GSS_IMPORT_SEC_CONTEXT, and removed
    whenever the context goes away, either at expiration or as part of
    GSS_DELETE_SEC_CONTEXT or GSS_EXPORT_SEC_CONTEXT?  This would at
    least provide a user with a short list.

Conceptual:
* The trust anchors belong to the IDP realms, right?  Wouldn't it make
  sense to have two identities within the same realm share a trust
  anchor?  The document details service to identity mappings, but
  identity to trust anchor mappings might merit attention too.
* One of the problems with error handling is that applications have the
  responsibility to handle errors, but not all of them do this well.
  Would it make sense to hook into GSS_INIT_SEC_CONTEXT and the like,
  and record any errors, so that the identity selector can maintain a
  list of recently encountered errors?  This could be correlated with
  the services and identities to show the error log for this service or
  this service/identity combination.
  - This does get outside of the idea of an "identity selector",
    however.