[Openid-specs-ab] OpenID Connect Specs Nearing Completion

Sun Oct 13 18:13:14 UTC 2013

Thank you very much, Mike.
It is a great work. Having said that,

I have some comments on it.

   1. The terminology section is not assuming the agreed upon structure as
   in
   http://nat.sakimura.org/wp-content/uploads/2013/08/openid-connect-all-1_0.html
[1].
   Note that the order of the terms in [1] is not alphabetical but in the
   semantic order: i.e., the term that is used in the text appears before it.
   Also, it is separating out the definition text and the notes. That is
   adding to the readability of the text greatly. It is also showing where it
   came from.
   2. The agreed upon structure is much less deep. It was one of the main
   consideration in restructuring. It is adding to the ease for grasping the
   structure. For example, in your version, it is
"2.2.2.1.1.<http://openid.net/specs/openid-connect-core-1_0-13.html#ImplicitRequestParameters>
   Authorization Request Parameters" while in [1], it is "3.1.1.  Request
   Parameters".
   3. As to the order of the request parameters are concerned, I have
   placed 'scope' at the top since it acts as the switch between OpenID call
   and pure OAuth call. This would definitely help the user when writing the
   code.
   4. For the definition of 'scope', I change the text as follows to make
   it clear that it is stating about the value.

   REQUIRED. The value MUST contain the openid. This scope value requests
   ID Token, which is a JWT that includes the Claims about the End-User
   Authentication event.

   Your text is:

   REQUIRED. Space delimited, case sensitive list of ASCII OAuth 2.0 scope
   values. OpenID Connect requests MUST contain the openid scope value.
   Other scope values MAY be present. See Sections
4.1<http://openid.net/specs/openid-connect-core-1_0-13.html#ScopeClaims>
    and 10<http://openid.net/specs/openid-connect-core-1_0-13.html#OfflineAccess>
for
   additional scope values defined by this specification.

   Here, at least "Space delimited, case sensitive ... " is superfluous
   since it is already defined in RFC6749. The former also describes the
   effect of this scope, while the later does not.
   5. This version still has claims authorization components in 2.1.2.4.
   6. The "4. Claims" is not describing only about what is claims but also
   how the claims are to be requested and received. That's why [1] is using
   the chapter name "Claims Framework." I think this title is more
   appropriate, and has been agreed upon in the WG.
   7. Accordingly, the description about this chapter should also be
   strengthend. Your version states:

        This section specifies how the Client can obtain Claims about the
   End-User and defines a
        standard set of basic profile Claims.

   while [1] states:

   This section defines a framework in which the client may obtain the
   claims about the End User. It can be done through the pre-defined scopes
   values or through more granular claims parameter. The claims can come from
   a single source or distributed sources as well.
   The later, IMHO, is clearer.

   8. Again, "4. Claims" is not assuming the order of the agreed upon
   structure. 4.5 should be moved before 4.2.

Regards,

Nat

2013/10/13 Mike Jones <Michael.Jones at microsoft.com>

>  I posted this note at http://self-issued.info/?p=1137 and on Twitter as
> @selfissued to raise awareness that the time to do a final review of the
> OpenID Connect specs is now.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *OpenID Connect Specs Nearing Completion*
>
> ** **
>
> Based on feedback from developers, the OpenID Connect<http://openid.net/connect/>working group decided to replace the OpenID
> Connect Messages<http://openid.net/specs/openid-connect-messages-1_0-20.html>and OpenID
> Connect Standard<http://openid.net/specs/openid-connect-standard-1_0-21.html>specifications with a new OpenID
> Connect Core <http://openid.net/specs/openid-connect-core-1_0-13.html>specification that combines the contents from both of them before finishing
> OpenID Connect.  The content has also been restructured to separate
> Authentication from other features such as Claims and to have separate
> Authentication sections for the different OAuth 2.0 flows.  No changes to
> the protocol were made.  The publication of this new spec is another major
> step towards finishing OpenID Connect.****
>
> ** **
>
> *Please review this and the other OpenID Connect specifications in the
> coming week.*  While a few local changes will still be made this week to
> address issues that have been identified<https://bitbucket.org/openid/connect/issues?status=new&status=open&sort=-id>since the
> approval of the Implementer’s Drafts <http://self-issued.info/?p=1095>, I
> fully expect that the working group will decide at the in-person working
> group meeting <http://openid-wg-oct-2013.eventbrite.com/> just over a
> week from now that it’s time to publish proposed final specifications.****
>
> ** **
>
> Thanks to Nat Sakimura for producing a proof-of-concept document
> restructuring<http://nat.sakimura.org/2013/08/27/refactoring-openid-connect-drafts/>that the structure of the current OpenID
> Connect Core <http://openid.net/specs/openid-connect-core-1_0-13.html>spec is based upon.  And thanks to Torsten Lodderstedt for convincing us
> that the specs will be clearer by better separating the descriptions of
> logically distinct features while combining previously separate
> descriptions of highly interrelated functionality.****
>
> ** **
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenID Connect Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openid-connect-interop+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131014/1eedbf5b/attachment.html>