[OAUTH-WG] -00 of draft-bradley-stateless-oauth-client

[Brian Campbell <[e-mail]>]

Some musings on
http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00

Abstract: "... allowing for fully stateless operation." --> saying that the
statelessness is on the AS side might avoid some confusion. The client is
still going to have to maintain state.

The kid is header rather than a claim.

"The issuer SHOULD sign the JWT with JWS ...  issuer MAY encrypt the JWT
with JWE." --> this text seems a little off given that the most common
case, I'd think, would be an AS who issues these client id JWTs only for
its own consumption using JWE's AES_CBC_HMAC_SHA2 which gives encryption
and integrity protection.

Does the relationship between the "iat" and "exp" claims here and the
"client_secret_expires_at" and "client_id_issued_at" parameters of dyn reg
need to be explained or explored more? Strikes me as potentially
problematic.

And what happens when one of these JWT client ids expires or needs to be
updated? Or the keys used to create or verify them expire? I know the
answer thus far has been that the client will just have to get a new one.
But I feel like that might be too limiting in practice. I'd like to further
pursue understanding/defining how these kinds of client ids might be used
in conjunction with a longer lived way to identify the client that allows
the client id (i.e. the metadata) to change but can allow correlation
across such changes (the sub claim in this doc even suggests that a client
might have such an identifier).

As was pointed out in another review, there's a difference between
documenting how it's possible for an AS to issue "stateless" client ids for
its own use and defining something that allows for some other party to
issue such ids. It may make sense to discuss them in the same document but
I believe it'd be valuable to have the doc acknowledge and address the
difference more.