Page History

I wonder if the signing section of the profile should bot use a more

formal 

language,

like

this

borrowed

from

Ian,

modified

and

used

in

the

Aggregation

Statement

document:

In order to assure metadata integrity and originality, each federation aggregate MUST be signed as specified in [Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0].

This

signature

made

with

the

key

matching

the

one

supplied

to

the

eduGAIN

OT

is

the

only

element

on

which

trust

is

based.

In

particular

the

eduGAIN

aggregator

does

not

use

trust

that

might

be

derived

from

an

https

endpoint

details.

Metadata

signature

verification

is

done

against

the

public

key

alone.

If

the

public

key

for

the

channel

is

supplied

in

the

form

of

an

X.509

certificate,

other

aspects

of

the

certificate

such

as

its

expiry

date

do

not

form

part

of

signature

verification.

This

is

in

accordance

with

the

SAML

metadata

interoperability

profile.

In

particular

an

expired

certificate

will

still

be

used

for

the

verification

purpose.

Replace: "The organisation with which the end users are affiliated."
with: "The organisation with which an end user is affiliated."

Typo: SAML Profil  -> SAML Profile

1. The aim of this profile seems to be to improve interop among entities in different federations by means of definng common practices by fed ops and edugain ops. Interop issues can sometimes result from different filtering policies implemented by different federations when they consume edugain metadata. Examples include federation-specific standards for end point scheme (HTTP vs HTTPS) and minimum key length (1024 vs 2048+). Is this profile the right place at which to define eduGain-wide standards for such things? If so, is this the right time to consider doing so in these two instances?

2. Members of federations are advised by their federations' operators to check the signature of their federation metadata to verify its authenticity and integrity. Does eduGain do likewise in the process of aggregating member federations' metadata for redistribution? If not, should it, and if it does not but should, is this profile the right place in which to address that requirement?

 line 111 change SHOULD to MUST

RegistrationInstant and mdrpi:RegistrationPolicy are only OPTIONAL within the RPI spec so current proposal is consistent. This is because old entities will not have this data.

md:OrganizationDisplayName   can be advanced to a MUST.

Chris/CAF: No additions specific to key rollover but a request for improved operational state information on the technical.edugain.org website
No specifics to key rollover but it would be useful to have a way to render a time difference for publishing time on the eduGAIN OT website. 
Many federations exhibit latency on republishing stemming from operational practices and offline signing techniques. It would be helpful to know in a dashboard fashion the following:

• Last update of mds.edugain.org
• And per federation last known update of eduGAIN data and time difference since MDS publishing.

This will go a long way in managing expectations of when to expect data to circulate beyond '24-48hrs'. I suggest a simple table view of flag and age difference from MDS so we may know how far we all drift from each other republishing data from the eduGAIN MDS 'creation date'. While this could exist in the 'twisty list' for each federation,  one visual dashboard page of observed latency would be more helpful in this regard.

regex scopes should be permitted and eduGAIN should ensure scopes do not collide when accepting aggregates from Members (see longer notes)

There are few legitimate uses of regexp scopes that even UKf accepts. IMO it's a SHOULD. One should have no worries about the entity being silently discarded somewhere if it violates a SHOULD.

Actually the Scope element is only a subset of the issue of using internet domain names in metadata.

Domain names are significant (in terms of security):

* entityIDs

* endpoint URLs

* scopes

I'd suggest to include a more generic section about using domain names in metadata, and include the special requirement of Scope's not being a regexp here.

Chris Phillips

Kristof Bajnok

They MAY exist and should be strongly encouraged with 'SHOULD'.  'MUST' would be very hard to do but having 'SHOULD' will keep parity to these features across multiple technologies like OIDC and moonshot. See below for more on this.

• Recommended attributes and mapping across the given attribute profiles
• Vocabulary
• Unique identifier practices
• Entity categories (or mapping within given technology profile to exhibit it)
• Consistent application of scope within the technology profiles
• Security characteristics such as position on logout

Remove requirement for the element md:OrganizationURL to have values in English (xml:lang="en"): Some Organisations simply do not have English language web sites and it's beyond our control to mandate one. (Though arguably that falls under the kind of exception allowed by "SHOULD".)

Remove requirement/recommendation (and the matching check in the eduGAIN validator) for the element mdui:Description for entities of role IDP. (1) Often nothing useful can be put there (values like "IDP of Organisation Foo" are semantically void) and (2) I don't know of any software that makes use of that element.