Please use this page to record ideas that you would like to include in the 2020 REFEDS workplan. Copy and paste the table below. Ideas don't need to be fully formed but the more scope we can get the easier it will be to assess whether idea should be taken forward. We look forward to all your ideas!
Want to know what was proposed in 2019? Have a look here.
Template
| Title | <title of your proposal here> |
|---|---|
| Description | <description text here> |
| Proposer | <your name here> |
| Resource requirements | <money? effort? coordination? unicorns?> |
| +1's | <for others to voice their support - add your name here> |
Ideas
| Title | |
|---|---|
| Description | Input into a baseline expectations for eduGAIN |
| Proposer | REFEDS SC |
| Resource requirements | |
| +1's | Scott Koranda |
| Title | Revise Cloud Services Cookbook |
|---|---|
| Description | The Cloud Services Cookbook, https://wiki.refeds.org/x/PoDR, was posted to the Refeds wiki with a few updates made from it's original version created by the Big Ten Academic Alliance. It hasn't been updated since 2016, however. It would be very useful to devote some resources to updating SAML-specific recipes as well as add OIDC and protocol-agnostic recipes. |
| Proposer | Keith Wessel |
| Resource requirements | People resources, brain power, and possibly a Festivus miracle |
| +1's |
| Title | Extensions to MDQ |
|---|---|
| Description | The RA21 and SeamlessAccess projects have defined two extensions to the MDQ protocol, one to enable a search capability and one to enable a "webfinger" query to determine "what the server knows". Leif Johansson has provided an example implementation with pyFF. This proposal is to have REFEDs help formalize these extensions, perhaps by working with Ian Young to evolve the MDQ specification. |
| Proposer | Scott Koranda and Leif Johansson |
| Resource requirements | People resources for help with planning and organization and to help shepherd the update. |
| +1's |
| Title | Dynamic errorURL |
|---|---|
| Description | After login at a service the service (SP) may be missing some information or requirements of the login, for example
There currently is no best-practice for how a service should inform users of non-technical shortcomings of logins. It would be convinient if IdP:s could supply url:s to different support pages that services could referer to depending on pre-defined problems with logins. Many login problems are not detected until after login. |
| Proposer | Pål Axelsson |
| Resource requirements | A short term workinggroup to write up recomendations and profile |
| +1's |