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

From: Mark Donnelly <[email-masked]>
Date: Tue, 21 Jul 2015 18:37:55 +0200

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.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 05:33:43 -0400

>>>>> "Mark" == Mark Donnelly <[email-masked]> writes:
    Mark> Conceptual: * The trust anchors belong to the IDP realms,
    Mark> right?  Wouldn't it make sense to have two identities within
    Mark> the same realm share a trust anchor?  The document details
    Mark> service to identity mappings, but identity to trust anchor
    Mark> mappings might merit attention too.  * 

This is a *really* good idea.

    Mark> One of the problems
    Mark> with error handling is that applications have the
    Mark> responsibility to handle errors, but not all of them do this
    Mark> well.  Would it make sense to hook into GSS_INIT_SEC_CONTEXT
    Mark> and the like, and record any errors, so that the identity
    Mark> selector can maintain a list of recently encountered errors?
    Mark> This could be correlated with the services and identities to
    Mark> show the error log for this service or this service/identity
    Mark> combination.  - This does get outside of the idea of an
    Mark> "identity selector", however.

I agree that more discussion of this would be valuable.
It only catches some of the errors.
In particular, it doesn't handle the unintended success case I discussed
in my comments.
I don't know how much more energy we have for this document.
One of the things we discussed when we first started this effort was
whether we wanted to document desired enhancements to GSS.
Tracking errors at the init_sec_context level plus some routine for
applications to signal that there had been an app-level authorization
problem would probably give better error handling experiences.
[on to specific comments]

    Mark> Note that in other contexts the usual use of "identity" would
    Mark> match our use of "user", whereas the usual use of "identifier"
    Mark> matches our use of identity
    Mark> ----------------------------------------------------------------
    Mark> If other contexts use the terms differently than this
    Mark> document, why not match those contexts?  Wouldn't that be less
    Mark> confusing?  * Trust Anchor + This isn't a complete sentence:
    Mark> ----------------------------------------------------------------

I think that at least for identity vs identifier the other contexts are
almost entirely outside of the IETF.  It's complicated now because a
bunch of those folks have started hanging around OAUTH/JOSE/CBOR.
However, I think the general point you're making  applies and should be
considered.

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

Presumably such a website would be https.
However, I think this is one of many cases where Rhys described what our
identity selector does, and I think you've done a good job of
identifying places where the document could be more general.
I definitely appreciate that work.

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

It's sad that the IETF has not come up with general advice on updating
leap-of-faith trust anchors yet as the problem pops up in several
protocols.
To my knowledge though we have no such general advice so I agree with
Mark that we should think about it here.

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

Generally, the desktop does not have server credentials.
It would be possible for each IDP realm to run such a service.
I think calling that out as a area for future expansion would be good.

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

Today none.
Perhaps a RADIUS routing error to your IDP realm should?

In section 7.5:

    Mark> * Could a list of open identity / service
    Mark> mappings be maintained?  Could it be added to during
    Mark> GSS_INIT_SEC_CONTEXT, GSS_ACCEPT_SEC_CONTEXT, or
    Mark> GSS_IMPORT_SEC_CONTEXT, and removed whenever the context goes
    Mark> away, either at expiration or as part of
    Mark> GSS_DELETE_SEC_CONTEXT or GSS_EXPORT_SEC_CONTEXT?  This would
    Mark> at least provide a user with a short list.

I don't understand this.
Are you saying that the selector could keep track of all the currently
open contexts?
One thing to consider is that there are a number of applications that
delete their context immediately after successful authentication.
But we definitely could keep a list of recently used identity/service
mappings.

I really wish we could get a UI consultant to explore this sort of
thing.
The ideas you proposed definitely belong in the spec.
We've proposed similar concepts internally to UI consultants and never
gotten useful feedback about which of them would actually be usable by
our users.