Re: [OAUTH-WG] expired hotk spec

Nat Sakimura <> Wed, 06 November 2013 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 279E421E80B6 for <>; Wed, 6 Nov 2013 11:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NzvUHxPvadJz for <>; Wed, 6 Nov 2013 11:10:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::234]) by (Postfix) with ESMTP id A03FF21F9CC2 for <>; Wed, 6 Nov 2013 11:10:43 -0800 (PST)
Received: by with SMTP id y6so81954lbh.11 for <>; Wed, 06 Nov 2013 11:10:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9MUqJy9pQfTm9uJ4A0T2w7hDge4CFxSUAhWpoGJKMI=; b=YfcgUU2iwPTRt6JBhRQNs+E2+Au+ILcprid79OXknqR8pQVTMyjr/nHHeUs5/VL0Ez uS+5w37UUCimsRpUbWhaVvT4RLvffJ4oPWqOq0CN1NLkQZU48tGIXUYk51HRIkbMsQFV 2ThosoUC7pQj3VKYcvrOLwpopimGPSu37KX2Md6Q4EceGJIdRuy6T3MCxzpseEDe+uXg mry6PWsv3w34DlkI6mNTkKB7UC2m1q20ZwZE9X3V9NE+tfFsa7YGwHVdNiZALyrAL8ih 5Bv+k+J7oZuLEEpZbja/upV10Qaf2663FGGa3GZ/zhadb8eC94a3UV+JMax/89Q9T1Hw 8pHA==
MIME-Version: 1.0
X-Received: by with SMTP id l6mr3767254lbo.5.1383765042615; Wed, 06 Nov 2013 11:10:42 -0800 (PST)
Received: by with HTTP; Wed, 6 Nov 2013 11:10:42 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 6 Nov 2013 11:10:42 -0800
Message-ID: <>
From: Nat Sakimura <>
To: Phil Hunt <>
Content-Type: multipart/alternative; boundary=001a113366bcd15d0804ea86e78b
Cc: " WG" <>
Subject: Re: [OAUTH-WG] expired hotk spec
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2013 19:10:45 -0000

Some comments to the draft[1] to invigorate the discussion:


*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
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
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
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.



2013/11/4 Phil Hunt <>
> Phil
> @independentid
> _______________________________________________
> OAuth mailing list

Nat Sakimura (=nat)
Chairman, OpenID Foundation