Re: [dix] Agenda bashing

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
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix