Hi Zhou,
On Sep 10, 2012, at 12:32 PM, [email protected] wrote: > > Hi, Hannes, > > > The Client and the Resource Server need to obtain this session key somehow. > > Only two mechanisms exist: > > > > a) Key Transport > > b) Key Agreement > > > > Here a key transport based mechanism is used and that's not uncommon. > I have no doubt about that. > My concern is may be there are some better ways to do proof-of-posession, > or proof-of-knowledge of keys. > For example, as I wrote in the review of draft-tschofenig-oauth-security-00: > client send H(R) in token request to AS, AS includes the H(R) in the token, > and client sends (token,R) to RS, > RS can verify the access capablity by recalculating H(R) and checking access > toekn, > by feature of hash, RS can trust R provider,this method does not use > pre-shared key between AS and RS. I am sure that we can come up with many different protocols; the area of key agreement protocols isn't necessarily a new one. (What by the way is "H(R)" standing for?) > > > > > > > Since distributing shared keys between AS and RS is already a > > cubersome work, > > > sending key to client implies the key is only one time thing, that > > will further increase the complexity. > > > > > An authentication and key exchange protocols is a complex thing. > > No doubt about that. > > But Oauth is aimed at simple solutiion and better user experience. > An AKE and be complex, but some AKE can be simpler than others, depending on > requirements. > "simple" is a common but often misunderstood concept in the design of protocols. With the increasing number of security properties we want to provide the solution will get more complex. And it is important to keep in mind that user's don't get to see anything thing about this. I even expect normal application developers not to get exposed to these details either. Ciao Hannes _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
