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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
