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>:

> 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
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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