Re: [OAUTH-WG] expired hotk spec

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 <phil.hunt@oracle.com>
>
> https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en