[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
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<http://simple-web-discovery.example.com> or
simple-web-discovery.well-known.example.com<http://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
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>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121024/e5a42691/attachment.html>
More information about the Openid-specs-ab
mailing list