[Openid-specs-ab] Feedback to implementators draft

[Torsten Lodderstedt]

Hi all,

I want to give you some feedback regarding the implementators draft 
based on ongoing discussions at Deutsche Telekom and other operators. We 
are currently considering to use OpenID Connect for two purposes:

1) There is an initiative to expose our login capabilities (e.g. based 
on SIM cards) to application developers via an standardized interface. 
For the first phase, we decided to go with OpenID 2.0. For the next 
phase, we are considering to migrate to OpenID connect because of its 
superiour capabilities regarding mobile apps and its alignment with 
OAuth 2.0 (which already is the authorization protocol of choice for 
other Telco APIs).

2) We use OpenID 2.0 with some extensions for session management and 
token handling internally at Deutsche Telekom for our consumer products. 
Clearly, OpenID connect would be the next logical step in order to get 
rid of the propietary stuff and come up with a better OAuth integration.

For both use cases, we think simplicity is, beside security, a critical 
success factor. There are a couple of aspects that currently prevent us 
from adopting OpenID connect and I want to share those with you along 
with some suggestions how to cope with them.

1) Client Basic Profile
In my opinion, the basic client profile should support the 
straight-forward implementation of any kind of application. I currently 
see issues regarding web and mobile apps and would therefore propose the 
following changes:

  1.1) Use grant type code instead of implicit grant
   I would suggest to change the Basic Client Profile to use 
authorization codes instead of the implicit grant. In my opinion, code 
has the following advantages:
   - It is simpler to implement for web applications.
   - It is better suited for mobile apps because of the support for 
refresh tokens.
   - The ability to transmit large user data chunks over a back channel 
instead  of the front channel is beneficially for mobile web 
applications, which most likely run on high latency, low bandwitdh 
network connections.
   - It is more secure due to the transmission of longer-lasting secrets 
via back channels only.

  1.2) Drop the need for signature validation in basic profile
   Because of the direct TLS-protected connection between RP and AS on 
the tokens endpoint, the RP no longer needs to validate the digital 
signature of an id token. This is because the authenticity of the issuer 
is already ensured by TLS server authentication. This would further 
simplify RP implementations and follow the OAuth 2.0 spirit to avoid 
signatures if possible. Clearly, signature validation is still needed 
for all indirect tranmissions of id tokens.

  1.3) Drop nonce from basic profile
   I would suggest to remove nonces from the basic profile and instead 
use TLS and a single-use restriction on authorization codes to prevent 
token replay. This is inline with the defintions given in the security 
consideration section of the OAuth core spec and further simplifies 
implementations.

In §10.12, it is stated that any client must prevent XSRF:

"The client MUST implement CSRF protection for its redirection URI."
"The client SHOULD utilize the "state" request parameter ..."

§10.5 requires:
"Authorization codes MUST be short lived and single use."

and also states TLS MUST be used to protect the redirect endpoints of 
clients, which use OAuth for login functions, which clearly holds for 
OpenId Connect RPs.

"Therefore, if the client relies on the authorization code for its own 
resource owner authentication, the client redirection endpoint MUST 
require TLS."

2) General proposals
Regarding the overall specification, I would like to suggest the 
following changes:

  2.1) removal of checkid endpoint
   As stated above, Id tokens don't need to be verified for direct 
connections. Even if the RP (or any other party) needs to validate it, 
the verification of id tokens is simple given the adoption and 
simplicity of JWT. So I don't see a need for this function.

  2.2) removal of symmetric signatures for id tokens
   I think the spec could benefit from removing support for symmetric 
signatures and support asymmetric signatures, only. RPs (even public 
clients) could validate signatures based on the AS's public key. Interop 
would benefit because of the reduced numbers of algorithms, security 
would benefit because of the limited applicability of symmetric 
signatures (two parties only!). Moreover, dual use of client secrets for 
authentication on the AS (original use case) and creation/validation of 
digital signatures would put to an end.

What do you think?

best regards,
Torsten.