[Openid-specs-ab] Connect Working Group Meeting at Google 22-Oct-12

[Mike Jones]

Connect Working Group Meeting at Google 22-Oct-12

Attendees:
Tim Bray - Google identity team - developer facing
Naveen Agarwal - Google identity tem
Mike Jones - Microsoft identity standards and policy team
Brian Campbell - Ping Identity
Chuck Mortimore - Salesforce
George Fletcher - AOL
Adam Dawes - Google identity team
Breno de Medeiros - Google identity team
Chunlei Niu - Google identity team
Axel Nennker - Deutsche Telekom
Andreas Leicher - Novalyst IT
Mike Schwartz - Gluu
Scott Kern - Identity at Verizon
John Elkaim- BlueID
Alex Chong - Verizon
Brian Berliner - Symantec, personal
Morteza Ansari
Edmund Jay - Illumila
Tom Brown
Greg Keegstra - Janrain
Lucy Lynch - Internet Society
Amanda Anganes - Mitre
Justin Richer - Mitre
Johnny Bufu - Janrain
Don Thibeau - OpenID Foundation executive director

IPR Reminder
Introductions
Agenda Discussion

Session Management
               Session management open issues
                              #650 Session - Dependency on Third Party Cookies
                                             Agreed that no means to fix this, short of new browser technology
                              #605 Session Sec 2 - op_logout_url description
                                             Needs clarification in the spec
                              #634 Session 5 - Re-redirection to RP after the OP logout, or no redirection logout
                                             Agreed that need continue URL, including possibility of continuing if user chooses not to logout
                              #635 Session - 4.1 Format of hash and salt
                                             Lots of discussion - to be continued at IIW
               Breno gave an overview of Session Management
               They want all validation to occur within the OP frame

#595: Discovery 2 - No means of discovery without web server for domain
               Possibilities:
                              DNS based solution
                                             Can be hard for administrators to do
                                             Can be hard for clients to use - DNS lookup may not be available
                                             A lot of DNS registrars don't expose SRV records
                                             Agreement that this is not a viable solution
                              Broker aggregator
                                             Delegate to trusted third party
                                             Somewhat analogous to Account Chooser
                              Domain prefix
                                             simple-web-discovery.example.com or
                                             simple-web-discovery.well-known.example.com
                                             Agreed that we should publish a SWD draft with this approach

#604: All - Create a MTI section
               OpenID request object for claims requests MTI
               RSA signing mandatory to implement
               Johnny said that this effectively makes discovery MTI
                              John Bradley said that cert could be communicated out of band
               Justin and Tim said that discovery and registration are needed for "cold boot" case
               Discussion moved to the distinction between the "open" case and the "cold" case
               We agreed that the userinfo endpoint is required for the open cases and optional for the closed case
               Breno said that we may want a discovery error saying that static registration is required
               People didn't think that requiring signing the userinfo response
               OPs can ignore acr if they don't understand it
               preferred_locales is MTI, in the sense that it must not throw an exception

#633: Messages - 4.2 JWK and X509 format support
               OPs must support X.509
               We should work with JOSE to ensure that self-signed certs are supported

#601: Standard - No way of doing IdP initiated login defined
               Justin proposed a flow that adds an OP -> RP message that then starts the normal login flow
                              Breno said that that mitigates session fixation attacks but not XSRF attacks
               John proposed to just send a response message (like SAML)
                              It would have a special state value saying that this is an IdP-initiated login
               Breno pointed out that the security details matter

#668: Messages,Multi Response - Cope with bloating id_token_hint in self-issued cases
               People still don't like having another OAuth response_type
                              They thought that multiple id_token response types was worse
               Chuck suggested a profile for push messaging to the phone to retrieve claims
               People agreed that the current solution is at least a local maximum, and to leave it as-is

#636: JWT - intermediate audience claim
               Breno proposed a requested audience parameter
               Google's ID tokens contain an audience and a client_id
                              The requested audience is used to request a different audience than the client_id
               This is rooted in the fact that most providers require the client_id for web and mobile clients to be different
                              Breno suggested we may need rules for when it's safe to accept an ID token issued to a mobile client
               John asserted that this is a bad pattern
               We will discuss this more at IIW

#539: Messages - 0. Add scope for offline access
               We adopted George's proposal
               We invite continued review

#656: Discovery - 4.2 Provider Configuration File does not specify what optional parameters the server accepts
               We do want optional functionality to be discoverable

#653: Registration - 2.1 policy_url SHOULD be displayed?
               Justin added that if you can't trust the source of the privacy URL, it doesn't add any value
               We will leave this a SHOULD
               Naveen said that the policy URL should be different from the terms of service URL

#628: Discovery 3.2 - need a strict JSON structure
               This pertains to the different layers of MTI
                              In the "open" case, some parameters will be required
                              Chuck suggested different terminology than "open"
                                             Amanda suggested possibly "dynamic"
                                             Lucy suggested "negotiated"
                                             John suggested "out-of-band"

#667: Registration - Restructuring
               This seems OK

Sessions to hold at IIW:
               Session management parameters
               On-behalf-of / delegation
               Hybrid applications (mobile applications with a web back end)
               Intermediate audience claim / multi-level application security
               IdP initiated login
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121023/4541f6d7/attachment.html>