Thomas Lenggenhager (SWITCH) provided you are careful not to annoy the security contacts

Wolfgang Pempe (DFN): our plan is to perform some test alarm at least once a year

Standardisation/spec via refeds

Prototype implemention for aggregation.

Protoype implementation for federation level infra.

Pilot.

The aggregated metadata of eduGAIN is under constant change as entities get added, removed, or changed. While daily backups are made, there is no event-based changelog and no trace of which change was made when. When an entry of interest is examined, the search for the exact event timestamps of changes pertaining to that entry are tedious by searching old copies of the entity database manually.

The proposed system stores any change to the metadata aggregate one-by-one in a ledger as soon as it happens. That way, even intra-day changes (between daily database backups) can be observed and a "rewind" of the entity list to specific point in time becomes simple.

For improved traceability of any changes, the ledger can be made distributed and authenticated in the way that both the publishing eduGAIN participant (sending side) and the eduGAIN OT (receiving side) both sign the change in a distributed ledger.

The ledger would be distributed so that each eduGAIN federation maintains a copy. With that, changes made automatically synchronise between federations and a manual polling of per-participant feeds (by eduGAIN OT) as well as a periodic download of the aggregate (by eduGAIN participants) becomes superfluous.

eduGAIN OT still maintains its role as metadata policy verifier by signing only such changes in metadata which result in eduGAIN policy conformant metadata. As a positive side-effect, this changes the granularity of metadata rejection from a per-participant (country-wide) effect to a per-entity effect, reducing outages due to metadata of entire participant federations vanishing.

The solution developed here is not limited to eduGAIN exclusively; it can also be used inside a federation to collect and sign individual pieces of metadata, thereby assembling its own metadata set in the same way.

Where IdPs or SP choose to maintain a copy of the ledger, they can immediately and in real-time see any changes and implement them in their entity; resulting in an experience similar to the MDX proposal above. They can choose to incorporate only entries signed by their own federation, or a superset to their liking.

Standardisation/spec via refeds

Prototype implemention for aggregation.

Protoype implementation for federation level infra.

Pilot.

Wolfgang Pempe (DFN): encourage cross-federation support for mdui:Keywords.

SURFnet: no catalog will survive if the (meta)data is not/cannot be maintained or is not of sufficient quality. I think therefore we need to address the root cause (as well). How prevent keeping a shadow "metadata" registry for this?

José Manuel, SIR/RedIRIS: We are developing such a service catalog for our federation now, and am interested in this. Also, agree with Wolfgang, and SURFnet... regarding the SURFnet question, the catalog could have both "static" (collaborative information, with the possibility of letting the providers administrate its own information) and "dynamically gathered" information (from metadata) for a certain entity in the catalog.

Rhys Smith, UKf: I think it's a laudable goal, and one worth exploring. For me, there are two main issues - deciding categorisation in way that works for everyone, and appropriate resourcing to both do the initial step of building the catalogue and effort to maintain it moving forwards. As soon as it's not kept up to date, it's not useful any more.

Mario Reale (GARR) - Relevant to ease human-friendly interaction with eduGAIN.

Vlad Mencl (Tuakiri/REANNZ): we have a service catalogue produced by our Federation Registry: the additional data needed for the catalogue is collected alongside metadata submission.  I think automation is the only way to keep the catalogue current - and aggregation from individual federations is the way (either in parallel with metadata, or inside the metadata).

The scope part of attributes means critical security context for many applications. Currently the only way for an SP to check whether an IdP is allowed to use a scope is based on verification of shibmd:Scope metadata extension. As metadata might  originate from a massive number of sources, an organization and/or an SP might want to provide additional means to verify scope usage. If the scope equals to a real domain name, it can be easily implemented by adding TXT records to the domain record that describe the allowed entityIDs which can assert the scope. (Similar to SPF - Sender Policy Framework.) This should be an optional measure in addition to existing metadata-based scope verification technique.

standardization - REFEDs?

implementation for Shibboleth and SimpleSAMLphp

Nick Roy, InCommon

Constantin Sclifos, RENAM

Rhys Smith, UKf: Sounds like an interesting idea. Would require changes to SP software though, of course, which means it'd be a very long term rollout. Worth exploring the idea in principle though.

Worth taking a closer look at this (Mario Reale /GARR)

