Hallam-Baker, Phillip wrote:
I think the question starts with a false premise, that the security layer
should be in HTTP. Since HTTP is the new IP this makes no more sense than
having authentication at the IPSEC layer.
I think the concept of "THE security layer" is a false premise. There's
no shortage of FPs....
The place for the authentication layer is actually HTML and that is out of
scope.
Actually I think Secure HTML (RFC 2659) died for lack of interest, not
because it was out of scope....
Moreover there has to be deep level support in the O/S if the authentication
layer is going to be robust.
If we take the traditional IETF view of security perfectionism then the only
answer on the table is the WS-* based identity metasystem, CardSpace, Higgins
etc running on top of trustworthy hardware.
If we take a more pragmatic view (I hope we do) then we accept that we have to have something else on tap that we can use now, OpenID has a lot to offer.
Regardless of which view we take it is clear that it would be most beneficial
if the two approaches were to meet in the middle. Starting the tunnel at both
ends at once only save time if the two tunnels actually meet up.
From a security point of view it is clear to me that neither approach has any
bearing on HTTP. Or rather to the extend that it does the bearing is minimal.
So I don't see any real purpose in delaying the advance of HTTP to full
standard.
I think the inevitable dread of the inevitably interminable discussion
of details of indetectable significance among the people who would have
to carry it forward has more to do with its non-advancement than the
missing usable security option....
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf