>>>>> "Pete" == Pete Resnick <[EMAIL PROTECTED]> writes:
Pete> EKR's note seems to have sparked discussions in the right
Pete> - What problem does this address that isn't addressed by a local
Pete> "keychain" or information database on the client? (For example,
Pete> possible answers include: "The problem of not having to change the
Pete> local user agent" and "The problem of portability".) What's the
Pete> downside if we don't solve those problems?
First, I think there is IETF work to do even if all we are doing is
working with W3c to recommend best client practices.
However I think that providing portable identities that meet ekr's COC
critera and that do not increase risk of phishing requires IETF work.
I believe that the same mechanisms that give us COC can give us CRC
and HRA.
Pete> - Does the mechanism use or extend currently deployed web
Pete> authentication mechanisms (client side and server side)? If not, why
Pete> not?
My proposal at least does.
Pete> - Is the client able to decide which identifying information goes to
Pete> the server?
In my proposal, yes in a limited form. This can be expanded over
time. I wanted to bite off a small chunk to start from. While this
is supported, I hope future work increases the granularity of client
control.
Pete> - Does the mechanism involve 3rd parties for authentication or
Pete> identifying info? Does the 3rd party need to be trusted by the relying
Pete> party?
My mechanism does. The third party is delegated a portion of a
namespace. The third party can produce credentials for any identifier
in that namespace. The third party needs to be trusted as much as the
most trusted identity that the RP currently accepts in its namespace.
Pete> - Does the mechanism use a format for the information that has widely
Pete> available implementations?
Yes.
Pete> - Are you using a mechanism to authenticate the information that has
Pete> widely available implementations?
I do not understand this question.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