SURFnet: Can this be solved by making this the responibility of the registar. Speaking for a hub-and-spoke registrar that already does it this way, forcing IdPs to administer TXT records for this is quite a burden for them.

Kristof: the concept is to provide an end-to-end solution to protect the scopes that works even with broken metadata sources/registrars.

Wolfgang Pempe, DFN: "can be easily implemented" sounds harmless, but carrying this out on federation level implies contacting several hundreds of IdP operators and providing support to them... 

Wolfgang Pempe, DFN: How is this supposed to work for a full mesh federation?

SURFnet: We support the notion of having good security operations in trust and identity but in the geant project this should probably be developed in the security activity.

Rhys Smith, UKf: Agree with SURF, sounds interesting, but isn't this a security area topic?

Nick Roy, InCommon

SURFnet

Rhys Smith, UKf: +1 in principal, but reserving judgement until we see the output of RA21 to be able to understand the scope of this.

Wolfgang Pempe, DFN: agree with Rhys. An embedded DS should always be the first choice, anyway.

Mario Reale, GARR: agree with Rhys Smith's comment.

The eduGAIN technical website would benefit it's members by having a central overall status dashboard that renders a single page with eduGAIN stats with initial focus on latency estimates for metadata circulation. This page should auto-refresh every X seconds/minutes as a configuration. It would be a 'nice to have' if this were operationally friendly such that someone could have it presented in their NOC control center on a screen and also have the data published at an API endpoint such that someone can publicly poll the information in JSON and then in turn render it on their own.

The problem this addresses is the knowledge gap about the state of the system without requiring operational questions or gueses. 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 (inferred by eduGAIN ops tools based on publishing practices in a best effort style calculation)

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'.

CAF, obviously

SURFnet

Rhys Smith, UKf: We've actually just been talking about how something like this would be good. I'm sure Sirtfi folks would be interested in this as well as it directly impacts on the time to full resolution for security incidents mitigated by MD changes.

Wolfgang Pempe, DFN

Schema standardisation - MACEDir is being rechartered, there is eduPerson, SCHAC, where is the global conversation taking place in the eduPerson?

Ability to leverage the relationships with Microsoft and ADFS - Attempted for many years to influence microsoft to improve ADFS not very successful. We need as a global edu community to have some more leverage.

I know the eduGAIN support team already uses a TTS, but I think we could go a step further and have a central TTS with federated access support, to track issues with the appropiate persons from any of the involved parts.

The service should be able to gather information from metadata, including federation operators, and all entities participating in eduGAIN contacts. Of course, these tools would also use e-mail as a communication channel.

Thomas Lenggenhager (SWITCH) provided you are careful not to annoy the security contacts

Wolfgang Pempe (DFN): our plan is to perform some test alarm at least once a year

Tom Barton: +1, and let's try to ensure that each contact is tested by only one testing activity, ie, perhaps the Geant activity should be formulated as a complement to other activities that are/will test contacts in their federations/areas.

Scott Koranda for LIGO +1

Rhys Smith, UKf: Exactly the same comment as Thomas. Good idea in principal, but have to be VERY careful not to annoy security contacts, as they'll stop responding in a timely manner if all they generally get is test messages. Would suggest consultation with CSIRT folks about how they do this today, and follow that model.

Mario Reale: +1 - of course avoiid spamming

Rhys Smith, UKf: Wot Lukas said - Can find this out from MD already? Is there enough evidence from potential users that a different way to get this info would significantly improve their lives?

Scott Koranda, LIGO: No, one cannot find this out from MD already because immature federations do not support their entitites being able to register SIRTFI compliance. This is not likely to change soon enough to satisfy the needs of large international projects like LIGO and CERN. Having a separate SIRTFI registration process outside of eduGAIN metadata is necessary and strongly desired by those communities.

Rhys again: My comment is not about helping federations that can't register Sirtfi, it was purely about the first part - an API query to find out whether an entity supports Sirtfi. These two items are separate things and shouldn't be conflated, as neither / either / both could be worked on. So i'm unsure about the API bit, c.f. my comment. I'm broadly +1 for the second bit - not a fan ideologically, but pragmatically can see the benefits.

(Wolfgang Pempe, DFN: outside federation metadata? IMHO not a good idea. This would lead to inconsistencies.)

Tom Barton: Once Wolfgang hears the details, he'll say it's a good idea!

