[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-0001.html>


More information about the Openid-specs-ab mailing list