[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 Session Management.

On Fri, Jul 8, 2011 at 3:07 AM, Johnny Bufu <jbufu at janrain.com> wrote:

> Hi John,
>
> On 11-07-06 08:30 PM, John Bradley wrote:
>
>> Thanks for the feedback.
>>
>
> Found the Session Management spec which covers some of the questions I had
> about the ID Token, but is not linked from any of the documents I've
> explored previously - it should be referenced from Core, I think.
>
> Following is a review of it.
>
> Johnny
>
> ------------------------------**------------------------------**----
>
> Session Management (draft 00 / June 29, 2011)
>
> 2. Terminology
>
> Client definition overloaded, Core terminology already references OAuth.
>

Remove.


>
> Client Servlet is not defined


Define. Serverside client?


>
> ID Token has two definitions.
>

Unite.


>
> 3.  Session Management
>
> "In addition, session management for fourth parties such as desktop, native
> or mobile applications that utilizes authorization server credentials at
> fourth party web sites are also supported."
>


> Grammar needs to be fixed here. Semantic is unclear: who are the fourth
> parties - desktop/native/mobile apps, web sites mentioned later, both
> groups?
>

Confirm with Breno and fix.



>
> 3.1.4.2.  Implicit Flow Response
>
> "when response_type includes id_token, an ID Token MUST be returned in the
> response."
>
> Where is the ID Token added? Query parameters or fragment?
>


> The example includes the access token as a query parameter, contrary to the
> referenced OAuth 2.0 / Section 4.2.2 (which says it should be added to the
> fragment).
>

Clarify.
Must be returned in the fragment of the response.



>
> The example misses the required token_type parameter.
>

fix


>
> 3.1.5.4.  Token Access Response
>
> "The request format is defined in section 4.1.4 of the OAuth 2.0 [OAuth2.0]
> specification."
>
> Should say "response format".
>

Accept.


>
> 3.1.6.1.  Browser Load
>
> "The client servlet then gets an ID Token that is session synchronized with
> the authorization server."
>
> "session synchronized" should link to the corresponding section (reading
> through this section I had no idea what was meant by it, or that an
> explanation was following).
>

Clarify. Link.


>
> Also consider moving the Session Synchronization up in the document.
>
> The "session synchronized" attribute of the ID Token could be asserted by
> the OP and part of the ID Token (rather than requiring clients to keep track
> of it separately).
>

Accept.


>
> 3.2.1.  Refresh Session
>
> "In a typical HTTP binding, an HTTP 302 redirect to the specified
> redirect_uri in the request with a new ID Token."
>
> Grammar needs to be checked (missing predicate).
>

Fix.


>
> How is the new ID Token returned? Added to the query parameters or
> fragment, or either?


Query.

>
>
> ------------------------------**------------------------------**----
> ______________________________**_________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.**net <Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/**mailman/listinfo/openid-specs-**ab<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>



-- 
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/905a88b3/attachment.html>