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]>: > 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
