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

From: Rhys Smith <[email-masked]>
Date: Wed, 25 Sep 2013 17:30:48 +0000

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 <[email-masked]> 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?

> 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?

> 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?

Best,
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Sep 2013 11:46:23 -0700

You really expect me to remember after this long?

> -----Original Message-----
> From: Rhys Smith [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2013 10:31 AM
> To: Jim Schaad
> Cc: [email-masked]
> 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:
> 
> 
> > 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).
> 
> 
> 
> 

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.

> 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.
> 
> 
> 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.
> 

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
>