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/

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

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)