Implicit - Tony Nadalin's review comments

Issue #725 resolved
Michael Jones created an issue

From: openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of Anthony Nadalin Sent: Friday, January 25, 2013 10:22 AM To: openid-specs-ab@lists.openid.net Subject: [Openid-specs-ab] openid-connect-implicit-1_0-06 review

Section 2.2.1 1. Not sure what RFC the Authorization Endpoint should use for HTTPS ? RFC 2818? If so should also be listed. 2. Response_type there is nothing in the core that indicates that there might be more that a single value here since it’s just response_type, seems overloaded to me Section 2.2.3 1. Should state that TLS needs to be used and point the reader to section 2.3 in RFC6749

Section 2.2.4 1. Seems odd to have this in an implicit flow since in an implicit flow the end-user is not authenticated

Section 2.2.5.1 1. expires_in – how do you know what this is relative to?

Section 2.3 1. “the following claims are required” but then some optional ones are listed, so the heading is wrong

Section 2.3.1 & 2.3.2 1. Validation does not say what to do if there is a failure 2. Why can’t one use ES256?

Section 2.4 1. This seems to be in opposition to section 1.6 in RFC6749

Section 2.4.2 1. Does not say how the response is to be returned, secure or not? Are all the members returned and ones that don’t have values are null? Or is it assumed if they are not returned they are null?

Comments (3)

  1. Michael Jones reporter

    I filed issue #741 to track your comments on 2.2.3 and 2.2.4.

    Per your comment on ES256 - it can be used and the spec has a pointer to how it can be.

  2. Log in to comment