Interfederation

[Tom Scavo <>]

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