Subject: [OAUTH-WG] HOTK/POP/etc drafts

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 24 Apr 2014 15:14:10 +0000

Hi,

Lots of crypto drafts on OAuth popping up that I need to come up to speed on.
draft-bradley-oauth-pop-key-distribution-00<http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/>
draft-hunt-oauth-pop-architecture-00<http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/>
draft-jones-oauth-proof-of-possession-00<http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/>
draft-sakimura-oauth-rjwtprof-01<http://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/>
draft-sakimura-oauth-tcse-03<http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/>
draft-tschofenig-oauth-hotk-03<http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/>

Glad to see all the work, but is there a preferred reading order here?  Which ones build on each other vs. which ones are out there on their own?

-adam

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Apr 2014 13:02:24 -0300

The overview document is draft-hunt-oauth-pop-architecture-00

For the client requesting POP tokens and key draft-bradley-oauth-pop-key-distribution

For how to include the proof key info in a JWT (more generic than just access tokens) draft-jones-oauth-proof-of-possession

The draft-sakimura-oauth-tcse spec is older and is about symmetric proof keys for code when using public clients, and not directly related to the new docs.

The draft-tschofenig-oauth-hotk is how to use the pop AT at the RS.  It needs some updating to align with  draft-jones-oauth-proof-of-possession but is the general idea.

I am going to do a version of draft-sakimura-oauth-tcse using asymmetric proof keys for discussion on how you could start with a public client generating a key-pair and tying the public key to code, refresh and access tokens. 

> draft-sakimura-oauth-rjwtprof was a discussion document for the WG.

These are all independent drafts at the moment.  The WG will look at them and decide how it wants to proceed with WG drafts, that may or may not be based on these.

We are still trying to decide what sort of sausage to make.

John B.

On Apr 24, 2014, at 12:14 PM, Lewis Adam-CAL022 <[email-masked]> wrote:

> draft-bradley-oauth-pop-key-distribution-00
> draft-hunt-oauth-pop-architecture-00
> draft-jones-oauth-proof-of-possession-00
> draft-sakimura-oauth-rjwtprof-01
> draft-sakimura-oauth-tcse-03
> draft-tschofenig-oauth-hotk-03
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 18:40:05 +0200

Hi Lewis,

good that you ask.

In the London IETF meeting we have proposed a plan on how to proceed
with the proof-of-possession (PoP) work.

John had already explained that the main document is
draft-hunt-oauth-pop-architecture-00. It pains the big picture and
points to the relevant documents, in particular to
 a) draft-bradley-oauth-pop-key-distribution
 b) draft-jones-oauth-proof-of-possession
 c) a not-yet-published HTTP signature mechanism.

(a) explains how the client obtains keys from the authorization server.
(b) describes a mechanism for binding a key to the access token.
(c) illustrates the procedure for the client to interact with the
resource server (based on the PoP mechanism).

These documents replace prior work on draft-ietf-oauth-v2-http-mac-05
and draft-tschofenig-oauth-hotk-03.

We are getting closer to have all relevant parts published.

Ciao
Hannes

On 04/24/2014 05:14 PM, Lewis Adam-CAL022 wrote:
> <http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/>
> 
> <http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/>
> 
> <http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/>
> 
> <http://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/>
> 
> <http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/>
> 
> <http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/>
> 
>  
> 
> Glad to see all the work, but is there a preferred reading order here? 
> Which ones build on each other vs. which ones are out there on their own?
> 
>  
> 
>  
> 
> -adam
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 21:42:22 +0200

Btw, the HTTP signature mechanism now also got published as
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01

I think we now have a pretty good collection of documents to look at.

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 25 Apr 2014 09:42:49 +0100

Hi Hannes

Is the MAC token effort you were leading still on the map ?

Thanks, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Apr 2014 11:23:23 +0200

Good question. The architecture allows different mechanisms to be used
for proof-of-possession between the client and the resource server.
With the publication of draft-richer-oauth-signed-http-request-01 we
have a version that uses a JOSE-based encoding. I have not had time to
illustrate how the MAC-based version would fit in there.

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 25 Apr 2014 10:38:57 +0100

> illustrate how the MAC-based version would fit in there.

OAuth2 is very open to supporting all sort of access token types.
Hopefully PoP model will not be made exclusive for JWT only, it won't be 
very OAuth2 friendly IMHO...

Cheers, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Apr 2014 11:44:27 +0200

Hi Sergey,

> very OAuth2 friendly IMHO...

Note that draft-richer-oauth-signed-http-request-01 doesn't use JWTs. I
just uses a JSON-based encoding of the parameters. I put a strawman
proposal into the document.

For the access token there is also no requirement to use JWTs. The use
of a reference only (in combination with the token introspection) is one
possible deployment option (which I still need to add to the overview
document; I put a editor's note in the version of the document I
submitted today).

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 25 Apr 2014 11:08:24 +0100

Hi Hannes
> document; I put a editor's note in the version of the document I

Thanks for the clarifications, actually, 
draft-richer-oauth-signed-http-request-01 is quite cool, perhaps we will 
see the document in time for using JWE for encrypting HTTP payloads too. 
Looks like OAuth2 is going to affect a lot the way HTTP communications 
are done in the future.

Cheers, Sergey