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

[Sam Hartman <[e-mail]>]

>>>>> "Mark" == Mark Donnelly <[e-mail]> 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.