[Openid-specs-ab] Feedback to implementators draft

[Justin Richer]

+1 to making the Basic client use the authz code flow and moving 
implicit off somewhere else. I again contend that it makes sense for 
Facebook, who want to host the callback URL for you, but not for other 
people.

-1 to dropping signature check requirement -- this fits a "trust but 
verify" pattern and allows for a pretty simple way to implement security 
in depth, especially when coupled with the checkid endpoint.

Ambivalent on nonce -- it's simple enough to implement in a client, 
though the "state" parameter almost takes care of it for you.

-1 to dropping the checkid endpoint -- unless it's in favor of a more 
generic "check the token with the AS" endpoint, which is what's starting 
to be talked about over in the OAuth WG.

-1 to dropping symmetric signatures. They're defined under JWS, which is 
pulled in by reference, so I'm not sure I see the value in cutting out 
the capability from Connect.

  -- Justin

On 03/31/2012 04:43 PM, Torsten Lodderstedt wrote:
> 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.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab