Interfederation

[Tom Scavo <>]

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