[Openid-specs-ab] Spec Call note 12-Sep-2013

[Mike Jones]

We'd previously agreed on the calls that once the working group had decided what form the refactored specs would take, I would do the refactoring in a systematic way, being extremely careful that no normative statements were lost in the process.  We will then compare the results of the output of that process with Nat's results as a cross-check that we have the specs that we want.  I believe that this independent refactoring effort is extremely important in order to ensure that we have the highest-quality result as possible - particularly since people will be asked to review the results quickly.

Therefore, despite what was said in the notes below about Nat checking his draft refactored specs into BitBucket, I'd like to request that NAT PLEASE NOT CHECK THESE IN.  They were intended as quickly produced demonstration of the possible refactoring - not the actual refactored specs.  If there's any disagreement with that, please let's discuss that on the list or schedule a short special call for that topic.

Nat, maybe you and I can talk on Skype soon about the details of the refactoring decisions, and I'll get started on doing it.

                                                                Thanks,
                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Edmund Jay
Sent: Thursday, September 12, 2013 11:17 AM
To: openid-specs-ab
Subject: [Openid-specs-ab] Spec Call note 12-Sep-2013

Spec Call notes 12-Sep-2013

Attendees
  Nat Sakimura
  Brian Campbell
  George Fletcher
  Justin Richer
  Roland Hedberg
  John Bradley
  Edmund Jay



Agenda
  Spec Refactoring
  Planning for Final Draft
  New Issues
  Unsolicited authentication flow using ID Tokens



Spec Refactoring
  Some members prefer the monolithic version with all components in one place. Reference lookups are easier.
  Monolithic version may be too long with too many features, but it may be solved by having a separate
  authentication document and keeping the monolithic document as the full version.
  It has a perception problem of being overly complex.
  A version with chapters/partitions may alleviated the perception.
  The spec needs a roadmap/guide for specific features.
  Different profiles for OpenID Connect can be produced once a definitive normative spec is finalized. Current specs
  have a synchronization problem.
  The sentiment of the group seems to be in favor of the monolithic spec.

  Nat asked whether the current ordering of the code flow and implicit in the monolithic version should be switched.
  The group decided to keep the current order of code flow before implicit flow.

  People should review the refactored specs at http://nat.sakimura.org/2013/08/27/refactoring-openid-connect-drafts/
  Nat will add the refactored version to Bitbucket and add it to the issue tracker for reported problems.



Planning for the Final Draft
  There is not much time if the group is planning to finalize the spec by the end of December.
  Roland, Justin, John have volunteered to do detailed review.
  Even though JWS/JWE hasn't been finalized, there should not be normative impact on the specs.


New Issues
  #870 - Standard 3.2.1. Refresh Token Response - return of id_token prohibited, conflicts with Messages 2.2.3
      It has been decided that an ID Token can be returned from the token endpoint for grant types other than
      authorization_code
      This is part of the synchronization problem between current specs.
      It's decided that normative fixes to the current specs will continue in parallel with the new refactored specs.


Unsolicited Authentication Flow using ID Token
  Zendesk/Salesforce and others are starting to use ID Token for IdP initiated SSO for parties with pre-established
  relationships.  Some security requirements may be skipped because they may be mitigated by out of band means.

  The current specs does not allow this. ID Tokens must include a nonce if the ID Token is returned in the front
  channel. Nonce requirement can be soften by changing it to a SHOULD and including some extra security considerations.
  Current specs are focused on a request and response protocol.  It does not specify responses in cases where there are no requests.

  Justin/George feels that this is not OAuth anymore. It should start with OAuth as the base with other protocols built on top of it.
  OpenID Connect should not change to accommodate foreign(SAML) concepts.

  We should have a separate document that details how to perform authentication with ID Tokens but is not part of OpenID Connect.
  John will post to the list with this decision.

  Will also need to develop a response to the question of why others are using this alternative IdP initiated login instead of OpenID Connect itself.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130912/9ac54fd5/attachment.html>