Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

Thanks for the feedback Justin. Do you have any specific wording?

On Tue, Jul 18, 2017 at 6:34 PM Justin Richer <jricher@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.Jones@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!