[06:49:02 CST(-0600)] <phrearch> hello
[06:49:04 CST(-0600)] <phrearch> anyone here?
[06:49:19 CST(-0600)] <phrearch> any idea where this error comes from? http://paste.pocoo.org/show/506235/
[06:49:25 CST(-0600)] <wgthom> hi
[06:49:25 CST(-0600)] <phrearch> trying to create a maven overlay
[06:49:30 CST(-0600)] <phrearch> hello wgthom
[06:50:09 CST(-0600)] <phrearch> seems like it uses a property i defined earlier in cas.properties. but after removing it its still there after a rebuild
[06:50:11 CST(-0600)] <wgthom> 'ticketGrantingTicketUniqueIdGenerator' defined in ServletContext resource [/WEB-INF/spring-configuration/uniqueIdGenerators.xml]: Could not resolve placeholder 'host.name'
[06:50:22 CST(-0600)] <wgthom> check your cas.properties
[06:50:43 CST(-0600)] <phrearch> that one is empty, but it doesnt flush the old values it seem
[06:50:57 CST(-0600)] <phrearch> shouldnt mvn clean package reset all values?
[06:51:02 CST(-0600)] <wgthom> not sure what you mean
[06:51:29 CST(-0600)] <wgthom> mvn clean will remove your the 'target
[06:51:32 CST(-0600)] <wgthom> dir
[06:51:41 CST(-0600)] <phrearch> well, that ticketgranting reference was in src/main/webapp/WEB-INF/cas.properties first, but i removed it again and rebuild with mvn clean package
[06:51:43 CST(-0600)] <wgthom> mvn pacakge will overlay your files on the the speicific cas version
[06:52:11 CST(-0600)] <wgthom> removed the file?
[06:52:35 CST(-0600)] <phrearch> no, the reference to the ticketgranting in cas.properties
[06:52:51 CST(-0600)] <phrearch> im not sure, maybe i need to mess in the target dir?
[06:53:29 CST(-0600)] <wgthom> not following you.
[06:53:39 CST(-0600)] <wgthom> you should not have to mess with target dir
[06:53:50 CST(-0600)] <wgthom> what ref did you remove from cas.props?
[06:54:02 CST(-0600)] <phrearch> hm. well every time i make a change in the overlay, i expect the resulting war file to reflect the changes i made in /sr/main/webapp/WEB-INF
[06:54:15 CST(-0600)] <phrearch> not sure if thats correct
[06:54:46 CST(-0600)] <wgthom> yes. after mvn clean pacakge…the change in /src/ will be overlayed on the cas.war
[06:55:12 CST(-0600)] <wgthom> "host.name" must be in cas.properties
[06:55:24 CST(-0600)] <wgthom> if you removed it in your overlay…you need to put it back.
[06:55:43 CST(-0600)] <wgthom> running mvn clean package won't put it back into your overlay files in src
[06:55:52 CST(-0600)] <phrearch> aha, maybe i should just remove the whole file
[06:56:08 CST(-0600)] <wgthom> yes, unless you need some local change to it
[06:57:13 CST(-0600)] <phrearch> ok great. i thought an empty cas.properties wont harm, but it does apperently
[06:57:22 CST(-0600)] <phrearch> cas runs again
[06:57:27 CST(-0600)] <phrearch> thanks 
[06:57:37 CST(-0600)] <wgthom> yes, since your empty file is getting overlayed onto the cas.war and blowing away required config
[06:58:00 CST(-0600)] <phrearch> i see
[06:58:03 CST(-0600)] <phrearch> lots to learn
[06:58:13 CST(-0600)] <phrearch> im trying to setup mysql auth in deployerConfigContext.xml
[06:58:15 CST(-0600)] <wgthom> one downside of mvn overlay method….if you want to introduce changes they must go along with the required file out of the cas dist
[06:58:48 CST(-0600)] <wgthom> ok. you'll want to first copy deployerConfig out of the cas dist into your /src/ dir and then make changes there
[06:59:11 CST(-0600)] <wgthom> each upgrade you'll have to diff any changes in the cas dist
[06:59:15 CST(-0600)] <phrearch> yea got that. added a datasource bean and a QueryDatabaseAuthenticationHandler
[06:59:24 CST(-0600)] <phrearch> aha ok
[06:59:47 CST(-0600)] <phrearch> made a simple db to check against md5
[07:01:10 CST(-0600)] <phrearch> i read the cas protocol a while ago, but was wondering whether the cas server checks against the credential store on each request
[07:01:27 CST(-0600)] <wgthom> "each request?
[07:01:44 CST(-0600)] <wgthom> cas only does primary authN when necessary
[07:02:23 CST(-0600)] <phrearch> well, suppose a user sends a request to an app. the app sends a message to cas through cas-client. does cas check against the credential store on each request, or just whether the ticket is still valid in some in-memory db?
[07:02:53 CST(-0600)] <phrearch> at least, thats what i imagines what happens when doing a request
[07:03:03 CST(-0600)] <phrearch> imagine
[07:04:36 CST(-0600)] <wgthom> once the app session is established cas is mostly out of the picture
[07:04:49 CST(-0600)] <wgthom> primary authN is only done to establish the cas sso session
[07:05:27 CST(-0600)] <phrearch> aha, so the app is responsible for the session?
[07:05:43 CST(-0600)] <wgthom> of course 
[07:05:50 CST(-0600)] <wgthom> cas is not a session manager
[07:06:18 CST(-0600)] <phrearch> aah ok. so suppose cas has a web service as credential store, then it wouldnt add another http call on each request
[07:06:29 CST(-0600)] <phrearch> like user -> app -> cas -> webservice
[07:06:47 CST(-0600)] <wgthom> user interacts with cas directly
[07:06:52 CST(-0600)] <wgthom> for primary authN
[07:07:46 CST(-0600)] <phrearch> hm, like the app redirects to cas?
[07:08:15 CST(-0600)] <wgthom> y
[07:08:21 CST(-0600)] <phrearch> i should reread the whole protocol thing
[07:08:32 CST(-0600)] <phrearch> especially the ticket part is a bit confusing to me
[07:09:05 CST(-0600)] <wgthom> http://www.youtube.com/watch?v=Ik_11Y17ASg
[07:09:54 CST(-0600)] <phrearch> aha thanks!
[07:10:07 CST(-0600)] <wgthom> my pleasure.
[07:23:30 CST(-0600)] <phrearch> hm, a custom passwordencoder shouldnt end up in authenticationHandlers?
[07:23:55 CST(-0600)] <phrearch> http://paste.pocoo.org/show/506253/
[07:24:14 CST(-0600)] <phrearch> somehow it cant find the reference
[07:26:11 CST(-0600)] <phrearch> ah got it. needed to add it to the outer bean
[12:59:17 CST(-0600)] <Ozy_work> no meeting today?
[12:59:27 CST(-0600)] <wgthom> hi
[12:59:36 CST(-0600)] <apetro_> checking in
[13:00:01 CST(-0600)] <apetro_> agenda bash?
[13:00:23 CST(-0600)] <apetro_> agendum: automatic registration of services management service
[13:00:46 CST(-0600)] <apetro_> agendum: enhancing theme support in CAS 3.5 to afford per-theme JSPs rather than just per-theme CSS
[13:00:57 CST(-0600)] <apetro_> agendum: LPPE
[13:01:05 CST(-0600)] <Ozy_work> yay!
[13:01:54 CST(-0600)] <apetro_> agendum: Jasig UnConference recap / discussion?
[13:03:16 CST(-0600)] <wgthom> lil distracted at this time...
[13:03:20 CST(-0600)] <apetro_> yeah
[13:03:23 CST(-0600)] <apetro_> I'm thinking that
[13:03:43 CST(-0600)] <apetro_> those were fun agenda items if there were a critical mass to work with
[13:04:50 CST(-0600)] * apetro_ discovers his IRC client is apparently unstable
[13:05:07 CST(-0600)] <apetro_> 0zy_work , what do you want to discuss?
[13:09:08 CST(-0600)] <Ozy_work> LPPE
[13:09:13 CST(-0600)] <Ozy_work> sorry on the phone
[13:10:53 CST(-0600)] <apetro_> k
[13:11:00 CST(-0600)] <Ozy_work> back
[13:11:09 CST(-0600)] <Ozy_work> i was just lurking to follow LPPE
[13:11:26 CST(-0600)] <Ozy_work> we are holding off on our CAS upgrade to see where LPPE support goes
[13:11:51 CST(-0600)] <apetro_> wgthom seems essential to a good discussion of LPE, and he's a "lil distracted". How to resolve? Take to list? Discussion can happen now? Reschedule discussion?
[13:12:25 CST(-0600)] <Ozy_work> i'm fine either way
[13:12:34 CST(-0600)] <Ozy_work> i have nothing to really contribute
[13:12:44 CST(-0600)] <apetro_> Is we University of Northern Iowa?
[13:12:45 CST(-0600)] <Ozy_work> i have not had time to do anything with CAS lately
[13:12:49 CST(-0600)] <Ozy_work> indeed
[13:13:02 CST(-0600)] <Ozy_work> well, we being me at the univeristy of northern iowa
[13:13:10 CST(-0600)] <apetro_> of course you have something to contribute, somewhere on the spectrum of adoption to requirements articulation to QA to feature development.
[13:14:09 CST(-0600)] <apetro_> I think where it's at is, good discussion at UnConference. Andrew Tillinghast is reflecting LDAP account status in his CAS login workflow, in production.
[13:14:23 CST(-0600)] <Ozy_work> fair enough
[13:14:24 CST(-0600)] <apetro_> Has shared code, is working with that feature branch via pull requests etc. to share that code.
[13:14:38 CST(-0600)] <apetro_> Collaboration towards stability, and targeting this feature for CAS 3.5, as per roadmap.
[13:15:00 CST(-0600)] <apetro_> Last I heard there were some issues getting to clean pull requests. Some growing pains in learning to use Git effectively.
[13:16:03 CST(-0600)] <apetro_> So, there's code to look at and comment upon and envision how it will meet your needs, and that would be awesome.
[13:16:20 CST(-0600)] <apetro_> But even sharing that you're enough interested in this feature to hold up your CAS upgrade to try to get it is good feedback.
[13:16:31 CST(-0600)] <Ozy_work> well then
[13:16:41 CST(-0600)] <Ozy_work> it's holding us up because we are selfish, to be fair
[13:17:04 CST(-0600)] <apetro_> please do be selfish. Enlightened self interest is a beautiful thing.
[13:17:14 CST(-0600)] <Ozy_work> it took a lot of work to hack the module into fitting our needs when I installed CAS, and now we are stuck requiring those features
[13:17:38 CST(-0600)] <Ozy_work> we cannot upgrade if it cuts the ability to detect and reset expired passwords
[13:17:55 CST(-0600)] <apetro_> well then. Sounds like you have even more to contribute than you let on, if you're running this functionality in production today.
[13:17:58 CST(-0600)] <Ozy_work> and the lasat time I tried to get the patch to work, I ran out of time and never got it to work
[13:18:06 CST(-0600)] <Ozy_work> indeed we are
[13:18:10 CST(-0600)] <Ozy_work> it's slick, too
[13:18:13 CST(-0600)] <apetro_> you delivering the password reset experience directly in CAS login flow?
[13:18:23 CST(-0600)] <Ozy_work> and we are using Oracle, not Active Directory
[13:18:25 CST(-0600)] <Ozy_work> i think so
[13:18:28 CST(-0600)] <Ozy_work> well
[13:18:30 CST(-0600)] <Ozy_work> no
[13:18:33 CST(-0600)] <Ozy_work> I stand corrected
[13:18:42 CST(-0600)] <apetro_> as in, the form for password reset is delivered by, handled by CAS, or it merely links out to external app for providing actual password change experience?
[13:18:47 CST(-0600)] <Ozy_work> we use an iFrame when someone logs in with an expired password
[13:19:03 CST(-0600)] <Ozy_work> external app
[13:19:04 CST(-0600)] <apetro_> yup, cool
[13:19:10 CST(-0600)] <Ozy_work> want to test it?
[13:19:22 CST(-0600)] <Ozy_work> see it in action?
[13:19:24 CST(-0600)] <apetro_> sure
[13:19:43 CST(-0600)] <Ozy_work> https://castest.uni.edu/cas/login
[13:19:51 CST(-0600)] <Ozy_work> one second I need to drum you up an account
[13:19:53 CST(-0600)] <apetro_> I think the LPPE feature branch will meet your needs when Tillinghast's changes are merged in.
[13:20:28 CST(-0600)] <apetro_> some work to do for mapping from Oracle rather than AD, but I'd hope that will be an achievable bit of customization
[13:21:01 CST(-0600)] <Ozy_work> PM
[13:21:08 CST(-0600)] <Ozy_work> yeah
[13:21:14 CST(-0600)] <Ozy_work> that mapping was not terribly hard
[13:22:25 CST(-0600)] <apetro_> is castest.uni.edu available outside your network?
[13:22:44 CST(-0600)] <Ozy_work> hrm.... it is supposed to be, but the ACLs may have changed on me
[13:22:50 CST(-0600)] * apetro_ is not able to access castest.uni.edu
[13:23:12 CST(-0600)] <Ozy_work> try....
[13:23:21 CST(-0600)] <Ozy_work> https://casstage.uni.edu/cas/login
[13:23:34 CST(-0600)] <Ozy_work> does that load?
[13:23:43 CST(-0600)] <apetro_> yes
[13:23:48 CST(-0600)] <Ozy_work> awesome
[13:24:20 CST(-0600)] <Ozy_work> new password, same account
[13:24:39 CST(-0600)] <Ozy_work> i'm being lazy and using my lazyman scripts
[13:25:03 CST(-0600)] <Ozy_work> it's not the most clean thing in the world, but it works
[13:25:16 CST(-0600)] <Ozy_work> it also handles administatively locked accounts
[13:26:13 CST(-0600)] <apetro_> again, where "handles" is "advises user of problem via an error page" ?
[13:26:56 CST(-0600)] <Ozy_work> yeah
[13:27:07 CST(-0600)] <Ozy_work> by default, cas as authenticating them
[13:27:10 CST(-0600)] <Ozy_work> was*
[13:27:16 CST(-0600)] <Ozy_work> even though they were locked
[13:27:20 CST(-0600)] <Ozy_work> IIRC
[13:27:51 CST(-0600)] <Ozy_work> so now it catches them and it tells them to communicate with the office in charge of administrative locks
[13:27:56 CST(-0600)] <Ozy_work> the help desk, basically
[13:28:10 CST(-0600)] <apetro_> very nice
[13:28:18 CST(-0600)] <Ozy_work> yeah
[13:28:21 CST(-0600)] <apetro_> looks like a pretty seamless experience, despite the inline frame
[13:28:33 CST(-0600)] <Ozy_work> what doesnt work, though
[13:28:46 CST(-0600)] <Ozy_work> is that once you change your password, you go back, and have to re-log in
[13:28:58 CST(-0600)] <apetro_> right. Rather than continuing through flow.
[13:28:59 CST(-0600)] <Ozy_work> we were unable to have the iframe redirect to the cas login page
[13:29:05 CST(-0600)] <apetro_> hmm
[13:29:05 CST(-0600)] <Ozy_work> since that's hijacking
[13:29:07 CST(-0600)] <apetro_> right
[13:29:15 CST(-0600)] <Ozy_work> the iframe cannot control the parent
[13:29:21 CST(-0600)] <Ozy_work> silly security
[13:29:41 CST(-0600)] <apetro_> what about having the iframe experience terminate in a link/button that sends you to /cas/login?service=the_service_you_wanted
[13:30:00 CST(-0600)] <Ozy_work> i don't recall why that did not work
[13:30:02 CST(-0600)] <apetro_> or this issue is CAS login failed such that it didn't issue a tgt?
[13:30:05 CST(-0600)] <Ozy_work> i do recall we tried it
[13:30:07 CST(-0600)] <Ozy_work> oh
[13:30:10 CST(-0600)] <Ozy_work> that's part of it
[13:30:12 CST(-0600)] <apetro_> ah
[13:30:12 CST(-0600)] <apetro_> k
[13:30:23 CST(-0600)] <Ozy_work> you still need to authenticate with a new ticket
[13:30:44 CST(-0600)] <apetro_> interesting
[13:30:46 CST(-0600)] <Ozy_work> but I don't like the lack of a redirect shrug
[13:30:50 CST(-0600)] <Ozy_work> it works
[13:30:57 CST(-0600)] <Ozy_work> and it's been working since...
[13:30:59 CST(-0600)] <apetro_> well, good to know you've already implemented this, in production, and as you say, it works
[13:31:01 CST(-0600)] <Ozy_work> hmm
[13:31:08 CST(-0600)] <Ozy_work> it's been a long time
[13:31:58 CST(-0600)] <apetro_> I encourage you to stay engaged in the effort of mainstreaming this for 3.5., at whatever levels and ways you can.
[13:32:25 CST(-0600)] <Ozy_work> this is 3.3.5, and has been working since that version came out
[13:32:37 CST(-0600)] <Ozy_work> i'm trying to stay involved as much as I can
[13:32:52 CST(-0600)] <Ozy_work> i am swamped at work, though, so it's hard to do much other than monitor the meetings
[13:33:03 CST(-0600)] <Ozy_work> if someone has a concrete thing I can help with, I can find time
[13:33:21 CST(-0600)] <apetro_> well. Hope GitHub can facilitate monitoring of code and real work. It's a step up from meetings.
[13:34:12 CST(-0600)] <apetro_> concretely, I think it will be really helpful if you could try to locally implement (in a dev env) the lppe- feature branch just as soon as it's stable.
[13:34:23 CST(-0600)] <Ozy_work> that I can do
[13:34:36 CST(-0600)] <apetro_> either it meets your needs or it doesn't, will be awesome to shake that out before it ships in CAS 3.5
[13:34:46 CST(-0600)] <Ozy_work> any guesses on when that will be?
[13:34:54 CST(-0600)] <apetro_> Not sure.
[13:35:19 CST(-0600)] <apetro_> There was hope of working through github pull request cleanness at UnConf, but didn't quite get to bottom of it, so I think wgthom and atilling are still working through that.
[13:36:47 CST(-0600)] <Ozy_work> yeah
[13:36:57 CST(-0600)] <apetro_> as long as we're chatting anyway
[13:37:03 CST(-0600)] <apetro_> what are you doing for service registration?
[13:37:20 CST(-0600)] <Ozy_work> oh convoluted setup that rocks
[13:37:26 CST(-0600)] <Ozy_work> lol
[13:37:33 CST(-0600)] <apetro_> I sense a theme
[13:37:49 CST(-0600)] <apetro_> ok. What needs does the convolution meet / what makes it rock?
[13:38:05 CST(-0600)] <apetro_> feedback on this: ? http://www.unicon.net/blog/apetro/automatically_register_services_management_service
[13:38:12 CST(-0600)] <Ozy_work> we have an Oracle table that we load the urls into, along with the administrators name and their backups, and a description of the service
[13:38:32 CST(-0600)] <apetro_> interesting, so, tracking people associated with the services is important
[13:38:41 CST(-0600)] <Ozy_work> once a day (or on demand) we copy the appropriate information into the CAS DB tables
[13:38:49 CST(-0600)] <apetro_> how many registered services are we talking about?
[13:38:50 CST(-0600)] <Ozy_work> and then every 2 minutes the frontends refresh
[13:38:56 CST(-0600)] <Ozy_work> 347 at this time
[13:39:01 CST(-0600)] <Ozy_work> as of 15 minutes ago
[13:39:09 CST(-0600)] * apetro_ collects his jaw off the floor
[13:39:27 CST(-0600)] <Ozy_work> every cas enabled app is a service
[13:39:59 CST(-0600)] <Ozy_work> when you consider we have test, stage, and prod tiers, we have a lot of services to track
[13:40:16 CST(-0600)] <Ozy_work> and they are all in the same oracle table for logistical reasons
[13:40:22 CST(-0600)] <apetro_> ok
[13:40:24 CST(-0600)] <apetro_> this is awesome
[13:40:26 CST(-0600)] <Ozy_work> (we clone prod to test and stage regularly)
[13:40:31 CST(-0600)] <apetro_> are you doing any delegated administration of that table?
[13:40:38 CST(-0600)] <Ozy_work> yes and no
[13:40:40 CST(-0600)] <apetro_> as in, named admins of a service are allowed to edit that service?
[13:40:44 CST(-0600)] <Ozy_work> nope
[13:40:53 CST(-0600)] <Ozy_work> not directly
[13:41:01 CST(-0600)] <apetro_> k
[13:41:03 CST(-0600)] <Ozy_work> ok, so we have a move system in place
[13:41:13 CST(-0600)] <Ozy_work> they can edit test directly
[13:41:17 CST(-0600)] <Ozy_work> but not stage or prod
[13:41:20 CST(-0600)] <apetro_> ah
[13:41:26 CST(-0600)] <apetro_> that makes sense
[13:41:29 CST(-0600)] <Ozy_work> they make scripts and request they be moved
[13:41:35 CST(-0600)] <apetro_> right
[13:41:41 CST(-0600)] <Ozy_work> stage moves are twice a day, prod once a week
[13:41:51 CST(-0600)] <apetro_> so, you're kind of using test as a self-service service registration requesting tool
[13:42:02 CST(-0600)] <Ozy_work> for the most part
[13:42:15 CST(-0600)] <apetro_> see value in a service-provider-facing UI for requesting service registration / changes to registrations?
[13:42:17 CST(-0600)] <Ozy_work> not all service administrators can access the DB either, but they help each other
[13:42:21 CST(-0600)] <apetro_> Would your life be better if CAS had that?
[13:42:26 CST(-0600)] <Ozy_work> oh heck yes
[13:42:33 CST(-0600)] <Ozy_work> we are writing one.. sorta
[13:42:36 CST(-0600)] <apetro_> !
[13:42:47 CST(-0600)] <Ozy_work> not tied to cas, but tied to that oracle table
[13:42:52 CST(-0600)] <Ozy_work> it's on the list of projects
[13:42:59 CST(-0600)] * apetro_ encourages sharing it via GitHub, regardless of what it's tied to
[13:43:14 CST(-0600)] <Ozy_work> i'll see what I can do
[13:43:20 CST(-0600)] <Ozy_work> i am guessing there is no code written yet
[13:43:37 CST(-0600)] <apetro_> do you see value in these improvements, or are they mostly irrelevant to you? https://wiki.jasig.org/display/~awp9/CAS+Services+Registry+Improvements+for+CAS+3.5
[13:44:23 CST(-0600)] <Ozy_work> lookimng
[13:44:55 CST(-0600)] <Ozy_work> first off, we don't use the CAS provided webgui
[13:46:33 CST(-0600)] <apetro_> k.
[13:46:49 CST(-0600)] <Ozy_work> we also decided we cannot use the logout callbacks
[13:46:59 CST(-0600)] <apetro_> imho, an excellent choice
[13:47:10 CST(-0600)] <Ozy_work> too many applications would ignore that, adn let users be mislead into security concerns
[13:47:22 CST(-0600)] <apetro_> right there with ya
[13:47:28 CST(-0600)] <Ozy_work> like shibboleth, with is the biggest concern
[13:47:41 CST(-0600)] <Ozy_work> and our student information portal (grades, billing, etc)
[13:47:50 CST(-0600)] <apetro_> PeopleSoft?
[13:47:55 CST(-0600)] <Ozy_work> haha
[13:47:56 CST(-0600)] <Ozy_work> yeah
[13:48:08 CST(-0600)] <Ozy_work> and shibboleth = google/gmail
[13:48:14 CST(-0600)] <Ozy_work> thats the driving app
[13:48:35 CST(-0600)] <Ozy_work> not logging out of gmail on single logout was a ngihtmare of potential issues
[13:48:49 CST(-0600)] <Ozy_work> Interactive Service Matching Tester < – DO IT! THIS IS NEEDED
[13:49:19 CST(-0600)] <apetro_> voting on the tracking JIRA is welcome. https://issues.jasig.org/browse/CAS-996
[13:50:09 CST(-0600)] <apetro_> this is great feedback. Really helpful to hear from someone doing serious production service registration today regarding how services management should be made better
[13:50:10 CST(-0600)] <Ozy_work> done
[13:50:22 CST(-0600)] <Ozy_work> i'm full of feedback 
[13:50:36 CST(-0600)] <Ozy_work> cas is a wonderful app
[13:50:49 CST(-0600)] <Ozy_work> and we have... strange... requirements sometimes
[13:50:58 CST(-0600)] <apetro_> appreciate your saying so. Tell all your friends. About the CAS bit, that is.
[13:51:22 CST(-0600)] <Ozy_work> we do
[13:51:28 CST(-0600)] <apetro_> the responsible party tracking thing is an interesting insight
[13:51:52 CST(-0600)] <Ozy_work> if you are interested, I can show you the table headers and explain the,
[13:51:53 CST(-0600)] <Ozy_work> them*
[13:52:14 CST(-0600)] <apetro_> the open-ended description field might work kinda okay for that today, but might be some profit in embiggening the registrations to track that
[13:52:23 CST(-0600)] <Ozy_work> yeah
[13:52:25 CST(-0600)] <apetro_> notify on errors, perhaps
[13:52:43 CST(-0600)] <apetro_> could get it down to a single email address per service
[13:52:55 CST(-0600)] <apetro_> and then if you want it to go to multiple folks, point it at an alias or list or something.
[13:53:15 CST(-0600)] <Ozy_work> well, we use SSO_ID, which is an internal, unique identifier that links to the person record in another table
[13:53:51 CST(-0600)] <apetro_> yup
[13:54:06 CST(-0600)] <apetro_> I suppose if it's a user id, that'd be great for affording some kind of service-owner-view on services registry management
[13:54:17 CST(-0600)] <apetro_> maybe these are two different features
[13:54:22 CST(-0600)] <apetro_> notify an email address on failure
[13:54:32 CST(-0600)] <apetro_> enumerate set of zero or more userids of service owners