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? > 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 protected] / [email protected] GPG: 0xDE2F024C _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
