Overview

Operational Practice Statement for SAML: Operational Practice Statement - SAML profile

Metadata Aggregation Practice Statement for SAML: Metadata Aggregation Practice Statement

eduGAIN Best Current Practice as a SHOULD (CoCo, Sirtfi, R&S). 

Metadata Management Practice Statement might be a better way of referring to the process and aligning across both SAML and OpenID Federation described within that.

Agree to use term OIDFed. 

Metadata Registration Practice Statement

Metadata Registration Practice Statement

ShibMD for scope information

Metadata Registration is fundamentally different in OpenID as everyone effectively publishes their own metadata and then this gets built up. It's more metadata collection. 

It's publication and collection? When we collect and sign it, we make specific statements about it. The distribution process is different, the way in which we try to apply trust via a trust anchor is very similar. 

Add comparitive workflow on how OpenIDFed and SAML metadata production differs.

Current reliance on a non-machine readable document and we do not have any strong requirements over what is included, this is left to federations to describe local practice.  Does this still meet objectives or is another approach required? Note it is only a template, not a set of standards / requirements. 

Current MRPS only speaks to SAML requirements. 

Scope is a big issue as we use it heavily to relate to affiliation and assumptions made about that. OpenIDFed cannot bind scope of claim to scope of entity.  Is this something we need to look at across both specifications?

Need to do more work on what we are doing with Scope - point of it is a real-time check to avoid impersonation.

For scope, we can have a similar mechanism we have now. We want the fedop to be authoritative for which scopes a given OP may use. 

In the OIDfed context we can have the fedop run a TrustMark Issuer that makes "scope" statments about OPs

How do we apply the rules - we DON'T trust the entities, we trust the national federations in the SAML model. OpenID is a collection model. 

Policies are published in trust anchor - machine readable.  How do we enforce metadata policy rules.

SAML Metadata Production

Basic requirements on how federation metadata is formed and minimum standards for the metadata published by the federation

The SAML Metadata root element MUST contain:

A validUntil attribute with a value not earlier then 120 hours (5 days) and not later than

2304 hours (28 days) after the creationInstant.

<mdrpi:PublicationInfo> with publisher and creationInstant.

Each <md:EntityDescriptor> element MUST contain:

<mdrpi:RegistrationInfo> .

mdrpi:registrationAuthority with a value that has been registered with the eduGAIN

Operational Team.

<md:Organization> with values in English other values in the service's native languages for the elements where appropriate.

<md:OrganizationName> .

<md:OrganizationDisplayName> .

<md:OrganizationURL> .

<md:ContactPerson> with contactType="technical" and/or contactType="support" .

entityID prefixes that start with either urn: , https:// , or http:// only.

The <md:EntityDescriptor> SHOULD contain:

<mdrpi:RegistrationPolicy> .

If the <md:EntityDescriptor> contains <md:IDPSSODescriptor> it SHOULD contain an

<mdui:DisplayName> element and <mdui:Logo> element.

If the <md:EntityDescriptor> contains <md:SPSSODescriptor> it SHOULD contain an

<mdui:DisplayName> element, <mdui:Logo> element and an <mdui:Description> element

with a value in English. Where the service supports other languages, these values

SHOULD be supported for those languages.

If an <mdui:Logo> element is present, the logo MUST be expressed as a Data URI

(embedded logo) or an https URL. URLs used for this element MUST be publicly

accessible.

eduGAIN Metadata Aggregation Practice Statement

md / mdui  / mdrpi

Entity Statement

Informational Metadata Extensions

SAML Metadata Signing

Requirements for metadata signing

Public keys used for signing are at least 2048 bits in length. At least 3072 bits is RECOMMENDED for new deployments.

EC public keys are at least 256 bits in length.

The signature is made using an explicit ID reference, not an empty reference.

The signature reference refers to the document element.

The signature's digest algorithm is at least as strong as SHA-256, and does not use MD5 or SHA-1.

The signature's signature method is RSA with an associated digest at least as strong as SHA-256 and does not use MD5 or SHA-1.

The signature's transforms contain only these permissible values:

Enveloped signature.

Exclusive canonicalisation with or without comments.

SAML V2.0 Metadata Interoperability Profile Version 1.0

Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0

eduGAIN Metadata Aggregation Practice Statement

signed JWTs

SHOULD support signature verification with the RSA SHA-256 algorithm

SAML Metadata Publication

Participant Federation Requirements

Adherence

Process for monitoring and addressing non-compliance with the requirements set out

Series of BCP are mentioned here - this is probably not the best approach and has little in terms of incentives to enforce 

Mandatory Entity Requirements

This does not currently exist but the suggestion of introducing a privacy statement and Sirtfi as mandatory requirements would require this to be added.  Should this be part of the metadata production requirements or separate? 

Proposed new requirements for SAML Profile:

https://refeds.org/metadata/contactType/security

mdui:PrivacyStatementURL

https://refeds.org/assurance (e.g. core conformance criteria for baseline only)