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

Justin Richer jricher at mitre.org
Thu Sep 12 20:04:42 UTC 2013


I'd like to point out something important that wasn't quite captured in 
the notes, and that's that there seems to be general agreement about the 
feature-based restructuring, even within the monolithic document (as 
sections). So we'd still have parts for authentication, claims, json 
requests, self-issued providers, and security/privacy considerations.

I think it's very important that we not lose this (or a very, very 
similar) structure when the final refactoring is done.

  -- Justin

On 09/12/2013 03:58 PM, Mike Jones wrote:
>
> 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.
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

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


More information about the Openid-specs-ab mailing list