I guess I figured it out. H(R) is the hash of a random number. The issue with this approach is that the Client can only use the Access Token once with your approach. Of course, one could extend the approach to a hash chain and then disclose the reverse hash chain.
Still, this approach requires that the hash chain is bound to the access token in some way and this requires a key. In general, to secure the Access Token it is necessary to protect the token anyway (for other reasons as well). While I like these hash chain proposals (and I have seen these already back in the Mobile IPv6 days) I don't think they make anything simpler in the end. I prefer to go for a well-established scheme On Sep 10, 2012, at 12:32 PM, [email protected] wrote: > 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. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
