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

Mike Jones Michael.Jones at microsoft.com
Wed Oct 24 07:06:04 UTC 2012

Sorry you weren't able to make it as well.

For #633, only X.509 is MTI for servers.  Chuck and Brian, among others, felt that for the next several years, while there is readily available tooling for generating and maintaining keys in X.509 format, the same will not be the case for JWK keys.  This would, in practice, require another step of generating keys using openssl, etc. and then translating the key format, which seemed unnecessary.

For #668, there was substantial discussion of the possibility of mitigating token bloating by introducing a userinfo token and another set of response_type values.  People felt that they'd rather have the bloat, even in the hint case, than introduce that additional complexity.

Several people said that ideally, self-issued would use a general mechanism (not OpenID or OAuth specific) to let RPs fetch the UserInfo content directly from the phone.  Once such a mechanism is developed (if it ever is), they felt that OpenID Connect should use it to retrieve the UserInfo content.  Until then, the (bloated) ID token seems like the best available solution in the meantime.

For #653, no validation rules were discussed.  Instead, the discussion centered on the fact that we have to trust OPs and RPs to do the right things with respect to privacy anyway, and if they're not trustworthy in that way, they can't be relied on to display the policy_url in the first place, so a MUST would add no practical value.

Yes, it seems like people would like to define a tos_url.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Tuesday, October 23, 2012 5:02 AM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Connect Working Group Meeting at Google 22-Oct-12

Sorry that my connection did not work and could not join.

Several questions inline:
On Tue, Oct 23, 2012 at 9:52 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Connect Working Group Meeting at Google 22-Oct-12

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
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
                              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<http://simple-web-discovery.example.com> or
                                             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

Only X.509, or both X.509 and JWK?

#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

So, I was expecting some clarification on login_hint text to mitigate bloating id_token problems. Was there any discussion on it?

#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

Looking forward to.

#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

Was anything about validation rule talked about?

               We will leave this a SHOULD
               Naveen said that the policy URL should be different from the terms of service URL

So, does this mean that we create another claim tos_url ? I think we should.

#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

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

Nat Sakimura (=nat)
Chairman, OpenID Foundation

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

More information about the Openid-specs-ab mailing list