18:01:58 <dolphm> #startmeeting keystone
18:01:59 <openstack> Meeting started Tue Apr  2 18:01:58 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:02 <openstack> The meeting name has been set to 'keystone'
18:02:17 <dolphm> #topic RC3
18:02:45 <dolphm> we cut RC3 this morning with the db engine/connectionpool issue fixed, along with termie's patch to v3 auth
18:03:11 <dolphm> we have two more days in grizzly but it looks like RC3 will ship as grizzly unaltered (no RC4)
18:03:37 <dolphm> basically anything else triggering a new RC has to be a critical issue
18:03:38 <topol> congrats!!!
18:03:41 <ayoung> Keysteon!
18:03:46 <ayoung> Keystone!
18:03:51 <bknudson> did you consider this one: https://bugs.launchpad.net/python-keystoneclient/+bug/1161633
18:03:54 <uvirtbot> Launchpad bug 1161633 in tempest "V3 token fails with KeyError 'expires'" [Undecided,In progress]
18:03:54 <dolphm> grats everyone :)
18:04:05 <dolphm> bknudson: clients are not held to the release cycle
18:04:10 <bknudson> ok
18:04:13 <dolphm> bknudson: we can push a new version anytime, and will be doing so soon
18:04:20 <dolphm> that's my next priority before the summit
18:04:26 <EstevaoHessHP_> #info   Hello everyone, For clients changes, is it also needed bluepirnts?
18:04:44 <dolphm> EstevaoHessHP_: it's a looser process, but yes, we have blueprints for keystoneclient
18:04:52 <dolphm> https://blueprints.launchpad.net/python-keystoneclient/
18:04:58 <ayoung> dolphm, did you "global engine everywhere" patch pave the way for doing in memory sqlite for all of the tests?
18:05:13 <dolphm> ayoung: yeah, that was the original goal
18:05:17 <EstevaoHessHP_> Thanks Dolphm
18:05:23 <dolphm> #topic State of LDAP in Grizzly
18:05:49 <dolphm> so, i don't have that much insight into ldap proceedings / what's lacking / etc
18:05:49 <bknudson> is anyone planning to use the LDAP backend?
18:05:56 <dolphm> so i was hoping our ldap crew could chime in?
18:06:06 <ayoung> bknudson, UI would expect so
18:06:12 <dolphm> bknudson: absolutely
18:06:20 <ayoung> aside from the amount of work CERN did early in the release on AD issues for LDAP
18:06:41 <ayoung> we have a significant effort from the IBMers on making LDAP a first class citizen Id Provider
18:06:49 <spzala> I have code up for review for roles grant to ldap group #link https://review.openstack.org/#/c/25329/
18:06:52 <dolphm> i'm primarily asking because any problems need to be reflected in https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Known_Issues_5
18:06:59 <henrynash> topol, comment?
18:07:12 <bknudson> are we going to provide migrations for anyone using LDAP in G to H?
18:07:15 <ayoung> spzala, that is ready to go?
18:07:26 <ayoung> bknudson, I think we are going to have to
18:07:33 <ayoung> at a minimum, for p[eople using the default schemas
18:07:35 <spzala> ayoung: Yes, I think so.
18:07:47 <dolphm> bknudson: yes
18:07:49 <topol> so doing double duty, slow to respond. but if necesary we should provide migrations
18:07:50 <spzala> ayoung: I tested with ldap live test and that went well.
18:08:00 <ayoung> bknudson, the way we are doing domains for Grizzly is under review, and will most likely change in H
18:08:01 <dolphm> a document, if not an automated approach
18:08:29 <ayoung> spzala, looking at Roles patch now
18:08:41 <spzala> ayoung: cool. Thanks!
18:08:43 <dolphm> with rc3, could a havana ldap deployment use v3? or would you need to remove ldap from the pipeline?
18:09:11 <ayoung> spzala, BTW,  I am not going to recommend holding up the release for it, but we can certainly try to get it backported to Grizzly Stable.
18:09:12 <dolphm> or is it only new grizzly features that aren't implemented (grant role to user on domain?)
18:09:31 <spzala> ayoung: I have also added in today's agenda about possible redesign approach for ldap domain in Havana.
18:09:42 <dolphm> ayoung: it's far too late for new features to land in grizzly
18:09:57 <ayoung> dolphm, oh, yeah
18:10:19 <ayoung> dolphm, so here's the short on the Havana Domains thing
18:10:23 <spzala> ayoung: OK, that sounds great to me.
18:10:34 <ayoung> right now, domain is an attribute on just about everything
18:10:44 <ayoung> and the attribute we are using is...suspect...
18:10:53 <ayoung> it is a misappropriation
18:11:10 <ayoung> but domains indicate a higher level of separation anyway
18:11:19 <ayoung> and the LDAP way is for each domain to be in their own subtree.
18:11:25 <spzala> ayoung: we have businessCategory for domain_id attribute.
18:11:33 <ayoung> so, for a single domain deploy, G and H will look roughly the same
18:11:51 <ayoung> fo a G deploy with two domains, we will have to port one of them to a separate subtree
18:11:59 <ayoung> spzala, yep.
18:12:03 <dolphm> ayoung: is that an issue with grizzly, or is that just a non-ideal compared to the plans for havana?
18:12:19 <ayoung> dolphm, this is the plan for Havana
18:12:30 <ayoung> in grizzly, we use the attribute
18:12:38 <dolphm> ayoung: for now, i need to know what won't work in grizzly w/ ldap :)
18:12:39 <ayoung> and we will need a migration plan for havana
18:12:39 <spzala> ayoung: yes, about domain specific sub tree, that's what I have tried to have in design for which I have a etherpad link later in the agenda.
18:12:44 <dolphm> the rest is summit-speak :)
18:13:15 <ayoung> dolphm, yep,  I've moved on.  Unless there are fires to put out, I'm not Hunting Grizzlye's anymore
18:13:24 <dolphm> spzala: can you summarize what was implemented here and add it to known issues for grizzly? https://review.openstack.org/#/c/25329/
18:13:50 <dolphm> spzala: assuming it poses a blocker for a grizzly deploy, and it's not a forward-looking feature add
18:14:10 <spzala> dolphm: sure. So this one is mainly granting the role to the ldap groups
18:15:02 <dolphm> so what i want to confirm: v3 + ldap in grizzly has feature parity with v2 + ldap in folsom, correct?
18:15:05 <spzala> dolphm: also I tried to have generic grant for groups and uses as it was designed in the tests
18:15:22 <dolphm> just want to make sure we haven't moved backwards
18:15:27 <ayoung> dolphm, it limits grizzly/ldap usability, but does not completely destroy it.  It would be sad to be missing, and I would argue for putting it into Grizzly stable, but it should not block the release
18:15:41 <dolphm> ayoung: i'm not opposed to seeing that argument
18:16:00 <spzala> dolphm: agree with ayoung.
18:16:02 <ayoung> dolphm, I don't think we are missing anything that was in V2 LDAP in Folsom/
18:16:12 <dolphm> ayoung: spzala: bknudson: henrynash: topol: (and anyone else) if ya'll want to make enough noise to see that patch backported, do it on the mailing list, but you're facing very low adds at this point
18:16:25 <dolphm> ayoung: thanks
18:16:54 <dolphm> #topic Review, revise & amend Keystone's release notes
18:17:05 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Identity_.28Keystone.29
18:17:15 <bknudson> on this topic, sdague posted to openstack-dev ...
18:17:24 <bknudson> sdague: currious what the expected upgrade path is for keystone folsom users is, as the keystone folsom config doesn't seem to work at all with grizzly code
18:17:41 <dolphm> we already touched on this, but go revise release notes :)
18:17:48 <dolphm> i'm sure there are upgrade issues and new features i didn't capture
18:17:54 <dolphm> so add what you worked on!
18:18:02 <dolphm> make sure people know about all our goodness
18:18:07 <dolphm> and related....
18:18:07 <bknudson> sdague didn't say what the problems were.
18:18:14 <dolphm> #topic Grizzly Documentation
18:18:53 <dolphm> openstack-manuals needs some love -- everyone should take a pass through everything keystone related and make sure everything is up to date and that we're not documenting deprecated options, etc
18:19:22 <dolphm> #topic Design summit sessions
18:19:33 <dolphm> #link http://summit.openstack.org/
18:19:36 <bknudson> what's the schedule for the documentation?
18:19:44 <bknudson> does it have to be done at the same time as release?
18:19:58 <dolphm> bknudson: we have about a month window until docs open for havana
18:20:24 <dolphm> i'm happy to hear proponents & opponents of seeing any given session on the agenda
18:20:26 <bknudson> dolphm: thanks... I might have some time at the end of the month.
18:20:47 <ayoung> So..I have a scheduled session on FreeIPA integration that is in the security track
18:20:56 <ayoung> and I am unsure what the state of it is
18:21:07 <ayoung> As it shows up on the schedule
18:21:20 <dolphm> my primary goals in scheduling sessions is simply that there will be an engaging discussion with a useful conclusion impacting the future of keystone dev in havana
18:21:38 <henrynash> dolphm: so I updated http://summit.openstack.org/cfp/details/157 as requested
18:21:51 <dolphm> henrynash: i haven't reviewed yet, but thank you :)
18:21:57 <ayoung> Or at least it was...
18:22:05 <dolphm> ayoung: where are you looking?
18:22:12 <dolphm> i haven't pushed anything to the schedule yet
18:22:16 <dolphm> nor scheduled anything
18:22:21 <ayoung> dolphm, just got a link from our PR person that was tracking it...one sec
18:22:33 <ayoung> dolphm, it happend before you, but maybe it got nixed
18:22:51 <dolphm> ayoung: i think ttx reset some scheduling stuff when he opened it for final scheduling
18:23:03 <dolphm> ayoung: i'm not clear on the details of what happens after the review process
18:23:07 <ayoung> http://openstacksummitapril2013.sched.org/event/02841e3d64620e15b861db63628735bd#.UVsiBeOuI95
18:23:38 <ayoung> But maybe that session is now orphaned.
18:23:59 <dolphm> ayoung: the primary issue with your that session is that it's about how to integrate a tool with openstack, and doesn't concern the development of keystone in havana
18:24:19 <ayoung> Ah...it is scheduled at the same time as a Keystone session, but it is not in the Keystone track
18:24:30 <ayoung> dolphm, right...so here is my thinking
18:24:34 <dolphm> ayoung: final schedule will be settled on April 9th, i'm not sure what sched.org will reflect until then
18:24:58 <ayoung> dolphm, I'll try to get it bumped earlier, so people don't have to choose between Keystone and Security tracks
18:25:16 <ayoung> basically, it ties in with the technology overview
18:25:23 <ayoung> it is easier to say FreeIPA than to say
18:25:33 <ayoung> Kerberos, LDAP, X509 and DNS
18:25:56 <dolphm> ayoung: there's definitely a track for such sessions that would be a better fit than keystone, but i'm not sure what that would be (there's workshops at every summit, but i don't know what they fall under)
18:26:13 <joesavak> o/ sorry i'm late
18:26:17 <dolphm> joesavak: o/
18:26:19 <ayoung> And if affects components beyond just what Keystone does.  For example, looking at securing the Database connections for multiple Keystones talking to one DB
18:26:41 <dolphm> this was a late submission by nsavin -- http://summit.openstack.org/cfp/details/239
18:26:54 <dolphm> (nsavin -- i assume you're not here?)
18:27:23 <ayoung> dolphm, merge with HATEOAS?
18:28:06 <dolphm> i'm happy to see an architecture discussion, but there's no precedence for needing such a session -- this is out of the blue
18:28:26 <dolphm> ayoung: there's a HATEOS session?
18:28:31 <ayoung> dolphm, so the thing about the FreeIPA talk is it ties in with the other talks about security technologies.
18:28:41 <ayoung> dolphm, it is on today's agneda
18:28:56 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:29:10 <dolphm> known issues for summit?
18:29:17 <ayoung> yes
18:29:31 <dolphm> no session was proposed on the topic
18:29:37 <ayoung> just that the SOA and HATEOAS subjects both address organization of the URLS and resources under Keystone.
18:29:54 <dolphm> ah
18:29:56 <ayoung> dolphm, yeah.  We can do a session on it, but we seemed to be full up
18:30:11 <dolphm> ayoung: we're well over
18:30:23 <ayoung> I was OK with continuing the discussion in IRC/mail, as I think that it is sufficient to address
18:30:25 <dolphm> need to cut at least 3 session at this point
18:30:38 <ayoung> we can also have some casual talks between developers over it, but no need to steal an hour for it
18:30:59 <ayoung> I've posted my WIP to get things rolling, and that should suffice, I would think
18:31:05 <dolphm> ayoung: to do -- summit sessions are intended to hash stuff out that has proven to be difficult to discuss/design over email, irc, etc
18:31:40 <dolphm> i'd like to have a regular "keystone unconference" for the days leading up to our track
18:31:46 <ayoung> dolphm, +2
18:32:00 <dolphm> just open floor for a couple days
18:32:09 <joesavak> +1
18:32:25 <ayoung> dolphm, I think the single largest issue we should address is how to move beyond bearer tokens.  The rest is implementation details
18:32:51 <ayoung> LDAP support def needs people to come together to voice their requirments
18:33:11 <dolphm> ayoung: agree, that's a bit of dwaite's session and (as i understand) henrynash's session on generic auth
18:33:54 <dolphm> i assume oauth2 will be the topic of conversation for both those sessions, unless there's a strong argument for another contender
18:34:01 <ayoung> dolphm, there are two sides.  One is using a mechanism that is not yet part of Keystone, but the other is what to do about the current token architecture.
18:34:26 <ayoung> dolphm, oauth1, not 2, if termie has anything to say about it...and I think I agree with him on that
18:34:48 <dolphm> ah, i'm not familiar with the differences
18:34:51 <ayoung> but that is delegation, which doesn't address the fact that current tokens are bearer tokens
18:34:53 <dwaite> I am hoping that there is enough overlap that maintaining the current token architecture is not a headache
18:34:55 <dolphm> and i'm honestly not sure which i've used
18:35:00 <topol> why oaut1 instead of oauth2.  I believe oauth2 is getting good traction
18:35:21 <stevemar> ayoung: +1, that is what i've been been reading about
18:35:31 <ayoung> topol, that needs to be an unconference brawl...er..discussion
18:35:49 <dolphm> "Many services such as Facebook, Github, and Google have already deployed OAuth 2 servers, and deployed implementations win." -dwaite's session http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified
18:35:50 <ayoung> or something
18:36:20 <dwaite> I'd be up for a gentleman's brawl!
18:36:26 <dolphm> the summit should be a brawl, i hope that's clear to everyone
18:36:31 <dwaite> or nerf guns at 20 paces
18:36:39 <zykes-> dolphm: what about OpenID Connect ?
18:36:40 <topol> warren zevon song??? send lawyers, guns and money..
18:36:52 <dwaite> zykes-: what about OpenID Connect in particular?
18:36:53 <ayoung> dolphm, as I have learned, we ignore termie at our peril.  He stated something to the effect that 2 is not a valid replacement for 1....lets just make sure we get on the same page as far as delegation goes
18:37:01 <dolphm> powerpoint slides and polite clapping shouldn't be expected
18:37:17 <ayoung> I personally want to do the foam-rubber larp type sword fighting thing myself
18:37:29 <zykes-> dwaite: nothing in particular
18:37:39 <dolphm> zykes-: dwaite: was openid included/excluded from your talk? if excluded, reason why?
18:37:41 <ayoung> There are a slew of standards to consider
18:37:59 <dwaite> openid 1/2, yes. Openid connect, no.
18:38:12 <ayoung> I think they fall into two camps:  enterprise and web.
18:38:20 <dwaite> I would like to cover it, but I'm trying to reduce scope so there is discussion/brawling time
18:38:46 <ayoung> On the enterprise side is the technologies I'm addressing in the FreeIPA session.  On the Web side we have dwaite 's session
18:38:55 <dolphm> ayoung: +1 on the "let's make sure"
18:39:11 <ayoung> oauth 1,2 SAML, openid, and so on
18:39:14 <dwaite> I am btw very disappointed the Free IPA site does not have a form where I can submit my details to receive beer at no cost
18:39:29 <henrynash> i'd have thought the key thing for us is to agree how we modify keystone to allow the various studs to be supported/plugged in by those who require the,
18:39:41 <joesavak> 1: Saml, 2: OAuth, 3: OpenID, 4: SCIM is my order
18:39:46 <henrynash> studs? I mean standards !!!!
18:39:47 <ayoung> We should remember that AMQP is a fundamental portion of OpenStack and that we need to support non HTTPS technologies
18:40:00 <zykes-> joesavak: OIC then, isn't that OpenID + OAuth2 ? :)
18:40:10 <ayoung> dwaite, no, it is Free and in Free Quid, Guvnah.
18:40:13 <ayoung> as in
18:40:18 <dolphm> henrynash: at the api / project integration level or in implementation?
18:40:21 <joesavak> oauth authZ and openID authN
18:40:36 <joesavak> authZ more important for partner use cases. ; )
18:40:45 <dolphm> henrynash: because implementation is for code review, although working implementations are welcome talking points at the summit
18:40:47 <henrynash> so api/project integration must be first
18:40:53 <dolphm> henrynash: cool
18:41:01 <zykes-> fyi for you guys, check out: https://github.com/rohe?tab=repositories
18:41:03 <ayoung> joesavak, so there is the perpetual session from Kent to remember as well.  Closes the summit once again
18:41:07 <dwaite> OpenID Connect is a profile on top of OAuth 2.0, if we don't get to it in sessions I'll def. unconference it
18:41:19 <joesavak> love it. The only reason why I attend
18:41:23 <joesavak> ;)
18:41:27 <ayoung> http://openstacksummitfall2012.sched.org/event/23f0a08262c18dc00007fea69e97c1f2
18:41:33 <dwaite> I'll get an outline together for next week of the topics to better judge time
18:41:37 <zykes-> A dude at the Ume� university of Sweden that has done alot of work on it fyi!
18:42:04 <termie> dolphm: i requisitioned some custom tools for the summit
18:42:08 <zykes-> better described: "Federation Lab" is a collaboration between some entities about Federation
18:42:13 <termie> dolphm: we'll see whether they are fabricated in time
18:43:33 <dolphm> termie: i'm not sure i should anyone should feel comfortable with your definitions of "tools" lol
18:43:35 <ayoung> termie, the two technologies you've brought up recently are Cassiopea [sp/] and oauth 1.  Anything else that you think needs to be on the agenda?
18:43:44 <dolphm> i or anyone should*
18:43:47 <termie> ayoung: uhhhhh
18:43:54 <termie> ayoung: cassandra
18:43:57 <topol> termie, if beer is made available Im in
18:44:08 <ayoung> right mythos, wrong damsel
18:45:02 <joesavak> lol
18:45:16 <ayoung> And we all know what happens to people that don't listen to Cassandra.  The greeks get 'em
18:45:16 <termie> topol AND savak
18:45:23 <termie> it's all mispelled star trek in here
18:45:24 <dolphm> so i know this is going to take the next 15 minutes up pretty easily...
18:45:28 <dolphm> #topic Discussion/review request for LDAP domain design for Havana
18:45:34 <dolphm> #link https://etherpad.openstack.org/keystone-ldap-domain-support
18:45:41 <dolphm> (not sure who put this on the agenda?)
18:45:45 <spzala> dolphm: I have added this in
18:45:55 <ayoung> dolphm, I thought we covered that already
18:46:03 <joesavak> Savak is correctly spelled star trek.
18:46:10 <spzala> dolphm: this is about a blueprint I am working on for ldap domain support re-design
18:46:11 <dolphm> #link https://docs.google.com/file/d/0Bw37kS-ubhFMdzM5QlVCUGI5ZWc/edit?pli=1
18:46:15 <dolphm> did we discuss that ^ ?
18:46:29 <ayoung> dolphm, yep
18:46:30 <joesavak> er - n/m
18:46:33 <topol> lets make sure. want to get it right
18:47:06 <spzala> thought to have it out mainly for ayoung, henry-nash and all interested parties in LDAP's feedback
18:47:09 <ayoung> topol, this is probably not the forum for it
18:47:36 <ayoung> I think that it is best discussed at the Summit, when we can pull in non-keystone devs with an interest in the LDAP back end
18:47:41 <topol> ayouhng, agreed, but at least people can start looking at it in their copious spare time
18:47:45 <ayoung> and get them to confirm/deny
18:47:52 <topol> agreed
18:48:06 <topol> definitely need stakeholder input from other teams
18:48:10 <ayoung> topol, those of us that know LDAP have already discussed it, and I summarized for the rest.  PLease, all feel free to ask questions.
18:48:20 <topol> OK good
18:48:53 <termie> joesavak: saavik?
18:49:15 <termie> joesavak: there's probably a savak too though, vulcans and their names
18:49:23 <bknudson> this new design requires changes to the ldap schema?
18:49:39 <termie> i bet vipul is one too
18:49:55 <spzala> ayoung: if can please take a look at the doc and tell me that I have put it in a right way, that would be very helpful.
18:50:02 <spzala> ayoung: so that I stay in the right direction
18:50:19 <ayoung> bknudson, let me be specific
18:50:20 <joesavak> can i get someone to look at https://review.openstack.org/#/c/25298/ - RST doc changes for the old 2.0 stuff
18:50:31 <ayoung> in this case, it requires no changes to the schema
18:50:40 <ayoung> it does change the assumptions about the layout
18:50:57 <bknudson> there are ? for domain_id.
18:51:07 <spzala> bknudson:
18:51:11 <ayoung> and it will stop using the businessCategory attribute
18:51:19 <bknudson> Is this meant to match any existing LDAP deployment?
18:51:52 <spzala> bknudson: we have domain_id but with layout change I think it's not needed but I wanted to have it there for feedback
18:52:07 <ayoung> bknudson, I would say that it is meant to match best practices for LDAP, so it is more likely to match an existing LDAP setup
18:53:22 <bknudson> why not ou=default container for the default domain rather than default domain is right under root?
18:53:34 <topol> ayoung, other thing we should do (if not done already) is look at the LDAP support the apache ldap authorization module provides to perhaps steal some best practices from that
18:53:54 <ayoung> topol, good idea
18:53:56 <dolphm> general ldap question: how much of this is configurable in keystone for deployments? what's not configurable or has very little flexibility?
18:53:56 <bknudson> I don't think apache has projects.
18:54:14 <ayoung> bknudson, mod_auth_ldap
18:54:18 <spzala> bknudson: thought good idea to keep it the same way we have in originally for the default in stead of adding a 'default' in the tree
18:54:42 <ayoung> spzala, agreed
18:54:45 <bknudson> there's just some unique things about openstack... it has projects, which other apps don't have.
18:55:07 <dwaite> (five minute warning)
18:55:37 <ayoung> it is unlikely that most people are going to use multiple domains, and for those deployments, we want to keep the tree sane.  However, for multiple domains, we might want to be able to specify the segment for the default domain
18:55:51 <ayoung> I would not hard code it to 'default'
18:56:08 <dolphm> CONF.default_domain_id?
18:56:09 <ayoung> and, it might be that the entire DN chain is different
18:56:12 <bknudson> ayoung: that sounds good to me, the diagram has ou=Users right under root.
18:56:51 <ayoung> dolphm, perhaps, or perhaps we state that domains must be listed in the config file.  We need a way to be able to enumerate them,
18:57:11 <ayoung> I opened this blueprint as a placeholder
18:57:28 <ayoung> https://blueprints.launchpad.net/keystone/+spec/json-for-ldap
18:57:43 <ayoung> we can axe that if it is unnecessary
18:57:58 <ayoung> I suspect that creating a domain will be an unusual activity
18:58:19 <dolphm> ayoung: one step further, it almost makes sense to make the ldap driver an external project...
18:58:22 <ayoung> and I am OK with inflicting a little extra pain upon domain creation for that reason
18:58:35 <topol> so whatever we do, we need to make sure that is a customer only has users and groups of users in their ldap we understand how we map them given they dont have domains or projects in ldap
18:58:36 <joesavak> ayoung - we're using domains for customers
18:58:45 <joesavak> so hopefully it's not too unusual
18:59:02 <joesavak> or ldap domain?
18:59:04 <ayoung> joesavak, how often do you create a new domain?  Hourly, daily, monthly?
18:59:16 <bknudson> there was also discussion of having different backend per domain.
18:59:36 <ayoung> If it has to be quick, then the format is going to be pretty homogenized
18:59:37 <bknudson> so maybe need json for domains.
18:59:54 <ayoung> bknudson, yeah, that was brought up
19:00:03 <ayoung> I'm not sure I buy that, though
19:00:14 <ayoung> I think the Keystone Federation approach makes a lot more sense there.
19:00:39 <ayoung> We are at 15:00.
19:01:01 <ayoung> dolphm, we probably need to vacate the premises
19:01:06 <dolphm> ayoung: ah, thanks
19:01:08 <dwaite> Quick note; the company I work for (Ping Identity) is putting on their Cloud Identity Summit again this year, this time in Napa, CA. Details at http://www.cloudidentitysummit.com
19:01:11 <dolphm> switching to -dev!
19:01:18 <dolphm> #endmeeting