Re: [OAUTH-WG] Last Call comments on draft-ietf-oauth-proof-of-possession

Hi Nat,

Per my response to Justin, the title and introduction were revised to address the confusion.  It did not introduce the term “Registered token”, since this isn’t standard terminology that I’m aware of, and would therefore likely cause more readability issues than it would solve.  Use of the “azp” (authorized party) claim is also now described in Section 3 of -03.

                                                            -- Mike

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Tuesday, March 24, 2015 5:47 PM
To: Justin Richer
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Last Call comments on draft-ietf-oauth-proof-of-possession

I tend to agree.

This document is describing the format of (subset of) what I have been calling as Registered token in contrast to a bearer token.

It is currently covering two types of registered token:
- key embedding
- key reference embedding

There can be other types such as
- authorized presenter ID embedding

etc. as well, in which case, you would have a top level member "azp" and no "cnf".

Perhaps a title change to something like "JWT registered token format" etc. may be a good idea.

Cheers,

Nat

2015-03-25 8:31 GMT+09:00 Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>>:
I believe that this draft is misnamed and therefore somewhat misleading: it’s fundamentally a method of protected key transmission using JWT, and not about proof of possession of that key. The proof is in simply using the key to create a JWT within an application (such as will be in draft-ietf-oauth-signed-http-request). Proof of possession of a key does not require the transmission of the key or a direct reference through the client via a data structure, and I don’t want to accidentally give the impression that one needs to use a structured token for proof of possession to work.

For instance, in an alternative approach, the AS can issue a random-blob token to the client along side the key value (as it’s done in this draft), and the client presents the random-blob token to the RS. The RS then looks up the information about the random-blob, using a local lookup or introspection or some other magic, to get the information that it needs. The client doesn’t need to know anything about it, as the token itself is opaque to the client.

That said, overall the structure and function of the draft is good for what it actually is. The client remains agnostic about what’s inside the token itself, as in regular OAuth. It gives semantic processing for an RS to process messages (of various types) signed by keys issued alongside these structured tokens.

I think this problem could be fixed by renaming the draft and rewriting the introduction.

 — Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

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