Subject: [abfab] draft-ietf-abfab-usability-considerations review

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jul 2015 07:06:08 -0400

Section 3 and 6.
Trust anchor is described as either being the trust anchor for a service
or identity provider.
In section 6 the document talks about trust anchors for servers.
IN the scope of this document we only care about trust anchors for
identity provider.
I recommend narrowing the definition in section 3 and using more
specific terminology in section 6.

Section 6.1
The biggest reason we don't want to store multiple identities with a the
same NAI is that by passing in a NAI to gss_acquire_creds the
application can force the choice of a given NAI.

Section 8:

Section 8 implies that the identity selector will be in a position to
decide what errors to present to the user.
I don't think that's very likely to be true.
The GSS application is likely to decide what errors to present to the
user.

The identity selector is in a position to decide what if any automated
actions to take based on the error.

Section 8/9 should discuss the success but useless case.
That is, I am successfully authenticated and an app layer connection is
accepted, but I don't have the permissions I need.
Think about the case where I was hoping to be a moonshot management
portal admin, but end up being a random user.  I was hoping to create an
organisation but all I can do is create communities.
I'm not sure if it is an error or a success.

I think section 8 and 9 could also do a better job of clarifying what it
means for errors to be reported at different layers.  For example in
SASL, authorization failures will probably not come back as a GSS error,
but instead either as a dropped connection or as an app-level error.

--Sam