Sorry for the lateness; hopefully these comments may still be useful. Overall the draft is very clear and logical.
Sections 3, 4, and 6 refer to the identity selector as a 'mechanism' used by GSS-API to obtain identity information. This is potentially confusing since the identity selector is not a mechanism in the GSS-API sense of the term. Especially since in section 6.5 "...error messages provided by the mechanism may not be helpful enough..." does use 'mechanism' in the GSS-API sense of the term. Section 7.5 says the ui should indicate when an identity is 'currently in use,' but it is unclear to me how that can be determined. The selector knows when it has sent an identity and can be informed when an authentication is successful or fails, but how can it know for how long that authentication remains valid or in use? Implementing sections 7.1, 8, and 9 would require that the GSS-API mechanism report back to the identity selector when the authentication completes. The mechanism needs to provide a unique key which can be used to look up the identity the the selector previously provided at the start of the authentication. Would it make sense for the draft to specify that the NAI alone should be sufficient for this purpose? I.e., that the identity selector MUST NOT store different identities that use the same NAI? There are numerous cases of lowercase "should" thoughout the document. It is unclear whether these ought to be uppercase SHOULD or even MUST. e.g. 6.6.1, 7.3, 7.4 Minor grammar/style nits: 1. "This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency." Awkward. Maybe replace "aims to document" with "addresses"? 7. "This potentially complex many-to-many association between is not easily comprehended by the user" Should be "...between identities and services" 8. "can really effect" should be "can really affect" Kevin Wasserman Painless Security, LLC _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
