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

[Edmund Jay]

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