[Openid-specs-ab] Spec Call note 12-Sep-2013
torsten at lodderstedt.net
Sun Sep 15 17:52:50 UTC 2013
I've got some feedback on the refactored specs.
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
Am 12.09.2013 20:16, schrieb Edmund Jay:
> Spec Call notes 12-Sep-2013
> Nat Sakimura
> Brian Campbell
> George Fletcher
> Justin Richer
> Roland Hedberg
> John Bradley
> Edmund Jay
> 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab