Dean Woodbeck:Audio is available via Adobe Connect. But to participate in the discussion, you will need to use the phone bridge for audio (if doing so, please mute your computer speakers): 734-615-7474, or 866-411-0013 (toll-free in US and Canada) PIN: 0157272# David Langenberg – uchicago:yes Tom Scavo:I can hear you! Daniel Yu(UofC):yes Mark "Max" Miller:Sounds good! Dean Woodbeck:Slides are available on the wiki: https://spaces.at.internet2.edu/x/NYBHAgImage Removed Tom Scavo:Dick Visser (TERENA) is a pioneer as well. Tom Scavo:Any SAML service provider software should work (not just Shibboleth) Nathan Dors:doesn't AITOawmLuj.....etc break the usability requirement? Tom Scavo:@Nathan Not all use cases require an invitation Tom Scavo:Spaces, for example, needs an "Identity Provider of Last Resort," which the Gateway provides gettes:@nathan what "username" is passed to the SP remains an interesting question. The junk you see is the openid username passed by some providers - like google. the gateway could translate the username into something per human readable. it brings up the issue of apps displaying username which may not be a good practice. Nathan Dors:the invitation flow is friendly, like a party invitation. like @gettes says, it's the usernamethat creates the challenge Russell Beall:We choose to translate the username into a custom identifier @guest.usc.edu. It can be a license plate or chosen by the user. Nathan Dors:CMU has one too, i think gettes:CMU currently passes on openid@affiliates.cmu.edu - we are working with cirrus identity and may move to emailaddress@affiliates.cmu.edu (the @ in the email address translated to + or something). gettes:i will say the openid based username was a great opportunity to teach apps why it is bad to display a username. Eric Goodman (UC):@gettes Eric Goodman (UC): gettes:speak louder please? keith hunt uakron:why is it a bad practice for apps to display username? gettes:cuz in a federated world - you won't have control over what that username looks like. there are those who provide 64+ char usernames and it may screw up the screen layout. keith hunt uakron:I see Russell Beall:and it would be confusing to the user because they think they are 'customname'@google.com, not the wierd thing that showed up Russell Beall:customname@google.com, not the weird thing that showed up... keith hunt uakron:I see that too gettes:@carmody regarding Grouper invitation service - the user identity only lives in Grouper, right? It's not exposed to your identity management system? Brown - Steve Carmody:today, the user identity is stored in a a DB separate from our Identity mgmt svc (person registry) Brown - Steve Carmody:we are in process for deploying a new Person Registry, and I expect we will be creating entries in that for people with social identities Brown - Steve Carmody:we have a groups deploy project underway right now; gettes:so, within Grouper, you have the invite service using a different subject source, is that how you did it? Brown - Steve Carmody:it will be creating user objects in our ldap server for these people, and adding them to groups within our ldap directory Brown - Steve Carmody:re different subject source, – yes, today it works that way gettes:bugger. adobe connect just blew chow on my chat - lost most of the messages. Tom Scavo:More on delegated administration of metadata: https://spaces.at.internet2.edu/x/7ZiKAQImage Removed Dean Woodbeck:@gettes - I'll email you the chat Dean Woodbeck:@gettes - thanks, too, for the imagery while I'm eating lunch gettes:@dean sorry about that - i had already finished my lunch. Tom Scavo:A visual demo of the Google Gateway: https://spaces.at.internet2.edu/x/jAFOAgImage Removed Brown - Steve Carmody:https://spaces.at.internet2.edu/display/socialid/Draft+requirements+fImage Removed or+a+Social2SAML+gateway+service Eric Kool-Brown (UW):Is there a concern about metadata explosion? How will this scale for shared metadata? Tom Scavo:@Eric There is only one "Google Sign In" IdP in InCommon metadata (if that's what you mean) Eric Kool-Brown (UW):Is there addition SP metadata beyond the standard SAML info? gettes:and what if google really wants to join InCommon? then we have 2 google IdPs? Personally, i think this approach is too complicated. Tom Scavo:@Eric No, no metadata customization is required at the end SP Brown - Steve Carmody: "What are the barriers to your institution deploying support for authentication by social providers (twitter, yahoo, google, Facebook etc.)? Chris Bongaarts (UMN):if google joins incommon, you just switch to a federated instead of gateway model gettes:not true - the userids will be different. Tom Scavo:@gettes We would be happy to withdraw the Gateway if Google were to join InCommon Denis Hancock - University of Missouri:level of assurance Brown - Steve Carmody:I don't think anyone is expecting Google tojoin IC at this point gettes:and disconnect all those users? that doesn't sound very friendly. Tommy - SMU:What on the IdP side tracks the relationship between the social ID and the "registered ID"? Eric Goodman (UC):Certainly some sort of (local) policy or guidance around when it's appropriate to use Google IDs (might go beyond LoA concerns) Eric Goodman (UC):or other social IDs gettes:@carmody - i don't agree with betting on the future Tom Scavo:@Tommy Are you referring to the identifier asserted by the Google IdP? Tommy - SMU:correct Chris Bongaarts (UMN):perhaps google could be persuaded to release an openID identifier for a user as an attribute Tom Scavo:The Google identifier (called a Personal Private Identifier) is analogous to eduPersonTargetedID Tom Scavo:Every SP gets its own PPID for the user. Chris Bongaarts (UMN):if PPI includes "idp" as part of its uniqueness then my idea would be a nonstarteer Tom Scavo:@Chris The PPID is converted to an ePTID at the Gateway Kevin Legget - Northeastern:We currently provide credentials to over 10,000 "parents" and I would prefer to be out of that business. However, I am concerned about the access to certain applications (billing, student bio info, grades, etc.) but I see the potential here. Nathan Dors:@Tom, is there a wiki page that clearly describes that attributes asserted by Google (email, username, etc) and their appropriateness for SP consumption? Tommy - SMU:@Tom thanks, but the discussion was that there was an association between the Google identifier and either an existing campus account or one the user signs up for in real time. So what databases maintains that association for the IdP? gettes:@kevin - yup, that's why we rolled out our S2S gateway Earl Lewis - UofU:is anyone speaking? Eric Goodman (UC):Many of the desired use cases seem to involve access to relatviely sensitive data e.g., access to student bills. Are there guidelines/thoiughts around when that's appropraite? (kind of a followup to Kevin's question" Nathan Dors:@Steven, personally I don't think assurance attributes are a must-have for phase 1 Earl Lewis - UofU:i can hear now Tom Scavo:@Nathan Let me see if there's a wiki page...if not, we'll start one gettes:@john and whether or not registering social IdPs in metadata is actually a good idea. Tommy - SMU:Definitely agree that accounts for parents (over 10,000 of them now) is a big driver for us to move to social authN. Nathan Dors:@Tom, thanks. we may be able to contribute to that. Tom Scavo:Google OpenID Gateway Attributes: https://spaces.at.internet2.edu/x/EgZOAgImage Removed Michael Hodges @ U of Hawaii:Id like to understand the pros and cons of storing social ids in the person registry gettes:not on voice - is access to a student bill sensitive? gettes:we thought not. gettes:there is no personally identifiable info on the bill. and yes, the student is in control - the authorizer Nathan Dors:to a particular identifier or to a particular email address? gettes:no risk to the university in accepting money. gettes:we used to send the bills out by email Eric Goodman (UC):Good point; I think I was thinking of specific systems where billing and records and not clearly separated. Eric Goodman (UC):are not* Chris Bongaarts (UMN):applicants are of interest to us as well keith hunt uakron:do Google et al promise not to track anything about my login to an SP for their own use? gettes:google promise? funny. what does a google promise look like? Tom Scavo:@keith Google doesn't know anything about the SP on the other side of the gateway Chris Bongaarts (UMN):@gettes: "don't be evil" Loren Frerichs -UNL:in our student records system studnts can add a "guest for thier records" that only that student can reset the password for Chris Bongaarts (UMN):@scavo in krienke's diagram it would gettes:@chris - if you have to say "don't be evil" then you already are. Tommy - SMU:In our case, we allow the student to authorize anyone to have a sponsored account to not only pay bills but also optionally view academic information if they choose. Chris Bongaarts (UMN):@gettes i actually meant to stick the tongue in my cheek rather than out Kevin Legget - Northeastern:Does Cirrus expect to have an available GW by early November (the week established for the "Identity Week")? Chris Bongaarts (UMN):we have a parent proxy setup like tommy@smu Tom Scavo:@Chris Yes, I suppose SP-specific gateway in the box outlined in blue dotted line is tracked by Google Tom Scavo:But doesn't any IdP in the InCommon Federation know exactly what services it interacts with? Kevin Legget - Northeastern:On another note, the URL for the "Identity Week" event on the I2 page is not functional. Dedra Chamberlin:I certainly hope we will have something ready not just to demo, but as a viable service by November, yes Brown - Steve Carmody:https://spaces.at.internet2.edu/display/socialid/Draft+requirements+fImage Removed or+a+Social2SAML+gateway+service Tommy - SMU:Great topic, and I'd like to hear much more. Nathan Dors:are the ordered lists ordered by priority? Eric Kool-Brown (UW):I'm confused about the SP identifier in the consent page. Has this issue been worked out by Cirrus? Brown - Steve Carmody:@nathan – not prioritized. Tom Scavo:@Eric We have a solution but I don't know if it's the solution Nathan Dors:right. Keith Hazelton, UW-Madison:I do keep wondering why more campuses haven't started down the path of Social2SAML services. Is it capacity? Lack of a local campus driver? Dedra Chamberlin:We have had a number of conversations about SP identifier in the user consent page David Bantz, U Alaska:Lack of capacity to take on more... Tommy - SMU:We discuss it quite a lot and not sure how best to move forward. Nathan Dors:yes, lack of capacity. we're deploying this stuff to support social logins to Canvas Dedra Chamberlin:For OAuth providers, the text a user sees is configurable, and can describe the SP in user-friendly terms Chris Bongaarts (UMN):@hazel it's definitely been brought up as an interesting idea. part of it for us is OIM project which and related uncertainty Dedra Chamberlin:For OpenID, the info displayed is tied to the domain Russell Beall:Is there any more information on whether gateway usage of OpenID/oAuth providers will violate the providers' licence agreements Russell Beall:Does InCommon have an arrangement with Google? Tom Scavo:@Russell Using the architecture outlined in the diagram to the right, the end SP is in control of their piece of the Gateway, so there's no need for InCommon Ops or Cirrus Identity to "be in the middle" Tom Scavo:In other words, we nicely sidestep any legal issues Russell Beall:So, each SP would have to register with the providers if using oAuth (luckily OpenID doesn't require such registration of a service...) Nathan Dors:some SP owners have asked if the Gateway will host a configurable discovery service for them too, so they don't need to implement one local to the SP Tom Scavo:@Russell Exactly. Tom Scavo:@Nathan The SP can choose to use the InCommon Discovery Service (but a local, customized discovery service is recommended) gettes:@nathan that is a capability i am hoping for/expecting from Cirrus Dedra Chamberlin:Yes, with OAuth providers, SP admins would register with the social IdP, get an OAuth key and secret, and use that to configure the SP in the Gateway manager Brown - Steve Carmody:june 3, 12 noon EDT Tom Scavo:@gettes We really don't want to put a discovery service at the gateway, which would put two DSs in front of the user Dedra Chamberlin:Yes, Cirrus is planning to run a custom DS Dean Woodbeck:Please take a minute and fill out our evaluation: http://www.surveymonkey.com/s/VWGImage Removed Dedra Chamberlin:Our plan is to propose a design that will not present a user with double discovery Steve Olshansky:https://lists.internet2.edu/sympa/subscribe/socialidentityImage Removed Steve Olshansky:to subscribe to the list John Krienke, InCommon/Internet2:I wonder if it would be useful to have a meeting with campus App owners to discuss requirements. Good idea? Or a survey? Tommy - SMU:i like meetings, but this format for this topic was clumsy Tommy - SMU:some guys like me just need training/education Tommy - SMU:others have other conversations John Krienke, InCommon/Internet2:@ Tommy. Let us know what you'd like to see in the survey. I think we're in the process of developing guidance, but we're not there yet for "recommended practices." John Krienke, InCommon/Internet2:The working group is definitely where the Sausage is made. Tommy - SMU:Understood, and I don't intend to be critical - this discussion is exactly what we need more of! John Krienke, InCommon/Internet2:excellent. Keep the feedback coming. Tommy - SMU:Slides and discussion were great. Maybe a soup to nuts use case and demo would be the next valuable thing for us as we begin. John Krienke, InCommon/Internet2:Look for that in fall. And we'll pick up the thread and more at the Identity Week discussion... link ... somewhere ... John Krienke, InCommon/Internet2:a new meeting – or set of meetings – we're developing with community feedback. http://www.incommon.org/idweek/Image Removed |