- changed milestone to Implementer's Draft
Implicit - Tony Nadalin's review comments
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)
-
-
reporter I filed issue
#741to 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.
-
reporter - changed status to resolved
Fixed
#725- Implicit - Tony Nadalin's review comments→ <<cset 50385ad62d5a>>
- Log in to comment