Hi Adam, when the HOTK draft was submitted as an individual contribution the group started a debate about the requirements for an enhanced security solution. This had let of a high level presentation at the last IETF meeting. Phil volunteered to produce a document that captures the threats and the requirements.
Last week that document was published here: http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ As such, it would be good to figure out whether the aspect of a refresh token is something that can be casted as a requirement (if it is not already in the current writeup). Ciao Hannes PS: On your specific question from below my impression is the following. The public key is bound to the access token, authorization scope, and to the specific client / resource server. When a new access token is requested then the binding is renewed and the new access token will be bound to the new access token unless the client provides the same public key again. Currently, there is no way for the Authorization Server to create it's own public / private key pair (for usage by the client) since at the time of writing there was no functionality specified in the JOSE group to send private keying material around. This has changed in the meanwhile with a recent contribution from Mike. On Sep 8, 2012, at 1:56 AM, Lewis Adam-CAL022 wrote: > Hi, > > What are the plans for the OAuth HOTK draft with respect to refresh tokens? > Section 4.3 says that a new public key can be bound to a new access token > using a refresh token grant, but it would be nice if the refresh token could > also use the public key such that when using the refresh token as a grant > type to get a new access token, the AS could receive the same security > robustness with the RT as the RS does with the AT. > > John, I think you mentioned something along these lines at CIS, but it was > late at night and my memory is foggy. > > Either way, the current draft does not discuss. Is this something that will > be included in future versions? > > > -adam > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
