[Openid-specs-ab] Connect Working Group Meeting at Google 22-Oct-12
Nat Sakimura
sakimura at gmail.com
Tue Oct 23 12:02:17 UTC 2012
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>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 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
>
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
> 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/20121023/e3f191f2/attachment.html>
More information about the Openid-specs-ab
mailing list