Thanks for the feedback Justin. Do you have any specific wording? On Tue, Jul 18, 2017 at 6:34 PM Justin Richer <jric...@mit.edu> wrote:
> Mike et al, > > Overall, this document has some really great advice for people who have > chosen to use JWT in various situations. It’s a needed draft and I’d like > to see it go forward. I have some suggestions on how it can be improved. > > In this draft, I’d like to see some more discussion about privacy and > security issues around choosing JWTs to begin with. Namely, putting things > like subject identifiers and scope/permission information into the JWT > structure could potentially leak information about the end user to the > client, if the JWT isn’t encrypted, and to multiple RS’s, if the JWT is > encrypted with a shared key. It basically amounts to “anyone who can read > the JWT can see what’s in it”, which on the one hand is obvious, but on the > other hand it’s not always considered by implementers. Since the audience > of an access token JWT is the RS and not the client, and the token is > opaque to the client, it’s easy to assume that the client *won’t* read the > token. However, that doesn’t mean that it *can’t* read the token. It’s a > tradeoff in design space with other solutions. > > I’d also like to see a discussion on expiration and revocation of > self-contained JWT access tokens. Again, this is targeting the decision > space of whether or not a self-contained token is an appropriate solution > in the first place. If I’m issuing JWTs that are completely self-contained, > I can’t revoke them once they’re on the wire. Yes, that’s an acceptable > risk to many and that’s fine — but I would like this document to encourage > that thought and discussion. > > Thanks, > — Justin > > On Jul 4, 2017, at 3:43 PM, Mike Jones <michael.jo...@microsoft.com> > wrote: > > The JWT BCP draft has been updated to describe the use of explicit typing > of JWTs as one of the ways to prevent confusion among different kinds of > JWTs. This is accomplished by including an explicit type for the JWT in > the “typ” header parameter. For instance, the Security Event Token (SET) > specification <http://self-issued.info/?p=1709> now uses the “ > application/secevent+jwt” content type to explicitly type SETs. > > The specification is available at: > > - https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 > > > An HTML-formatted version is also available at: > > - http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html > > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=1714 and > as @selfissued <https://twitter.com/selfissued>. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
