What I meant by "most basic level" was storage and transfer of attributes asserted by the user. You could design a DIX protocol where that is the only service provided. In that case, there is no need for verification. From their responses, I think both Dick and Rob agree with this.
To summarize: a DIX protocol could be defined that allowed the signature to be optional in the Exchange Process. This protocol would support transfer of self-asserted attributes. The Verification Process would not be required. This eliminates the need for the membersite to communicate with an arbitrary (untrusted?) homesite, and eliminates a potential DoS problem.
I know that there are many times that attributes cannot be self-asserted. Carl Ellison made the case for that many years ago in his SPKI proposals - and I'm sure he wasn't first or last to do so. In those cases, it's clearly important to determine who made the assertion, whether they can be trusted, and whether the assertion is valid. Verification will be necessary in this case. However, as Phillip pointed out, a DoS problem is not likely to last very long in this case. The membersite will just stop trusting the homesite to make assertions.
Terry Hayes
AOL Corp.
-----Original Message-----
From: Robert Yates <[EMAIL PROTECTED]>
To: Digital Identity Exchange <[email protected]>
Sent: Thu, 09 Mar 2006 22:26:41 -0500
Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0)
From: Robert Yates <[EMAIL PROTECTED]>
To: Digital Identity Exchange <[email protected]>
Sent: Thu, 09 Mar 2006 22:26:41 -0500
Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0)
[EMAIL PROTECTED] wrote:
> The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting?
> > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way.
> > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite.
> > Can we agree that for this level of requirement, the signature and > verification are not required?
Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc.
A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step.
I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url.
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
> The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting?
> > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way.
> > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite.
> > Can we agree that for this level of requirement, the signature and > verification are not required?
Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc.
A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step.
I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url.
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
