[Openid-specs-fapi] Issue #93: Not clear why AS needs to support signed+encrypted ID Token (openid/fapi)

Nat Sakimura issues-reply at bitbucket.org
Sat May 6 19:06:53 UTC 2017

New issue 93: Not clear why AS needs to support signed+encrypted ID Token

Nat Sakimura:

There are two reasons for asking for it.
1) To cope with the internal attacker after TLS is terminated;
2) To cope with the man-in-the-browser when ID Token is returned in the
front channel.
In many cases, TLS are terminated at gateways. Since about 50% of
attacks comes from the internal network, non-TLS traffic within the LAN
is at risk of being eavesdropped. Encryption helps with these cases.
ID Token in the front channel works as the detached signature for the
authorization response, so it is indispensable for the protection of the
authorization response payload, but it is not protected by TLS within
the browser so the eavesdropper in the browser can actually see it if it
is not encrypted.
Do we care about these threats? Since the token is signed anyway, the
risk is primarily a passive one thus it should not be too high even if
we did not encrypt after all.
Perhaps we should change "shall" to "should" so that it will be: 
- should support signed and encrypted ID Tokens;

More information about the Openid-specs-fapi mailing list