Hi Zhou, On 09/11/2012 06:10 AM, [email protected] wrote: > > > > > > > > The example of asymmetrical key is flawed. Without trust (e. > > g. Certificate) implemented, Client can use any pk/sk generated by > > itself to confirm > > > its knowledge of sk. > > > > It is perfectly fine but there are obviously lots of details > > missing. If you look at http://tools.ietf.org/html/draft-tschofenig- > > oauth-hotk-01 then see the details. > > it says in *draft-tschofenig-oauth-security-00* that "When the Client > requests an access token the Authorization Server creates an ephemeral > public / privacy key pair (PK/SK) and places the public key PK into the > protected token." > --- AS selects the Pk,sk, and sends sk, pk to Client > in draft-tschofenig-oauth-hotk-01, it says Client includes pk_info in > request, it implies sk,pk are chosen by client.
That's correct. The approach changed in the two versions. The issue was the following: if the Authorization Server creates the ephemeral key pair then it has to also send the private key to the client. Since I wanted to re-use only available mechanisms this was not possible since http://datatracker.ietf.org/doc/draft-jones-jose-json-private-key/ didn't exist at that time. > > They are different. And selecting pk,sk by client is reasonable. > But how pk and access token are bound ? The Client sends the PK to the Authorization Server when it requests the Access Token. The Authorization Server then binds the PK to the Access Token. Ciao Hannes _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
