You really expect me to remember after this long? > -----Original Message----- > From: Rhys Smith [mailto:[email protected]] > Sent: Wednesday, September 25, 2013 10:31 AM > To: Jim Schaad > Cc: [email protected] > 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 <[email protected]> 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: [email protected] / [email protected] > GPG: 0xDE2F024C _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
