Subject: [OAUTH-WG] hotk and refresh tokens

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 7 Sep 2012 22:56:29 +0000

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

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Sep 2012 21:19:25 -0300

We already have the assertion profiles for SAML and JWT where you can use a asymmetrically signed token to authenticate the client to the token endpoint for code or refresh.

openID Connect supports that by allowing the client to register a public key as part of getting the clientID.   

In principal you could put the public key in a structured refresh token though I don't know that there is a real advantage to that.

We haven't talked about doing channel binding of a key to the token endpoint yet.  That is a possible extension.for the assertion profile or some other.

John B.

On 2012-09-07, at 7:56 PM, Lewis Adam-CAL022 <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 8 Sep 2012 09:46:54 +0300

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.