Some comments to the draft[1] to invigorate the discussion: [1] https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/
*3.1. Binding a Key to an Access Token* ======================================= *3.1.1. Symmetric keys* ---------------------- The server is creating a symmetric key and returning it from the token endpoint. So, this is only doing the token endpoint - client - resource binding. Should we not do the entire flow starting from the authorization request? Re: Editor's note: My vote is to bake the key into the access token and encrypt it with the resource server's public key as discussed below. *3.1.2 Asymmetric Keys* --------------------- The same comment as symmetric case: Should we not start from the authorization request? On access token: why just an example? Should we not prescribe it completely? Or are we just talking about the "within a same security domain" stuff? I feel like hotk field should contain only one key. If it expires, we can get another token. Do we really need kid then? *3.2. Accessing a Protected Resource* ====================================== *3.2.1 Symmetric keys* ----------------------- Is it assuming that the resource server can pull the key from the authz server? If the resource and the server is in a different security domain, you would not want to do this. As stated above, we should bake the key into the access token and encrypt it with the resource server's public key. *3.2.2 Asymmetric keys* ---------------------- Let's not require TLS Channel Binding. It is hard right now. Let's do something simpler. FYI, I posted http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-01that shows the flow starting from the authorization request to the resource access. It has been sitting on my laptop for a long time (like Aug. last year...) It has been very incomplete so I did not post it before but just posted it today to facilitate the discussion. Cheers, Nat 2013/11/4 Phil Hunt <[email protected]> > > https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/ > > Phil > > @independentid > www.independentid.com > [email protected] > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
