Date: Fri, 29 Mar 2024 11:59:16 +0000 (UTC) Message-ID: <1857226721.7921.1711713556357@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7920_1285814730.1711713556356" ------=_Part_7920_1285814730.1711713556356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
[AI]<=
span style=3D"color: rgb(51,51,51);text-decoration: none;"> Eric to s=
tart discussion thread on how to handle term endings. Janemarie will =
start a google doc with some of the summary/thinking so far, share with Eri=
c. DONE
[AI]<=
span style=3D"color: rgb(51,51,51);text-decoration: none;"> Janemarie will =
reach out to Ann and talk/go from there to finalize the proposal regarding =
Working Group co-chairs and flywheels. IN PROGRESS
(AI) Mark wi= ll discuss the structure of the Attribute Release working group with Steeri= ng Chair Sean Reynolds. DONE
(AI) Tom Barton will check with Jim Basney on this, as well.
(AI) Mark Scheible will revise the Attributes for Collaboration and Fede= ration WG charter for additional review and send it to technical-discuss.&n= bsp;DONE
(AI) Ann or Kevin talk with Klaas Weirenga from G=C3=89ANT about a prese= ntation to TAC meeting concerning their T&I roadmap for, say, the next = 3 years? <=3D Deferred to August
Members= Attending: Mike Grady, Jim Jokl, Eric Goodman, Mark Scheible, Tom Barton, St= eve Carmody, Kim Milford, Albert Wu
With:= span> Dea= n Woodbeck, Nick Roy, Ian Young, Tom Scavo, Ann West, IJ Kim, Steve Zoppi, = Paul Caskey
(AI) TAC should= review the IdP strategy document (https://spaces.at.internet2.edu= /x/FgrkAg)
(AI) TAC should= review the information for IdPs on the wiki and consider useful additions = and revisions.
https://spaces.at.internet2.edu/display/in= ctac/Ops+Update+2017-07-06
Metadat= a Aggregator - working on deploying v7.1. Also two versions waiting in the wi= ngs. One will implement the new policy re: entity attributes (switching to = default-allow). Beyond that, there are several modifications in the pipelin= e - this will likely become v8.
ADFS Is= sue - Dealing with an issue with ADFS4 consuming InC metadata aggregate. ADFS= 4 is strict on how it parses an aggregate. If there are non-unique indexes,= ADFS4 chokes. Working on that. Will also need to work with eduGAIN on reso= lving, as well
FM Bug<= /span> - = The FM dev team found an issue with creation of duplicate ACS index values = in SP metadata. The FM uses optimistic record locking. When more than one p= erson edits an SP at the same time, or one person has multiple SP edit page= s open for the same SP, the problem can occur.
Standby= Metadata Server Move - The standby metadata server is moving from Indiana to= the data center in Los Angeles. The LA server has been deployed. Ops is wo= rking on a deployment plan on the move, including communications to inc-ops= -notifications. Transition should be complete mid-August
Architects meeting in Denver in two weeks
<= /li>New project manager Erin Murtha has started
Have hired new DevOps and Security staff members - an= nouncements forthcoming
Had planned a release end of this week or early next = week. The first visual evidence to customers. Because of the non-unique ind= ex issue, the release is delayed (probably two weeks to an FM release).
Future release will allow some self service (such as = execs maintaining their site admins/roles) and other changes
Timeline - https://spaces.at.internet2.edu/x= /SpGTBg
Process kicks off September 1, with the roster finali= zed by November 9
Announcements have gone to technical-discuss= p>
Discovery 2.0 - REFEDS steering meeting will meet Jul= y 12 concerning this year=E2=80=99s work plan and is expected to discuss Di= scovery 2.0. Should REFEDS create a working group, InCommon should particip= ate in that. There is some urgency if something is to be done in conjunctio= n with the next Shibboeth SP release (which will be end of the year)=
There was discussion of the RA21 project, which is ad= dressing the same general issue. There is a pilot planned (Leif is the cont= act person). Ra21.org= a> is the website
The topic of po= tentially providing IdP as a Service came up on the TIER Packaging Working = Group call, as they discussed making Shibboleth easier and developing a GUI= for Shib. This seems to be a better fit with InCommon. Several ideas/issue= s were discussed:
Would it make sense for InCommon to operate such a se= rvice?
Should InCommon develop a document to help clarify is= sues for campuses considering outsourcing their IdPs? Examples would be min= imum expectations of the vendor, portability, support for InCommon profiles= , and support for importing a metadata aggregate and/or per-entity metadata= distribution. Such a document could be a cookbook and/or something that a = campus could use as part of an RFP.
Another option might be offering a =E2=80=9Ccontainer= as a service=E2=80=9D based on the TIER Shibboleth Docker container=
Reference: InCo= mmon Software Guidelines
Reference: Tech= nical Basics for IdP Operators from Alternative IdP WG Report: https:= //spaces.at.internet2.edu/display/InCFederation/Recommended+Practices#Recom= mendedPractices-TechnicalBasics.
The webinar cov= ered these 9 questions:
Where is it hosted?
Is there any vendor lock in?
Do you have full control?
How easy is it to set up and what maintenance a= re you responsible for?
Can you host onsite?
How flexible is the solution?
Are statistics provided?
Is there support to set up 3rd party SPs?
Does the service have a reliable track record?<= /span>
(AI) TAC should= review the IdP strategy document (https://spaces.at.internet2.edu= /x/FgrkAg)
(AI) TAC should= review the information for IdPs on the wiki and consider useful additions = and revisions.