Interfederation

[Tom Scavo <>]

On Thu, Nov 7, 2013 at 8:28 AM, Scott Koranda 
<>
 wrote:
>
> I would like clarification on this statement:
>
> "Clearly, Internet2 lawyers will have to review any certification
> process that might be put into place. As the CoC spec stands now,
> Internet2 lawyers will also have to review each application submitted,
> to determine compliance with CoC."
>
> I would like to know if that is the official and vetted position of
> InCommon or if a decision has not been made yet on whether I2 lawyers
> would have to examine each application. If it is I would be grateful
> to hear the rationale for that interpretation.

This is my perspective only.

Tom

> On Thu, Nov 7, 2013 at 6:53 AM, Tom Scavo 
> <>
>  wrote:
>> I tried to capture the discussion we had on the Nov 6 call in the wiki:
>>
>> https://spaces.internet2.edu/x/6oKsAg
>>
>> Please correct any omissions or errors.
>>
>> The document contains three recommendations. That may be the wrong
>> approach, I don't know. Maybe we should just report symptoms. I was
>> brave and formulated concrete recommendations instead. If you
>> disagree, we can restructure the document of course. In any case, at
>> least we have *something* going into the REFEDs meeting on Monday of
>> next week.
>>
>> Tom
>>
>>
>> On Tue, Nov 5, 2013 at 8:46 AM, Tom Scavo 
>> <>
>>  wrote:
>>> Ignoring the danger that I may be putting the cart before horse, let
>>> me give a brief Ops perspective on the Code of Conduct service
>>> category. Perhaps Steven and others would like to add a policy
>>> perspective.
>>>
>>> The Charter contains the following deliverable: "Review and adopt the
>>> US-EU Code of Conduct to address privacy and attribute release." That
>>> deliverable is perhaps overly prescriptive but let me proceed in any
>>> case.
>>>
>>> The Code of Conduct has been formulated as a service category. (To
>>> better understand what a "service category" is, here is an
>>> all-too-brief introduction: https://spaces.internet2.edu/x/fgVOAg)
>>> Some federations have already adopted a Code of Conduct service
>>> category and there is a proposal within the REFEDs community to
>>> standardize it:
>>>
>>> https://refeds.terena.org/index.php/Entity_Category_CoC
>>>
>>> As you skim the above document, you will quickly realize that the CoC
>>> is actually multiple levels of documents, each bearing its own set of
>>> requirements. Notably, the SP MUST include a PrivacyStatementURL in
>>> metadata, and moreover, the FedOp "Checks that the Service Provider's
>>> Privacy Policy document is available and indicates commitment to the
>>> Code of Conduct" before tagging the SP with the CoC entity attribute.
>>> As a result, I suspect the Internet2 lawyers will have to review any
>>> certification process that might be put into place.
>>>
>>> It's difficult to isolate all the requirements across this set of
>>> documents but the requirements around RequestedAttributes in metadata
>>> are notable in that the InCommon Federation will have difficulty
>>> meeting them, at least as things stand now. First some technical
>>> background.
>>>
>>> Shibboleth and simpleSAMLphp treat RequestedAttributes in metadata
>>> differently. (AFAIK commercial software doesn't recognize them at
>>> all.) Out of the box, the simpleSAMLphp IdP automatically releases the
>>> RequestedAttributes listed in SP metadata. This is the desired
>>> behavior in EU hub-and-spoke federations (which is where you find
>>> significant deployments of simpleSAMLphp). OTOH the latest version of
>>> the Shibboleth IdP can leverage RequestedAttributes in metadata, but
>>> like all attribute release policy in Shibboleth, that requires
>>> explicit action by the deployer.
>>>
>>> In the InCommon Federation, we support RequestedAttributes in metadata
>>> for informational purposes only. AFAIK there are no IdPs that leverage
>>> RequestedAttributes in SP metadata. Our recommended policy is to
>>> release the entire minimal subset of attributes to ALL SPs.
>>>
>>> Furthermore, we do NOT support the isRequired XML attribute on the
>>> <md:RequestedAttribute> element. There was an extended debate about
>>> that awhile back but I'll spare you the details for the moment. The
>>> upshot is that a RequestedAttribute is optional by default, so that
>>> means that IdPs won't be releasing attributes to an InCommon CoC SP
>>> any time soon.
>>>
>>> At the REFEDs meeting, I will be asking someone (not sure who is
>>> driving this) to consolidate the CoC spec in a single document
>>> (similar to what's been done with the REFEDs R&S spec). Unless someone
>>> has a different idea, I will also recommend that we NOT use
>>> RequestedAttributes in metadata to operationalize the CoC category. I
>>> think the attribute bundle approach used by R&S is a more rational
>>> approach. Given discussion on the REFEDs mailing list over the last
>>> couple of days, apparently there are others in the community that
>>> agree. I guess we'll see how it goes.
>>>
>>> Tom