Lukas Hämmerle, SWITCHaai: I don't exactly see the need for a query service if this information can be relatively easy retrieved from metadata. Then again I suspect this would be relatively easy to implement and given that there is already an API (https://technical.edugain.org/api.php) to query all sorts of eduGAIN-related things, this would probably be only  a small addition. (Comment from Scott Korand to Lukas–it cannot be easily retrieved from metadata because not enough federations are mature enough to support entitites registering Sirtfi. The descrition includes "outside federation metadata" as it should.)

SURFnet:

• Niels van Dijk: An independent registry outside of eduGAIN may carry a different trust level, and hence could be a resolution to challenges around mixing data with different trust levels. I therefor do not think this is the same thing as "Allow eduGAIN OT to enrich MDS metadata" below.
• -1: Many doubts. Sounds like an shadow metadata registration and/or confusion of the aggragator / registration roles (Pieter van der Meulen)

Scott Koranda for LIGO +1

Mario Reale / GARR

Rhys Smith, UKf: Interesting idea in theory, but need to articulate potential users of this portal, how they'd consume the information, who would moderate it (could easily do bad things with such a portal), and who would manage it.

Wolfgang Pempe, DFN: I agree with Rhys

Scott Koranda for LIGO + 1

Mario Reale / GARR

Nick Roy, InCommon, SURFnet

Rhys Smith, UKf: Yes.

Mario Reale / GARR

