[Openid-specs-ab] openid-connect-implicit-1_0-06 review

[Mike Jones]

These issues have been addressed.  See https://bitbucket.org/openid/connect/issue/725/implicit-tony-nadalins-review-comments for additional comments on the questions raised.

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike Jones
Sent: Monday, January 28, 2013 12:15 PM
To: Anthony Nadalin; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] openid-connect-implicit-1_0-06 review

I've created http://hg.openid.net/connect/issue/725/implicit-tony-nadalins-review-comments to track these review comments.

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony Nadalin
Sent: Friday, January 25, 2013 10:22 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at 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?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130202/3e3ca5e0/attachment.html>