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

Sun Sep 15 18:27:15 UTC 2013

yes

Am 15.09.2013 20:06, schrieb 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 
> <mailto: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 
>> <mailto: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/20130915/ee85ffd4/attachment.html>