...
| Title | Storing History and Evolution of Metadata in a Distributed Ledger |
|---|---|
| Description | 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. |
| Proposer | Stefan Winter (RESTENA) |
| Resource Requirements | VMs, storage for the ledger, a blockchain implementation, someone to work on that so it fits our needs |
| +1's |
| Title | Metadata Entity Decoration Distributed Ledger |
|---|---|
| Description | 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:
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. |
| Proposer | Chris Phillips |
| Resource requirements | 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) |
| +1's |
| Title | Reference implementation of an IdP and OP in Python |
|---|---|
| Description | The current GN4-2 projet has invested heavly into the Python stack for OpenID Connect (federation) and it should be good to put together a full blown home organisation IdP/OP based on this work and earlier work with the SAML stack. This imlementation should support all current best practices in eduGAIN and retrie attributes from different sources. |
| Proposer | Pål Axelsson on behalf of Sunet |
| Resource requirements | money, software dev |
| +1's | 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 |
...