InCommon Technical Discussions

["Farmer, Jacob" <>]

We hold ourselves to the branding standards quite strictly. In addition to our self-guided compliance, there is an group that monitors compliance at the university level and a group that coordinates it at the IT level. Intentional non-compliance is not something I would want to consider.

 

As for the rest, two responses:

1)      It’s a standard and I’m obliged to meet it simply because it exists. We (IT) expect others to meet IT standards and it would put us in an uncomfortable position if we elected to ignore the standards that other parts of the organization consider to be important.

2)      Not controlling the background has practical usability impact: The white version of our logo looks pretty bad against beige; the red version would be pretty hard to see if it were rendered against OSU’s red, MSU’s green, or UMich’s blue.

 

I want to stress that I am not arguing a hypothetical use case – I asked our User Experience Officer, who is the authority on these topics for IT, and he is telling me that IU must have control over the background to meet requirements. So I’m presenting this as an IDP operator who seemingly will have to choose whose rules to ignore.

 

I’m also sensitive to the “My First Webpage” concern you mention and I certainly don’t want to discovery service to be a visual mess because icon providers are careless. But I also have confidence in a designer’s ability to make a pleasant-looking icon that retains a non-transparent background when required. The guidance Facebook provides re: solid background seems like a compromise solution on this point.

 

Jacob

 

From: David Langenberg [mailto:]
Sent: Monday, November 13, 2017 1:45 PM
To: Farmer, Jacob <>; Nick Roy <>;
Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

 

Branding standards are nice and all, but I wonder how strictly you'd be held to maintaining them in practice.  I imagine the brand folks would vastly prefer the IU logo look nice on my non-descript-beige background than have it look like My First Webpage from 1997 because the rules say "must be red or white background"?

 

 

--

David Langenberg

Asst. Director, Identity Management

The University of Chicago

---

From: <> on behalf of Farmer, Jacob <>
Sent: Monday, November 13, 2017 12:33:43 PM
To: Nick Roy;
Subject: RE: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

 

Nick,

Thanks for posting the revision. It does not seem to include the information Dave shared from the Facebook policy. I think that would be useful clarification to have; by IU's brand standards, we would be required to use either a red or white background and I think Facebook's guidance about using a colored background or colored border is a good revision to add to the InCommon standard.

Also, I completely agree with having a standardized dimension, but I am not sure where this exact dimension came from. Has there been a survey done of widely-used identity selectors to make sure that resolution is commonly used? (and it's entirely possible this was done and I just missed that part of the thread)

Jacob

-----Original Message-----
From: [] On Behalf Of Nick Roy
Sent: Friday, November 10, 2017 4:10 PM
To:
Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

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" <> 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:
>>     >     [] 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
>>     >     >
>>     >     >
>>     >    
>>     >    
>>    
>>    
>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature