(I'm going to reply to this only on the working group list, since most of the
detail isn't relevant to audiences other than working group members.)
-- Mike
From: [email protected]
[mailto:[email protected]] On Behalf Of Nat Sakimura
Sent: Sunday, October 13, 2013 11:13 AM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [OpenID board] OpenID Connect Specs Nearing Completion
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.
1. 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
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:openid-connect-interop%[email protected]>.
For more options, visit https://groups.google.com/groups/opt_out.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
board mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-board
