Ben, I use "nonrepudiation" according to its meaning: starting from the reasonable assumption that a user has not compromised his/her own secret/token (e.g., password, smart card), you can prove that it is very, very probable that a given message was sent/signed by the user.
I'm not interested in any "legal" concept of nonrepudiation. I am interested in the inferences that a security technology allows the parties involve to make. For example, if I were the manager of a group of people who access a sensitive system using, I would want the authentication system to allow me to be very sure of who sent each message to the system. Then I could reasonably enforce this policy: "Protect your credentials, because I will assume that messages signed by your private key are from you and will revoke your privileges if I think you have behaved inappropriately." Charles (Dylan) On 12/9/09 8:24 AM, "Ben Laurie" <[email protected]> wrote: > On Tue, Dec 8, 2009 at 12:55 AM, David Recordon <[email protected]> wrote: >> Hey Dylan, >> Yes, this is correct but Google could also start sending email as me >> or even fill in forgotten password pages and then login as me. :) >> >> This is one thing which is known to be a challenge to see OpenID scale >> into higher levels of assurance. The ultimate answer for these sorts >> of use cases is not only the user trusting their provider, but the >> relying party having some form of trust in the provider as well. > > That's only one ultimate answer. Another is for the user to sign stuff. > > BTW, I wish people would not use nonrepudiation in this way - you can > always repudiate a digital signature. Nonrepudiation is a legal term - > it means that the law doesn't _care_ if you repudiate it. > > >> >> --David >> >> On Mon, Dec 7, 2009 at 4:47 PM, Shearer, Charles Dylan <[email protected]> >> wrote: >>> I have some concerns about OpenID, and I would like to see what those >>> involved think about them. >>> >>> It seems to me that, regardless of how OpenID is deployed, it is always >>> possible for an OpenID provider itself to authenticate with a relying party >>> as any user by forging a request to authenticate using the user¹s >>> identifier. This is because a relying party cannot tell the difference >>> between a user attempting to log in using his or her identifier, and the >>> user¹s OpenID provider spoofing that user to gain access to whatever >>> services the relying party provides to that user. This seems to require >>> that both users and relying parties put a lot of trust in OpenID providers: >>> for example, if I used my OpenID identifier for online banking and email, my >>> OpenID provider could easily access my email and bank account. >>> >>> Additionally, even if we assume that OpenID providers will not log into >>> users¹ accounts, I still cannot see how OpenID could provide nonrepudiation >>> regarding messages sent to a relying party by an authenticated user: for >>> example, if I authenticate with my bank using my OpenID identifier and then >>> use the bank¹s ³bill pay² service to pay a bill, there¹s no way the bank can >>> prove that I ordered that payment because it is possible that someone >>> working for my OpenID provider logged in as me and ordered it. >>> >>> Does anyone disagree with my analysis? >>> >>> Dylan >>> _______________________________________________ >>> security mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-security >>> >>> >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
