[Openid-specs-ab] Feedback to implementators draft

Sun Apr 1 16:26:37 UTC 2012

Hi Thorsten,

Thanks for your detailed input.

Having implementers drafts is intended to encourage implementers to build and give us this sort of important feedback.

Responses in order:
Basic client:
1.1)
We have gone back and forth several times on if the basic client profile should be code or implicit flow based. 
The implicit flow as basic comes from David's original Connect proposal.  

Part of the idea was that RP care deeply about response time.  That delivering the id_token in the front channel allows for faster customization of the user interface.
The downside is that in practice sending a id_token in the front channel and then having the client send that to the check_id endpoint is slower than sending code and getting a id token directly from a trusted endpoint where you can avoid signature verification.

So you have a good point in cases where the client is not doing crypto code is faster, code is also better optimized for mobile devices where bytes through the device have a much higher latency and cost.

I think the implicit flow is still needed for JS apps.  Perhaps a compromise would be making basic code and moving implicit to a specific JS client profile.

1.2)
No disagreement there in the original AB spec we had the assertion coming from the token endpoint for that reason.  The client can just base64url decode the id_token, no crypto is required for basic.

1.3)
The part of the OAuth spec that requires TLS for the client redirect endpoint if oath is used for authentication is relatively new and cryptically worded.  Some of us missed the intent.  Thanks for pointing that out.
Given that and an agreement that code is single use, and time limited, I am OK with removing it from a code flow basic, however I think it needs to say as an option in Messages for use in other flows where replay protection of 
the id_token is a issue.    We need more discussion on the security implications of this.   I would like to hear what Breno thinks on this.

2) If we move to a default code flow the check_id endpoint could go, as the other flows are largely motivated by JS clients who need a asymmetric signature on the token to verify it without a extra network call.  Speed being one of the main points of getting the token in the front channel in the first place.

3) Given the above changes,  the symmetric signature is probably not going to get much use.  As the person who did the verification rules for tokens,  removing symmetric, or making it a separate extension for people who really want it for some reason would simplify the main spec a lot.   I agree that overloading the client_secret for both the client authorization to the token endpoint and the Auth Servers authentication to the client is a high cognitive burden on many people.   It also allows clients who want authenticate to the token endpoint using the Assertion profile rather than http basic to not bother with any client secret,  simplifying life for some.

I should point out that these proposals are not a breaking change for the Authorization server other than changing the default id_token signature.
It is however a breaking change for the current Basic Client.  Eliminating the check_id endpoint would break that.   

With the appropriate registration e.g. registering wanting a asymmetrically signed token type the current specs allow for exactly what you are proposing as the new Basic Client Profile.  
It might be worth getting some clients of that design implemented so we can do a real back to back comparison of the implementation complexity.

On the Spec side removing things always makes the spec smaller so your proposals are likely to win on that account.

If others think Thorsten's ideas have merit, want to test them, or have other suggestions please speak up.

Regards
John B.

On 2012-03-31, at 5: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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120401/95e130e9/attachment.p7s>