Attending: Etan Weintraub, Rob Carter, Shilen Patel, Chris Dalansky,
Majeed Abu-Quibain, Erik Coleman, Jeffrey C. (UCLA), Marcus Mizushima
Etan: Recording is on, just for note taking -- if you want something
expunged from the notes, let us know and we'll gladly avoid adding it.
Etan: Speaking of notes... anyone want to volunteer for note taking?
Rob: I'll take notes
Etan: <Sharing screen>... We need to approve the notes from last
meeting. I put them together, so I implicitly approve, but we need at
least three approvals -- if you can jump into the comments and note
your approval, I'll move them over to public later.
Etan: The main thing we want to cover today is the key linked IDP
scenarios document. This is the final review before we present this
Rob: Correct -- we should ahve time in the CACTI agenda for this on
Etan: Couple things I need some feedback on: I put in URLs for the
products -- I'm not certain if I got the right URL for CAS?
Majeed: That looks like a reasonable URL to use for it -- it's their
Etan: Cirrus I just went to their product page, etc...
Eric: Does the Azure AD one got to their main products page, or to the
service description -- we've gone to the specific Azure AD page.
Etan: I'll adjust that -- I just went to the Azure page in general
because it was easy to find.
Eric: Yeah -- probably better if we can go directly to the Azure AD
page for this purpose.
Etan: I'd like to change the references to rationalize names to match
the names in the URL lists at the top -- to shorten things down a bit
and make sure things in the body match the names we use in the URL
Jeffrey: Do we also want to mention the Unicon product in the URL
Etan: I don't know what that is?
Jeffrey: If you go to the Okta site and look for federation -- they
have a link to a federation connector from Unicon...
Etan: I'll recommend we don't include it, if all we're going to do is
mention that it exists but not actually flesh out any details about
its use. Unless we have someone who wants to fill in a row for it, we
probably shouldn't note it.
Jeffrey: I don't know that anyone on the call here uses it, but I know
it's been used somewhere.
Etan: Yeah -- I think without someone to fill in details about it, we
don't wnat to note it.
Etan: Before publication, I'm going to remove the first and last
columns so we don't inadvertently make it look like we're doing
"ranking", and so that we don't publicize who wrote what within the
group (that was mostly for us to keep track of who had responsibility
Majeed: The details in the issues/benefits columns may be specific to
the institutions that are responding, so it might be useful to note
what institution(s) were represented?
Etan: I think they're general enough to be extrapolated... If we
wanted, we could probably list institutions instead of individuals --
what institutions are using a given scenario, but that might lead to
folks being contacted after the fact... I'm viewing this as something
we should put up and once it's up our WG shoudln't need to do anything
more. If anyone has questions, etc., they'd go to CACTI.
Rob: We can either let CACTI start a new working group for any new
efforts that are needed or consider re-constituting this group to
address any follow-ons... If there's work we think would be useful to
do beyond what this group did, we can note that in our supporting
Etan: I don't know what folks' preference is?
Jeffrey: I think I'll probably be contacted no matter what -- I'm not
opposed to being reached out to, but I may not be able to respond
Etan: I'd rather keep the working group email list and let folks email
the list, and whoever wants to reply to something can if they'd like.
Different institutions may be doing the same thing(s) -- having the
mailing list persist and letting folks on the list respond to
questions might be the best option.
Majeed: I'd support that. I'm kinda indifferent about leaving or
removing the names from the document, but I'm perfectly fine with
staying engaged with the working group -- I don't know that the names
need to be there though in the doc.
Etan: I'll recommend against leaving names in the document, then.
Marcus: Should we list institutions that are using each scenario?
Etan: I'd recommend against it because it would have to be kept up to
date. I could easily see our institution dropping Azure AD at some
point, in which case the doc would be out of sync.
Etan: Rob -- do you want to mention what you got back from Chris and
Rob: So, I briefly shared the draft table with Nicole and Chris
Phillips on our CACTI agenda-building call two weeks ago, and they
each had one suggestion to pass along. Nicole noted that the table is
good, but that it could probably use a bit more documentation in front
of the table to describe the work of the WG and what the table
represents, as well as why it's important, and some documentation of
what we think could be useful follow-on work for someone to undertake
based on or in response to the work of this WG. Chris noted that the
table will work well for folks who are textual and linear learners,
but might benefit from having diagrams depicting the individual
scenarios (eg., a sort of three-pane diagram that would show the
"login SSO system" with users authenticating and possibly some RPs
connected to it, the linked system with its integration point(s) to
the login system and with different RPs connected to it -- a sort of
high-level architecture diagram for folks who process information more
visually than verbally.
Etan: Before I comment, I'd like others to respond... Anyone else
have any thoughts about any of that?
Majeed: I kinda agree with the diagram approach, but I kinda ran out
of time -- I do like the idea of pictorial representations. I pasted
an image kinda like what I'm thinking of, and I feel like that might
be what Chris was aiming for.
Erik: Microsoft is publishing these reference models that might be
worth linking to -- that'd be useful, I think, as well. They cover
linkages in and out of Azure AD -- we could note them as well-known
diagrams, at elast.
Majeed: Yeah -- Microsoft was highlighting those as recommendations a
couple months ago.
Erik: When they're published, they'd be a good resource to use.
Etan: That would cover Azure, but not any of the others.
Erik: Right -- it would just be for the rows that match their
reference model diagrams.
Etan: I'm worried about having too many different diagrams with
different levels of detail and/or different layouts. Is this the type
of diagram we're thinking about?
Erik: A high-level architectural diagram.
Rob: I think we could do implementation architectural diagrams or
generic normalized diagrams.
Etan: I'm opposed to doing diagrams -- I don't think they add anything
that's not already in the text.
Rob: I'll push back just a bit and ask: For the scenarios you're not
directly familiar with, do you think you could necessarily construct a
diagram similar to the one you have for your implementation for each
of them based solely on the text in the table? If so, then perhaps
everyone can do the same, and there isn't a need for any
visualization, but I'm not sure there isn't some relational
information that's not clear from the text but would be in a diagram.
Etan: I think I could go from the text alone to the diagram myself,
but I can't say for anyone else.
Erik: I think some of us are more visually oriented than others -- I
might want to see how things fit together without having to try and
develop the image in my head from the text, especially if I'm not
entirely familiar with the scenario.
Majeed: Agreed -- some folks can get it out of the text easily --
others comprehend the information better in some sort of visual
Majeed: We have high-level diagrams that don't go into the detail of
our actual deployment -- it's purely logical -- what talks to what and
what's where, logically, without the detail of, eg., how many machines
provide each service, etc.
Majeed: I was originally expecting we'd have a link for each scenario
to a separate document -- in that case, the diagram would have been in
the separate document for the scenario. I understand why we chose not
to have separate documents, but if we did, that'd be where I'd have
expected to have diagrams depicting the scenarios visually.
Etan: I think adding iamges would make the table much harder to use.
I've been intending for the table to be used for comparing the
scenarios against each other. I have X and I know I need to add
support for Y, so I pull up the table and compare the scenarios that
include both X and Y to see which advantages / issues each approach
Rob: I'm not sure I see how addign links to diagrams would necessarily
be any more disruptive than having the links to the product pages at
the top for reference? If you want to read the product information,
you can click through the link, and if you don't, you can just ignore
the links altogether. Links of course won't work if someone prints
out the table, but I don't think that's likely to be a common use case
for this -- most folks are going to interact with the document live
online, I expect.
Etan: I put those product URLs in as something of an afterthought --
the original intent was just to define the acronyms, since someone had
noted that they weren't sure what "OAM" was... I understand your
points that some folks may find the images easier to understand, but I
was thinking the point of this document was for folks to be able to
use it for comparison purposes, so any image we include would make the
comparison harder or impossible -- you can't really compare
Etan: Maybe what we need to do is fully normalize the images and have
one diagram for folks to see visually what the mapping of things in
the rows mean...
Etan: I'd be willing to go for a generic image that sorta explains how
the columns map onto a generic model -- the "login SSO system" goes
*here*... the linking strategy fits in *here*, and so on... One image
that describes how to translate the text table rows into generalized
architectural diagrams. I'd be averse to more implementation-specific
diagrams, though, since we decided early on that we were going to
consider "how to" as out of scope for this working group.
Rob: In that case, I might suggest that we could consider having a
sort of one-page-ish introduction in front of the table -- something
of an expansion on the text at the top of the existing table. That
diagram could be part of the explanation of the key scenarios table
itself. Which brings us back to Nicole's suggestion about expanding
Etan: I'd really like to see some of the other documents Nicole would
want to compare this against to get an idea of what she's talking
Rob: To date, this is the first external WG with this degree of focus
that CACTI has sponsored -- most of the other WGs of this nature have
been sponsored by other advisory groups -- TAC, CTAB, etc. Mostly
TAC, actually... I think the idea, though, is that the output from
the WG *includes* the final product (the table) but is produced as a
report back to CACTI documenting the work of the WG and
contextualizing or framing the final product (in this case, the key
Etan: So CACTI wants a report back to CACTI that sorta wraps around
the final artifact (in this case, the table)?
Rob: I think that's basically it. The other part of Nicole's
suggestion was to perhaps bracket the table, and have the final bit
cover any next steps we think might be worth CACTI considering further
investigation or work on. We might actually just note the things we
originally thought were in range of the charter but decided were out
of scope for the work of this particular WG -- eg., "how to" documents
for implementing specific scenarios, possibly more detailed
implementation diagrams for specific scenarios, etc.
Etan: I get it -- and that makes more sense -- we put together a
report that contains the final product.. the report is for CACTI, and
the final product is the part that CACTI publishes as the end result.
Etan: So I think we have a few todos coming out of the meeting today
-- Rob will get the topic on the agenda for CACTI for Tuesday morning,
and will get information to me and Brian so we can dial in for the
CACTI call on Tuesday to discuss this. I'll take a todo to take the
introductory text we have in the table document now and pull it out
into a separate frontpiece with a general diagram describing how to
interpret the columns in the table and a link to the table itself,
which will then be what we take to CACTI on Tuesday for discussion.
And Rob will get the notes out as early as possible from this call so
we can get them approved quickly. We still need approvals for the
notes from last time, unless they've been out for review for long
enough to be approved automatically now...
Rob: I'm not sure, but if no one was on the call last time that wasn't
on the call this time, we could try and say that the notes from last
time were approved by assent.
Etan: I'll send a note to the mailing list and give folks until 10am
ET tomorrow to either add approvals or make amendments, after which
we'll consider silence to be assent to the existing notes, and I'll
move them to the public page.
Rob: And I'll get the notes for today up this afternoon or tomorrow
morning for review.
[ Adjourn @ 15:02 ET ]