Hi, Hannes, Thank you for the clarity. Yes, it makes sense. Then http-mac and hot-sk are quite similar. Why do redundant work?
Hannes Tschofenig <[email protected]> 写于 2012-09-10 16:06:34: > Hi Zhou, > > here is the story. > > The Authorization Server gives an Access Token to the Client and the > client presents that Access Token to Resource Servers. > This has not changed in comparison to Bearer Tokens. > > However, in addition to just presenting the Access Token by the > Client to the Resource Server the Client also needs to compute a > keyed message digest on the access request to the protected resource. > > It needs a key to compute the keyed message digest. > > This key, called MAC key, is provided by the Authorization Server > together with the Access Token. > > What is not said in the document is how the Resource Server obtains > the MAC key from the Authorization Server. It is assumed to be shared somehow. > > Hope that makes more sense. > > Ciao > Hannes > > > On Sep 10, 2012, at 10:57 AM, [email protected] wrote: > > > > > Hi, > > > > I have a question concerning draft-ietf-oauth-v2-http-mac-01： > > The propose is that Client obtains MAC credentials (i.e., MAC > keys) from Resource Server first, then Client genertate MAC access > token using MAC keys, and send MAC access token to RS, RS > recalculates MAC access token to verify the validity, right? > > But in Section 5.1 it says the Authorization server issues the > MAC access token. > > I am totally lost, > > if AS to issue MAC access token, then for RS to verify, the > MAC key should be shared between AS and RS, Client don't have to know them; > > if RS to issue MAC access token, then it is not conforming to > OAuth 2.0 framework. > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
