Re: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-03

["Jim Schaad" <[e-mail]>]

You really expect me to remember after this long?

> -----Original Message-----
> From: Rhys Smith [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2013 10:31 AM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: Re: Comments on draft-smith-abfab-usability-ui-considerations-03
> 
> Jim, all,
> 
> Assume all points addressed in -04 to be submitted shortly, apart from
those I
> have specific comments about below:
> 
> 
> On 1 Mar 2013, at 19:21, Jim Schaad <[e-mail]> wrote:
> > 6.  Section 6.1 - Is the issuing organization always going to be
> > derivable from the NAI of the user?  Under what circumstances would
> > this not be the case?
> 
> Actually, I don't think this is needed at all. If we're saying that we
MUST store
> an NAI, then that contains both the username and realm to use for
identifying
> the particular IdP. And then the friendly name for the identity would be
the
> place to store a human-friendly name (e.g. Janet or Cardiff University).
> 
> 
> 
> 
> > 10 Section 7 - Identity selection by calling application rather than
> > GSS-API
> 
> Sorry, not sure what part of Section 7 this comment is referring to?
> 

My best guess as to what I meant here, is that there should be a discussion
about the application that is requesting a server either be able to provide
its own mapping, rather than using the GSS-API internals for doing the
mapping.  Or that it should be able to do some filtering of the identities
that are displayed.

> 
> > 11 Section 7 - last paragraph - last sentence - should this be an
> > "automatic" option on some types of authentication failures?
> 
> Good point. I've removed discussion of it being manual at all in that
para, and
> amended section 7.4 to include the idea of manual and automated
> disassociation.
> 
> 
> > 12.  Section 7.3 - why should the association only be doable after
> > authentication?  Esp for manual authentications.
> 
> I think it's advisable that this would be the case as it would make
interacting
> with the user easier if the attempt failed, as it could happen JIT as the
user
> attempts to make the connection. If they'd previously made it and, say,
only
> tried to actually use that service weeks later, it would be less obvious
to the
> user as to what the problem might be, I think. I've changed the language
> though so as to not rule that out.
> 
> 
> > 13.  Section 7.3.1 - It would be beneficial to list the types of
> > things that are selections.  I don't know that it is necessary to know
> > the realm in all cases.
> 
> Do we know what these things would be?
> 
> Actually, wouldn't it just be the GSS Acceptor Name of the service?

Yes, but it would be the full name with all of its parameters and just the
name of the machine plus the service name.

> 
> 
> > 15.  Section 8 - should applications attempt to use multiple names if
> > there are multiple names associated with the service.  Need to discuss
> > possible privacy implications of this approach in terms of association
> > of multiple names together.
> 
> Sorry, not sure what this is referring to in sec 8? or is this suggesting
a new
> topic that should be in the error handling section?

This was triggered in my mind on handling of errors, but it might not belong
in this section.

Consider the case where I have two distinct identities associated with the
generic smtp service (i.e. not associated with any server name).  Is there a
privacy concern about providing the first one if it fails but the second one
works.  Should the use be told that which of the two succeeded or should
that be a hidden error?

Jim

> 
> 
> Best,
> Rhys.
> --
> Dr Rhys Smith
> Identity, Access, and Middleware Specialist Cardiff University & Janet -
the
> UK's research and education network
> 
> email: [e-mail] / [e-mail]
> GPG: 0xDE2F024C