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

[Nat Sakimura]

Hi Torsten, 

By section 7 and 8 for monolithic version, do you mean request by JSON and self issued? 

=nat via iPhone

Sep 16, 2013 2:52、Torsten Lodderstedt <torsten at lodderstedt.net> のメッセージ:

> Hi all,
> 
> I've got some feedback on the refactored specs.
> 
> modular version: 
> In my opinion, part 6 shouldn't stay as a separate document because the topics covered there are required for particular modules. For example, "OpenID Connect – Part 2: Authentication Implicit" needs text on signature validation. Right now, it only describes validation of the at_hash. Understanding signature validation will also require text on signatures in general, which can be currently found in part 6/section 4. 
> I therefore suggest to mix contents of part 6 into the respective functional documents. If part 1 is getting THE base spec, sections 3, 6, and 7 and parts of 8 should go into this document. Section 11 could be moved to another document, probably covering profiles as well. 
> 
> The monolithic version is really big (62 pages in A4)! If we decide to go for this version, I would suggest to move sections 7 and 8 into another document.
> 
> regards,
> Torsten. 
>  
> Am 12.09.2013 20:16, schrieb 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.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> _______________________________________________
> 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/20130916/53dde817/attachment.html>