Interfederation

[Scott Koranda <>]

Hi,

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.

Thanks,

Scott K


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