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:[email protected]] On Behalf Of Nat Sakimura
Sent: Tuesday, March 24, 2015 5:47 PM
To: Justin Richer
Cc: <[email protected]>
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
<[email protected]<mailto:[email protected]>>:
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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
