[Openid-specs-ab] openid connect specs review

[Nat Sakimura]

This is a note that records the decisions made at July 7 Spec Call.
This for the HTTP Redirect Binding.


On Thu, Jul 7, 2011 at 9:29 AM, Johnny Bufu <jbufu at janrain.com> wrote:

> Hello spec editors,
>
> I've given a close read to the following specifications. Below are comments
> about parts that I've found unclear or confusing, and questions for which I
> didn't find answers in the specs and would hold me back if I were to
> implement them.
>
> Thanks,
> Johnny
>
>
> ------------------------------**------------------------------**----
>
> HTTP Redirect Binding (draft 01 / June 30, 2011):
>
> 3.1.  Authorization Code Flow
>
> "the party that receives message MUST verify it according to the
> verification rule set in OpenID Connect Core 1.0 [OpenID.CC] and OpenID
> Connect Framework 1.0 [OpenID.CF]."
>
> There are no rules defined in Core.
>
>
Language in the Framework is not clear around id_token response. Clarify.

Probably needs id_token be in the core, because id_token is required to make
the core work. Talk to Breno.



> 3.1.1.1.  Query Parameters Method
>
> Which HTTP methods are allowed? Being a HTTP binding profile I would
> expect, as an implementer, to find this answer here.
>

Define methods for each endpoints. Edmund.

>
> 3.1.1.1.1.  Client sends a request to the Authorization Server
>
> "any other valid means of directing the User-Agent to the URL" is ambiguous
> and open-ended, a HTTP binding specification should define what's
> acceptable.
>

Delete valid. Edmund.


>
> scope: "openid" is missing from example.
>

Add it.


>
> 3.1.1.2.  Request Parameter Method
>
> "The JWT object MAY be signed or signed and encrypted via JWS [JWS] and JWE
> [JWE] respectively, thereby providing non-repudiation and/or security of the
> request."
>
> Non-repudiation is only one of the main benefits provided by signatures,
> while "security" is a too-generic term. I would suggest:
> "providing authentication, integrity, non-repudiation and/or
> confidentiality"
>

Accept.


>
> And again, the allowed HTTP methods should be specified.
>

As above.

>
> The second example should be replaced with the actual JWT (as the comment
> there says).
>

Add footnote.


>
> 3.2.5.1.  End-User Grants Authorization
>
> Core defines only code, token, none as acceptable response_type values,
> which would suggest that id_token would then be unacceptable. (See also note
> on Core/Section 3.1.1)
>
> Also, I couldn't find where "id_token" is listed as possible/acceptable
> value for the response_type parameter, and what its meaning would be.
>
>
As above.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110708/ed6ef65f/attachment.html>