Pete, > So, from the conversation so far, these are the architectural/protocol > issues I think need discussing at the BOF: > > - Discussion of the scope and number of the mechanisms. There seem to > be desires for (1) the ability for the user to identify to the server > (probably authenticating, preventing phishing as much as possible), > (2) the ability to transfer user attributes to the server, (3) the > ability to store user attributes remotely, and (4) the ability for a > 3rd-party to warrant user attribute claims.
On point (1) in order to fix phishing it is the server that must properly authenticate to the user (e.g., other way round). > > > - Discussion of the pros and cons of mechanisms that involve changes > to the user agent versus mechanisms which rely on a separate identity > server to do all of the work without changing the user agent (e.g., DIX). > > - Discussion of the types of authentication mechanisms to be used. (I > read Ben as saying it should be a general mechanism not tied to HTTP, > Eliot and Terry as saying that the underlying mechanism should be > common but that there should be HTTP-specific protocol, and John as > having no interest in solving that particular problem. :-) ) The focus needs to be on commonality. We want to avoid having to do this for each and every protocol separately. Using something like SASL would be ideal. I will not be present in Montreal, but I am very interested in the problem space, and may propose solutions in the coming months. Eliot _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
