Hi Igor Thanks for explanation. Unfortunately I am more confused. How does the third party know who the Client is?
I don't understand how an Access Token plus a signing secret gives any more assurance than an Access Token unless I get the Access Token from a different place than the signing secret. Is that what I am missing? -- Dick On 2010-03-12, at 11:38 AM, Igor Faynberg wrote: > Dick, > > The trick here is THE THIRD PARTY (referred to in the last words of Eve's > message), who is effectively a witness to the transaction. (This works pretty > much like when you want to switch your telephone provider. You would be > transferred to the third party to confirm your request.) Absent of the > private-key signature, this is the only known way to ensure non-repudiation. > > Igor > > Dick Hardt wrote: >> >> On 2010-03-12, at 10:22 AM, Eve Maler wrote: >> >>> This nets out to the requesting party (person or company seeking access) >>> having an incentive to say "It's really me accessing this", such that it >>> mitigates the risk that the requester (client) will hand off both the >>> access token and the signing secret to a third party. >> >> Note I am NOT a security expert, and would appreciate an education on where >> I am wrong. >> >> When I look at this, I question if there really is that much more value in >> the Client having two secret items over one secret item. >> I can see an advantage with something like using RAS, in that only the >> Client should have the private key, and if the private key can be used for >> lots of things, then there is some difference between a token and the >> private key. With symmetric keys, multiple parties have the keys, so >> non-repudiation is not possible. >> >> -- Dick >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
