[Openid-specs-ab] Notes: F2F Meeting at AOL, 7 October 2011

Mike Jones Michael.Jones at microsoft.com
Tue Oct 18 06:02:42 UTC 2011

Pam's notes from today's working group meeting.  Thanks, Pam!

From: Pam Dingle [mailto:pdingle at pingidentity.com]
Sent: Monday, October 17, 2011 6:13 PM
To: Mike Jones
Subject: Notes: F2F Meeting at AOL, 7 October 2011

OpenID Connect Working Group Meeting

17 Oct 2011


  *   John Bradley
  *   Mike Jones
  *   George Fletcher
  *   David Cox
  *   Axel Nennker
  *   Nat Sakimura
  *   Edmund Jay
  *   Don Thibeau
  *   Yutaka Oiwa
  *   Boku Kihara
  *   Tatsuya Hayashi
  *   Nov Matake
  *   Amanda Anganes
  *   Justin Richer
  *   Jay Unger
  *   Kevin Marks
  *   Thomas Hardjono
  *   Markus Sabadello
  *   Henrik Biering
  *   Drummond Reed
  *   Allen Tom
  *   Joni Brennan
  *   Leif Johannson


  *   Plan for Implementers Draft Vote
  *   Open Issues/Resolution
  *   Report on Interop Status
     *   Discovery & Registration Implementations
  *   Choose which specs to take to Implementers Draft
  *   Tentative timeframe


Google Group:  openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>


DCR - Dynamic Client Registration

Open Issues:

  *   (DCR) Authentication to Dynamic Client Registration Endpoint
     *   Suggested: make a Protected Endpoint w/ Public Access (Optional)
     *   Agreed - John to make edits
  *   (DCR) Need commentary on expected usage in Registration
     *   No minimum requirement
  *   (Messages) PAPE Parameters (no open issue -- only discussion)
     *   Max Auth Age
     *   Auth Types
     *   Auth Time
  *   (DCR) Bearer Request w/ no Token
     *   Endpoint can either be an OAuth protected resource
     *   -OR- an unprotected resource
        *   Can it be the same URL, if Bearer parameter included you get something different from what you get if no Bearer parameter
        *   Suggestion: leave out Bearer header for public
        *   Note: caching ramifications must be discussed
  *   Specifying Encryption
     *   More spec work to go - possibly also in registration
     *   Assigned to John, Nat, Mike to propose resolution
     *   Should a client be able to specify that they want a combination of signing and encryption?
        *   Easier at registration time than at API access time
        *   Assume that if you're asking for encryption for anything, you will ask for encryption for everything...
  *   Serialization for JWT
     *   Concern about parsers expecting JSON and getting JWT
     *   Spec says the content type of application/jwt should be sent.  It is in the spec but not registered
     *   Mike to register a new Content type for JWT
  *   Difficulty of deploying .well-known deployments
     *   SWD allows static redirect file
     *   Question about issuer matching
     *   Nat to file an issue
     *   Justin to take a stab at improving text in section 4.3 of Discovery
  *   Document Structure
     *   Some Duplicated Content - especially between Standard and Messages
     *   Cross References
     *   Issuer, audience, other SAML/identity jargon sprinkled in without explicit context
     *   Goal:  go through documents and replace duplicates with cross-references
     *   Agreed - no document renaming or reorganization will happen before Implementers Draft
  *   PPID Scope
     *   Nat to write an issue - Standard section 4.3.1
     *   Agreed to remove PPID scope, but keep in request object
     *   Need to specify how to get an PPID as part of request
  *   Token Endpoint Authentication
     *   Need an asymmetric method to authenticate
     *   Duplicated text in messages and standard
        *   OAuth 2 says negotiate out of band and register against client id
        *   We will extend the token endpoint authentication mechanism
           *   Create another authentication mechanism
              *   JWT with claim of code, signed with key, included as bearer token
              *   ie Authorization: Bearer xxxxxx <-- client auth in header
           *   ours will only have additional parameter: id_token
           *   allow an authorization method that takes a bearer token
           *   will be part of the dynamic client registration spec
           *   John will write text
  *   OAuth 2.0 Multiple Token Response Types
     *   Discussion on motivation, reasons for decision.  No open issue.
  *   What specifications to take to an Implementers Draft:
     *   Session     <---- No
     *   Basic          <---- Yes
     *   Standard   <---- Yes
     *   Messages <---- Yes
     *   Discovery <----- Yes
     *   Registration <-- Yes
        *   Justin noted that UMA dynamic registration has some more mature features
        *   Thomas, John Justin will form a committee to take a look at whether current Registration spec could be improved by incorporating ideas from more generic OAuth dynamic registration efforts.  But strong agreement to keep it simple.
     *   OAuth 2.0 Multiple Token Response Types  <---  Yes pending notification of Paul & Breno
        *   Document separate from main OpenID specs, but also published on openid.net/specs
        *   OAuth process for registering response types exists
        *   Process requires that a document be published in some stable place - hence need to make spec an implementer's draft
  *   Dependencies:
     *   JOSE - will include JWS, JWE, JWK <-- no action necessary here
     *   Looking for standards home for JWT, SWD
  *   Reviewed approximately 40 issues in the issue tracker, closing approximately 20 issues.
  *   Tentative goal for proposed implementers draft set for  Friday October 28, 2011
     *   Implementers draft vote:  early December
     *   45 day membership comment period for Implementers Draft

IP Agreement

     *   The following agreement was read to the room:

There are folks present who haven't signed a formal Contribution agreement with OIDF.

OIDF is NOT going to ask you to do that, but we think it is important to be explicit about IP relationships.

Please note the following understandings and agreements associated with your participation n these meetings.

1.  You aren't required to provide feedback.

2.  If you provide feedback, you (on behalf of yourself and any organization that you represent) are deemed to agree that:

3.  Feedback license - You give OIDF the right to use your feedback and comments.  Specifically, you grant to OpenID Foundation a perpetual, irrevocable, non-exclusive, royalty-free, worldwide  license, with the right to directly and indirectly sublicense, to use, copy, license, publish, and distribute and exploit the Feedback in any way, and to prepare derivative works that are based on or incorporate all or part of the Feedback for the purpose of developing and promoting OpenID Foundation specifications and enabling the implementation of the same.

4.  Also, by giving Feedback, you warrant that you have rights to provide this Feedback

5.  Please note that Feedback is not treated as confidential

6.  You also acknowledge that OpenID Foundation is not required to incorporate your Feedback into any version of an OIDF specification

Statement ends here

     *   nobody indicated that they were unable or unwilling to comply with the terms as read by Don Thibeau and as notated on the openidconnect Event description.
     *   Everyone in the attendee list was present when the agreement was read except for:
        *   Allen Tom, who has signed an IPR agreement.
        *   Joni Brennan, who has signed an IPR agreement.
        *   Leif Johannson, who verbally agreed after the fact

Pamela Dingle  |  Sr. Technical Architect
PingIdentity  |   www.pingidentity.com<http://www.pingidentity.com>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: 303-999-5890   M: 303-999-5890
Email: pdingle at pingidentity.com<mailto:pdingle at pingidentity.com>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud

Connect with me
Twitter: @pamelarosiedee

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

More information about the Openid-specs-ab mailing list