Hi Justin,
-03 was renamed to "Proof-of-Possession Key Semantics for JSON Web Tokens
(JWTs)" to eliminate this confusion. The introduction was also revised to
address related points of confusion.
Thanks again for your review comments.
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Justin Richer
Sent: Tuesday, March 24, 2015 4:31 PM
To: <[email protected]>
Subject: [OAUTH-WG] Last Call comments on draft-ietf-oauth-proof-of-possession
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
