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

main page.

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: Done.

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

quickly sometimes.

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

the document.

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

scenarios table).

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 ]

  • No labels