In the current eduGAIN SAML Profile work there is an effort to develop BCP to position a lot of the current "step-up" processes we have as a set of best current practice for eduGAIN.  Within eduGAIN, these will be positioned as what we consider mature entities  / federations to look like...and this could even possibly be flagged somehow.  The current requirements of eduGAIN will be promoted purely as a baseline and a "first step" to interoperability (acknowledging use cases that don't need any more than that).  The next logical step from that is to review whether there is any need to offer a central service to manage that maturity level for federations / entities as a bolt on to existing federation operations. This could take on a variety of forms and draw in a lot of the areas that have been proposed here. Options and areas could be:

1. Response Testing for Security Contacts.  For entities claiming support for SIRTFI, a regular response test exercise will be undertaken building on experience gained in operating Trusted Introducer.

2. Developing the eduGAIN technical database further to flag maturity for federations / entities based on the eduGAIN Best Current Practice documentation.

3. Working with external registries, such as a PEER registry for community-based aggregates (as described in the eduGAIN Disruptive paper).

4. Developing processes to allow MDS to select the most mature entity formulation within federations rather than simply the first submitted.

5. Working with eduGAIN Support to proactively follow up on errors and issues flagged by the eduGAIN Technical Database.

6. Standardise metadata registration and publication across eduGAIN federations.

Nick Roy, InCommon

Rhys Smith, UKf: Sounds interesting, as long as long as we can decide what a "mature" federation/entity is, and who would be consuming this information, and for what purpose.

SURFnet: It is unclear to us what is the purpose for this work and who will be the users.

Mario Reale / GARR - same sort of concerns as previous item. However in general, I prefer to address the trust issues at the lower level of the stack: the federation themselves.

 Chris Phillips - CANARIE – see related collab area: https://wiki.refeds.org/display/GROUPS/Incubator

Rhys Smith, UKf: Still not 100% convinced of the use case as MDQ is still immature so we don't yet understand its characteristics fully. But an interesting topic to investigate that might have nice properties.

Wolfgang Pempe, DFN: agree with Rhys

The aggregated metadata of eduGAIN is under constant change as entities get added, removed, or changed. While daily backups are made, there is no event-based changelog and no trace of which change was made when. When an entry of interest is examined, the search for the exact event timestamps of changes pertaining to that entry are tedious by searching old copies of the entity database manually.

The proposed system stores any change to the metadata aggregate one-by-one in a ledger as soon as it happens. That way, even intra-day changes (between daily database backups) can be observed and a "rewind" of the entity list to specific point in time becomes simple.

For improved traceability of any changes, the ledger can be made distributed and authenticated in the way that both the publishing eduGAIN participant (sending side) and the eduGAIN OT (receiving side) both sign the change in a distributed ledger.

The ledger would be distributed so that each eduGAIN federation maintains a copy. With that, changes made automatically synchronise between federations and a manual polling of per-participant feeds (by eduGAIN OT) as well as a periodic download of the aggregate (by eduGAIN participants) becomes superfluous.

eduGAIN OT still maintains its role as metadata policy verifier by signing only such changes in metadata which result in eduGAIN policy conformant metadata. As a positive side-effect, this changes the granularity of metadata rejection from a per-participant (country-wide) effect to a per-entity effect, reducing outages due to metadata of entire participant federations vanishing.

The solution developed here is not limited to eduGAIN exclusively; it can also be used inside a federation to collect and sign individual pieces of metadata, thereby assembling its own metadata set in the same way.

Where IdPs or SP choose to maintain a copy of the ledger, they can immediately and in real-time see any changes and implement them in their entity; resulting in an experience similar to the MDX proposal above. They can choose to incorporate only entries signed by their own federation, or a superset to their liking.

This proposal is to experiment with distributed ledger technology as a pilot aimed for production to provide a live and auditable record of who has claimed what about any entity and in turn, leverage these entity claims to augment existing metadata as well as other future protocols in a variety of ways. 

Metadata decoration, regardless of protocol(SAML,OIDC,ABFAB,etc) is challenging to do at scale and equally challenging to do in a trustworthy way economically. By using the features of a distributed permissioned ledger there is an opportunity to leverage our rich set of entities in our respective trust fabrics.  Each entity already has cryptographic keys  to ‘go on record’ and assert things about other peer entities. These assertions in the distributed ledger would be signed using the existing keypair that each entity controls to indicate the authenticity of the claim. These claims can be verified leveraging the existing key distribution in our metadata. The distribution of said claim is handled by the decentralized ledger and thus reduces overhead in overall operations and has resiliency aspects over a centralized service.

These claims could indicate almost anything. Some interesting ones may be:

• A SIRTFI service entity could sign its claim that a given entityId is SIRTFI compliant
• An entity could claim a given entityid possesses an entity category tag of any label
• A federation operator could sign a claim that a given entityId belongs to its federation
• An entity could claim a given entityid has a certain SSLLabs score as of a given date
• A service provider could sign a claim that a given entity is permitted in its discovery service
• An entity could sign a claim about an entity in its community of interest
• An entity could sign a claim about where geographically an entity resides

Anyone publishing or handling metadata can then choose to merge (metamerge?) their choice of any or all of the above into their metadata and sign it. Similarly, use cases exist for those already receiving our metadata to ‘listen’/read’ certain things from the distributed ledger to augment the metadata for their own purposes: e.g. render enhanced discovery for service only showing SIRTFI compliant entities or showing entities that are in my community of interest, etc  This is especially interesting as our federations move toward MDQ as a way to achieve more near real time delivery of elements about entities.

Decision of what to merge and consider ‘appropriate decoration’ is always in the hands of the person/process merging the data be them federation, identity provider, or service provider operator. This is done by determining which keys sign which claims and which keys will be considered anchors for the claim.   If another entity attempted to sign a same claim, the validation would fail because it would not be signed by the right anchor or authority.

Other interesting features of this approach is that it is a distributed ledger system and thus decentralized and lends itself well to our geographically diverse community. Another benefit is the ledger technique is agnostic to underlying trust-fabric technology. Usage examples: Populate only SIRTFI OIDC Ops for discovery. Show only members of a community of interest in a given user interface in moonshot, indicate which IdPs are in govroam and/or eduroam etc.

A group of interested participants to assist with initial structure and would contribute a portion of time to the activity 3 – 18 months depending on how robust one would want things and who participates. I can better elaborate if there are more +1's here

Niels: This might be build on top of existing work in GEANT project from Linus (certificate transparency)

The most interesting session that I had at TechEx 2017 ACAMP was asking "How do students federate an application?" with Fed-Lab.org and TestShib.org existing - but not solving all of the edge cases for new applications and especially new developers.

A student can pick a framework off the self - run through tutorials and then connect their application to a host of services (Github, Twitter, Facebook) but SAML often isn't an option - and even if it is - there is a lack of enviornments that a student/new developer can jump into to make their tool work. This needs to be solved to support new developers, create a sandbox for development and expose SAML integration for various frameworks.

Include OIDC

Wolfgang Pempe (DFN): the current approach (at least in our federation) is to perform periodical attribute queries with SAML2 Persistent NameID, which leads to quite some problems.

SURFnet: +1

Stefan Winter

Nick Roy, InCommon

Niels van Dijk, GEANT 4-2 Project; This should be carried out in close collaboration with the pyid.org community

During REFEDs at TechEx2017,and later-on during TechEx2017 itself, a interesting discussions developed over the future of federation, the role of users and the use/rise of proxy technology.

This activity investigates and showcases privacy enhancing technologies including, but not limited to, PEP (Polymorphic Encryption Pseudonyms) (1) and IRMA (I reveal my attributes) (2) and tests and validates applicability and usecases of these in the context of R&E federations and eduGAIN.

SURFnet has build some experience with these technologies on a national level, and has for example implemented PEP into commonly used software products like ADFS, Shibboleth and SimpleSAMLphp. In regard to IRMA, it has now been enable in pilot for both SURFconext federation as well as the IDIN Bank ID federation. We feel these technologies have significant promise, but would like to validate this in international context. We would also like to learn about other alternative strategies and solutions that may help us to shape the future of our identity federations.

• Other technologies to showcase other then PEP and IRMA
• Participants for pilots
• People with good ideas

(1) https://blog.surf.nl/en/privacy-surfconext-using-polymorphic-pseudonyms/

(2) https://privacybydesign.foundation/irma-en/

The SAML Tracer (https://addons.mozilla.org/nl/firefox/addon/saml-tracer/) is a highly rated firefox plugin which was developed in our community (UNINETT, with contributions from others). As the browser is the central entity in any SAML transaction, it is extremely convenient tool for testing en debugging SAML transactions. There are not many alternatives to this tool

Unfortunately, Firefox has changed its plugin framework, rendering the existig plugin useless and a major rework is needed.

Money, a (junior) developer

Stefan Winter

Scott Koranda, LIGO

Nick Roy, InCommon

Thomas Lenggenhager, SWITCH:Feasibility to provide also a version for Safari compatible version? Thanks José Manuel, I now found the SAML Chrome Panel!

Pieter van der Meulen (SURFnet)

Michael Domingues (University of Iowa)

José Manuel, RedIRIS/SIR. Regarding Thomas question, there's a SAML Chome Panel extension for Chrome

Wolfgang Pempe, DFN

MIchael Brogan (University of Washington)

Nate Klingenstein (The California State University)

Marcus Mizushima (The California State University)

Andrew Morgan (Oregon State University)

David Bantz (U Alaska)

Brent Putman (Georgetown University, Shibboleth Developer Team)

Liam Hoekenga (University of Michigan)

Terry Smith (AAF)

Dalia Abraham (AAF)

Daniel Lutz (SWITCH)

Etienne Dysli Metref (SWITCH)

Martin Haase (DAASI)

Rod Widdowson (Steading System Software, Shibboleth Developer Team)

Allan West (University of Florida)

Dominique Petitpierre (University of Geneva)

Cédric BRINER (University of Geneva)

Eric Yurick (Gettysburg College)

Vlad Mencl (Tuakiri/REANNZ)

I would like to have a placeholder to include work that my be triggered by the revisited list of FIM4R requirements, as well as by AARC.  Furthermore, I'd also like to include in this box liaisons with EOSC hub concerning their T&I architecture developments and adoption/support of FIM technologies. This item cannot and should not be more specific than this at this point in time.

• Drive two factor towards ubiquity with low cost - create an eduToken (for the users that do not have a phone; critical mass can bring down the price even more. It can be implemented as a kickstarter campaign).

• Challenges in deploying multi-factor in EU, partially due to the costs and partially due to the cost involved. A cost-effective approach would help.
  

• An edu-token  as  a separate ‘token’ may reintroduce token management aspects (losing the token etc)

• management is (will be even more) a non issue as the majority of people will use phones. We should strike for that.

• Technically this problem can be solved, taking the above considerations into account.
  The real problem is how to scale the token vetting over EU. This is especially challenging for research collaborations.
  

isn't this the work being done in IoLR +REFEDS?

Some of it is - implementation in service contexts is not. It is expected any work in GEANT would do this, leaning on results from the above

With eduroam Managed IdP, there is a service which takes all RADIUS hassle off of Identity Providers. There is no equivalent for eduroam SPs. I.e. a future eduroam SP either needs to set up a local RADIUS server and connect it to the NRO, or (if the NRO supports it) connect the Wireless Controller directly to an NRO server - losing all advanced features such as VLAN assignment. For small hotspots, there is a possible additional complication if the hotspot has a dynamic IP address, which makes the interconnection via RADIUS' shared secrets infeasible. Right now, such potential hotspots are not serviceable by eduroam infrastructure.

The goal of this activity is to create a self-service web portal where any prospect SP can register his hotspot (requiring sign-off by the NRO; comparable to eduroam Managed IdP) - regardless whether he has a static IP address, a dynamic one, or doesn't even know what an IP address is in the first place. The new hotspot's RADIUS connectivity is tested in real-time (e.g. using a credential from eduroam Managed IdP, a good complement to this service) and the new SP is instantly connected to the eduroam infrastructure. Where the NRO admin confirms that a particular hotspot maps to a specific realm or Managed IdP instance, the SP can even get VLAN ID assignments for his own users (that part of the use case is possibly a bit weak as an SP who does not know about setting up a RADIUS server likely also doesn't know about VLANs to begin with).

For the technicalities of the uplink itself, there should be support for multiple attachment anchors (=RADIUS servers behind the web interface) because geographical proximity to the hotspot is important for performance reasons.

The remaining complexity for the SP which this service will not take away is: phyiscal installation of APs, controllers, and the configuration of those so that they are providing proper local eduroam.

To ensure service quality on such "no clue" SPs, it could be made mandatory to install a probe at the site so eduroam Operations can monitor the hotspot quality.

VM for web interface, VMs for RADIUS attachment anchors, a clever idea how to handle registering hotspots with dynamic or unknown IPs

There were a multitude of reasons why the GÉANT community couldn't run the infrastructure for WIFI4EU.

Sufficient issues were exposed by managing this as a single centrailsed infrastructure (partially addressed by "get eduroam", "eduroam DEEP Learning", "eduroam SP-as-a-Service"). By identifying all the scaling blocks to existing eduroam services we'd be able to offer advice, guidance and technology push into govroam, WIFI4EU and eduroam services to support the existing infrastructure and development in new territories.

Georgi Tsochev, BREN

Reimer Karlsen-Masur, DFN-PKI

Great chance to accelerate the deployment of secure public Wi-Fi systems in the world and to inter-connect them. Related to my proposal of inter-roaming, but a separate work item dedicated to WiFi4EU is still preferred. (Hideaki Goto, NII)

Develop an inter-roaming architecture that connects various Roaming Consortia (RC) including eduroam, govroam, City Wi-Fi (secured), WiFi4EU, etc. to enable roaming, with or without Passpoint.

Make the deployment of off-campus eduroam/govroam services much easier. For example, eduroam accounts can be enabled on City Wi-Fi world-wide.

Contribute to the improvement of Hotspot 2.0 to make "eduroam on NGH" possible. (The current HS2.0 specifications and some implementations are known to have some issues hampering large RC creation.)

Contribute to the revisions of the WRIX specifications to make them as much compatible as possible with eduroam's. WRIX-i (interconnect) and WRIX-L (location) are the targets.

Let's Encrypt and the certbot have made certificate management for 1 particular CA very easy and effective. With the addition of ACME v2 this will allow additional CAs to participate and allow the dev/test/production environments to automatically deal with certificates.

Work should also investigate eduPKI and Let'sRADSEC use of this mechanism for certificate maintenance.

TechEx 2016 ACAMP notes: https://docs.google.com/document/d/1o20NmuLjmNySp10QqfueO3of6jmoeTRfmgG4e_olZ_s/edit

Georgi Tsochev, BREN

Rhys Smith, UKf: Certbot is going to take over the world, so we should start doing stuff with it.

Reimer Karlsen-Masur, DFN-PKI

• Standardization
• SAML stack development

While for IdPs and SPs eduGAIN metadata requirements are well described, no such requirements exist for AAs. We have however already 5 of these entities in eduGAIN.

It would also be a good idea to consider/define what it would mean for an AA to claim CoCo, R&S and Sirtifi support

• Standardization
• Probably a no-brainer as much can likely be derived from IdP requirements (?)

Constantin Sclifos, RENAM

Nick Roy, InCommon

SURFnet

Rhys Smith, UKf: I think AAs will become more important as we move forward, and there is a gap here in policy that needs thinking about.

Wolfgang Pempe, DFN