InCommon Technical Discussions

[Steven Carmody <>]

I think InCommon is already past the point where the "profile" of a 
typical installation/site/sysadmin has drastically changed from the 
early days. Growth has brought changes. A major implication of that 
statement is that the type of documentation that IC provides will have 
to change. The TAC was recently discussing whether its now reasonable to 
expect that a campus sysadmin would know how to "create" a local proxy 
server. The errorURL documentation is another example of this question 
-- I believe its exhaustively documented for some sysadmins, but 
under-documented for a growing proportion of the IC member sites.

re "I would suggest that the community start working groups ... to 
determine what the requirements are"

I think that's a great idea, but I'm not aware of any process that could 
be used to do that.

Since this is a Policy Issue, shouldn't the AAC create a WG ?

On 11/14/17 3:52 PM, Nick Roy wrote:
> The errorURL is exhaustively documented at:
>
> https://spaces.internet2.edu/display/InCFederation/Error+Handling+URL
>
> The mdui:PrivacyStatementURL is less thoroughly documented in the
> following places:
>
> IdP:
> https://spaces.internet2.edu/display/InCFederation/IdP+User+Interface+Elements#IdPUserInterfaceElements-IdPPrivacyStatementURL
>
> SP:
> https://spaces.internet2.edu/display/InCFederation/SP+User+Interface+Elements#SPUserInterfaceElements-SPPrivacyStatementURL
>
> The SP privacy statement documentation offers a bit of a chicken-and-egg
> problem in that it refers to the POP, which will be deprecated by
> Baseline Expectations.
>
> If the community wants guidance on what it expects of itself in these
> documents, I would suggest that the community start working groups or
> something to determine what the requirements are.  The 'testables' that
> InCommon operations will be checking for are merely the existence of the
> relevant URLs in metadata and that they give an HTTP 200 in response to
> a GET.
>
> Nick
>
>
> On 11/14/17 1:45 PM, Steven Carmody wrote:
> > I assume IC will be providing guidance for both the Privacy Statement
> > and the errorURL page ?
> >
> > I think IC should list the points related to Federated Authentication
> > that should be covered in the Privacy Statement, while making it clear
> > that this list is a minimum, and other topics can also be addressed.
> >
> > With the errorURL page, I think IC could be rather specific in its
> > suggestions about both content and layout, in order to achieve some
> > level of consistency from site to site.
> >
> > Without some guidance, I think we'll merely repeat our experience with
> > the LOGO images.
> >
> > On 11/10/17 4:09 PM, Nick Roy wrote:
> > > Here's an updated version of the wiki, please review:
> > >
> > > https://spaces.internet2.edu/x/4RL9Bg
> > >
> > > Nick
> > >
> > > On 11/10/17 8:52 AM, Nick Roy wrote:
> > > > Nice
> > > >
> > > > I'm going to collate all the info from this discussion and update the
> > > > wiki page and our internal gdoc with the info today.
> > > >
> > > > Nick
> > > >
> > > > On 11/10/17 8:35 AM, David Shafer wrote:
> > > > > FYI, here is Facebook’s policy for app icons, which seems to work
> > > > > pretty well:
> > > > >
> > > > > “4. Icons:
> > > > > a. Use a transparent or colored background. If your icon requires a
> > > > > white background, use a colored border.
> > > > > b. If your logo has a drop shadow, use a colored background.”
> > > > >
> > > > > https://developers.facebook.com/policy/
> > > > >
> > > > > Dave
> > > > >
> > > > > -----Original Message-----
> > > > > From: 
> > > > > <>
> > > > >  on behalf of Nick
> > > > > Roy 
> > > > > <>
> > > > > Date: Thursday, November 9, 2017 at 4:05 PM
> > > > > To: Chris Phillips 
> > > > > <>,
> > > > >  "Farmer, Jacob"
> > > > > <>,
> > > > >  "Cantor, Scott" 
> > > > > <>,
> > > > > ""
> > > > >  
> > > > > <>
> > > > > Subject: Re: [InC-Technical] InCommon Baseline Expectations
> > > > > Metadata Requirements
> > > > >
> > > > >       I'll point out that the SSL test is a *recommended* piece but
> > > > > *not
> > > > >       required* in the current specification of Baseline Expectations.
> > > > >            To restate what I've heard so far:
> > > > >            Logo URL:
> > > > >            - results in a 200 via HTTP GET
> > > > >       - is a PNG with a transparent background / alpha channel
> > > > > (because JPG
> > > > >       does not support transparency)
> > > > >       - is 80w x 20h
> > > > >            SSL for endpoints:
> > > > >            - subject to InCommon operations' running of SSL scans
> > > > > (exact nature to
> > > > >       be determined by operations)
> > > > >       - operations may save and act on information about the quality
> > > > > of SSL at
> > > > >       its discretion
> > > > >            (no minimum grade or other requirement related to SSL)
> > > > >            errorURL:
> > > > >            - results in a 200 via HTTP GET, other results cause a
> > > > > warning but not a
> > > > >       full failure of the baseline tests
> > > > >       (do we need to say something about 302 and maximum depth to chase
> > > > >       referrals before lack of a 200 causes failure?)
> > > > >            How does that look?
> > > > >            Thank you,
> > > > >            Nick
> > > > >            On 11/9/17 8:47 AM, Chris Phillips wrote:
> > > > >       > Great dialogue on this.
> > > > >       >
> > > > >       > Maybe it would be better to define what’s not acceptable
> > > > > regarding a grade and what’s a reasonable duration to remediate.
> > > > >       >
> > > > >       > Highest grade (A+) preferred but no lower than C on ssllabs
> > > > > and no longer than say X days below this band of acceptance.
> > > > >       >
> > > > >       > This gives latitude to maneuver when the tools change
> > > > > underneath one’s feet and dependencies to catch up.
> > > > >       > Jacob’s example is great in this regard. If his group didn’t
> > > > > care about it (or know to test that way) then how would he have
> > > > > pushed for the change to get back into compliance and hence
> > > > > pressured the vendor to step up?
> > > > >       >
> > > > >       > That said, things like Poodle SSLv3 and other future events
> > > > > we know will happen will change ranking from A+ to F overnight.
> > > > > Using the idea of X days to come into compliance allows us to
> > > > > respond commensurate with the risk.  It also allows us to simply be
> > > > > users of the tool which is not our core mission – we just want the
> > > > > output to inform our decisions.
> > > > >       >
> > > > >       >
> > > > >       > C
> > > > >       >
> > > > >       > On 2017-11-09, 9:53 AM, "Farmer, Jacob"
> > > > > <
> > > > >  on behalf of
> > > > > >
> > > > >  wrote:
> > > > >       >
> > > > >       >     Nick,
> > > > >       >
> > > > >       >     I like the Qualys SSL scanner and we use it often. Given
> > > > > my history, though, I
> > > > >       >     am reluctant to rely on it for this kind of thing. A
> > > > > real-world story from the
> > > > >       >     last few years: Qualys made a change to the scanner
> > > > > which caused sites we
> > > > >       >     manage that were in the A range to fall into the B+
> > > > > range. I don't recall all
> > > > >       >     of the details about why; I think it had to do with
> > > > > cipher suites. Our load
> > > > >       >     balancer -- a widely deployed product on its current
> > > > > version -- could not be
> > > > >       >     adjusted to bring it back up to A. There was something
> > > > > in the configuration
> > > > >       >     that Qualys simply didn't like and there was no way to
> > > > > fix it until a vendor
> > > > >       >     patch shipped.
> > > > >       >
> > > > >       >     I'm glad that we took the time to get it figured out,
> > > > > but I also don't think
> > > > >       >     that the quality of SSL was meaningfully degraded in the
> > > > > interim.
> > > > >       >
> > > > >       >     I support the idea of defining "good TLS" but I am
> > > > > reluctant to rely on this
> > > > >       >     scanner to define it.
> > > > >       >
> > > > >       >     Jacob
> > > > >       >
> > > > >       >     -----Original Message-----
> > > > >       >     From: 
> > > > >
> > > > >       >     
> > > > > [mailto:]
> > > > >  On
> > > > > Behalf Of Nick Roy
> > > > >       >     Sent: Wednesday, November 8, 2017 4:59 PM
> > > > >       >     To: Cantor, Scott 
> > > > > <>;
> > > > >
> > > > >       >     Subject: Re: [InC-Technical] InCommon Baseline
> > > > > Expectations Metadata
> > > > >       >     Requirements
> > > > >       >
> > > > >       >
> > > > >       >
> > > > >       >     On 11/8/17 1:58 PM, Cantor, Scott wrote:
> > > > >       >     >> RECOMMENDED:
> > > > >       >     >>
> > > > >       >     >>    SSL certificates on endpoints are valid
> > > > >       >     > That seems like a slippery slope: valid re: dates?
> > > > > Specific CAs? Key sizes?
> > > > >       >     > What about ciphers, or use of TLS 1.0, etc.?
> > > > >       >     >
> > > > >       >     > Requiring a logo is, I think, underspecified, we
> > > > > should mandate specific
> > > > >       >     > size(s).
> > > > >       >     >
> > > > >       >     > I'd like to see errorURL be required with guidance
> > > > > around what should be
> > > > >       >     > behind it.
> > > > >       >
> > > > >       >     We think errorURL should be included as well, but since
> > > > > it was not part of the
> > > > >       >     'required' elements that AAC specified (AAC assumed
> > > > > errorURL was part of the
> > > > >       >     mdui: information, and it is not) that means this would
> > > > > have to go back to ACC
> > > > >       >     to make errorURL a separate required element.
> > > > >       >
> > > > >       >     Agree re: specific requirements for SSL and logo.
> > > > >       >
> > > > >       >     Here is my proposed requirement for SSL for endpoints
> > > > > (since it's recommended
> > > > >       >     but not required):
> > > > >       >
> > > > >       >     - Achieve a grade of A on the Qualys SSL scanner [1]
> > > > >       >
> > > > >       >     And for HTTPS Logo URL:
> > > > >       >
> > > > >       >     - Must result in an HTTP 200 in response to a GET request
> > > > >       >     - Image must be either a PNG or JPG
> > > > >       >     - Image must be 80 pixels in width by 60 in height
> > > > >       >
> > > > >       >     [1]
> > > > > https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
> > > > >       >
> > > > >       >     Let me know if you think this is something that would
> > > > > better be discussed in
> > > > >       >     detail by the Ops Advisory Group or in some other venue.
> > > > >       >
> > > > >       >     Thank you,
> > > > >       >
> > > > >       >     Nick
> > > > >       >
> > > > >       >     >
> > > > >       >     > -- Scott
> > > > >       >     >
> > > > >       >     >
> > > > >       >
> > > > >       >
> > > > >