eBackground & Basics
This is a staging area for material for which JRA3 is fully or partially responsible in the GN4-2 PLM Processes.
Any operational material is available at SA2.
The matrix of responsibilities for transition to production is also at SA2
Process
Processes are documented ad interim on Sharepoint pending update of the PLM site.
Useful Templates/Resources
- CBA Word document, customised for JRA3
- CBA Payback schedule excel, customised for JRA3
- Roadmap template
- PID Template - general
- Production Transition Templates for Service Definition, Policy and Branding and Operational docs- use as early as is sensible, not just in transition.
- GÉANT SD Response SLAs - for inspiration
Subtask to Product Mapping
eduGAIN
Target Gate: None. In production.
Main service Documents
NIF:
CBA:
- v2 Text and Excel. Document was not formally evaluated by management.
- v1 Text. Document is over 4 years old.
PID:
Roadmap: Proposal for eduGAIN versioning
Service Description: GN3plus PLM Version; GN4-2 SA2 Operations Version.
Service Policy: https://technical.edugain.org/documents - Declaration v2, Consitution v2, other supplemental policies inc. CoCo v1.
Service Design Documents:
Branding: Materials
e-Science/enhanced eduGAIN support
Target gate: Production
Target review date: Sept/Oct
Task: 2.
Documents
PID: Draft
Roadmap: Feature in main eduGAIN roadmap.
Service Description: Draft
Service Policy:
Service Design doc: Draft in progress
Pilot plan:
- High level outline as presented REFEDS Nov 2016
- KPIS: Section 2.1.4 of CBA
Branding/visibility:
- Branding simply as eduGAIN support.
- No special web presence on innovation required - bundle with overall eduGAIN innovation section.
- Visibility - outreach at AARC, FIM4R, REFEDS meetings throughout the pilot period.
- Already presented at REFEDS/AARC November/December 2016
SIRTFI
Target gate: Design (Central infra) Pilot (BCP and support)
Target gate review date:
General pilot - M12 for BCP and support
Central design: M15 (provisional)
Central pilot M21 (provisional)
Task 1.
Documents
CBA:
Roadmap: Feature in main eduGAIN roadmap.
Service Description:
Service Policy:
Service Design doc:
Pilot plan:
- KPIS:
Branding/visibility:
- Branding simply as eduGAIN supports SIRTFI as BCP.
- No special web presence on innovation required - bundle with overall eduGAIN innovation section.
- Visibility - outreach at AARC, FIM4R, REFEDS meetings throughout the pilot period.
- Plans Already presented at REFEDS/AARC November/December 2016
Cross-sector Interoperability
Target gate: Pilot
Task 3
Documents
CBA:
Roadmap: Feature in main eduGAIN roadmap?
Service Description:
Service Policy:
Service Design doc:
Pilot plan:
- KPIS:
Branding/visibility:
- Branding simply as eduGAIN Cross-Sector/eIDAS interoperability within eduGAIN.
- No special web presence on innovation required - bundle with overall eduGAIN innovation section.
- Visibility - outreach at AARC, FIM4R, REFEDS meetings throughout the pilot period.
eduGAIN f-ticks Monitoring
Target gate: Pilot
Task 1
Documents
CBA:
Roadmap: Feature in main eduGAIN roadmap?
Service Description:
Service Policy:
Service Design doc:
Pilot plan:
- KPIS:
Branding/visibility: N/a, a regular eduGAIN feature.
Simple Service Provider Registration
Target gate: Production
Task 2
Target gate date: Combine with e-Sci support target transition date Sept 2017
Documents
CBA:
Roadmap: Feature in main eduGAIN roadmap
Service Description:
Service Policy:
Service Design doc:
Operational Requirements:
Operational Docs:
OLA:
Operational Processes:
User Support:
Branding/visibility:
- Branding simply as eduGAIN support.
- Marketed only via User Liaison and other GÉANT services to particular groups of inter federation-only scope e.g. SA4 cloud.
- Engagement with federations via eduGAIN SG
- Priority given to classic federation model, this is a process of last resort.
OIDC eduGAIN Profile
Target gate: Design
Task 3 + task 1
Documents
CBA:
PID:
Roadmap: Feature in main eduGAIN roadmap, TBD on representing individual roadmap
High level baseline Service Description:
Service Policy:
Service Design doc:
Branding/visibility: OIDC Profile of eduGAIN
MFA profile:
Target gate: Design
Target date: M18
Task 3
Documents
CBA:
PID:
Service Description: BCP for use of MFA in eduGAIN
Service Policy:
Service Design doc:
Roadmap: Product Output is BCP documents. How to represent?
Branding/visibility:
InAcademia
Target gate: Pilot
Target date: Material ready jan 23.
Task 2
Documents
CBA: (GN4-1 format) - rebaseline to payback schedule during pilot
Roadmap:
Service Description: Section 11 of CBA
Service Policy:
Service Design Documents:
Pilot Plan: Draft
KPIS: Section 5 of CBA
Branding:
eduTEAMS Basic
Target gate: Pilot
Target date end April
Task 2
Documents
CBA: In Progress,
PID: How does this relate to the GN4-2 workplan?
Roadmap:
Service Description: COPaaS.pptx (Needs updating/customising)
Service Policy: Source material, needs writing
Service Design Documents: Market Analysis GN4-1, Functional Architecture ; Technical Architecture ; VM Platform
Pilot Plan: TBC - Umbrella in Q1 2017...what else?
Branding: In progress
Baselined Operational Reqs: In prgress
eduTEAMS Advanced
Target gate: Design
Task 2
Documents
CBA: , Market Analysis GN4-1
PID:
Roadmap:
Service Description:
Service Policy:
Service Design Documents:
Branding: In progress
IdP as a Service
Target gate: Design
Task 1
Documents
CBA: Draft in progress
Baselined PID:
Baselined Roadmap:
Baselined Service Description:
Baselined Service Policy:
Service Design Documents:
Assurance
Target gate: Design
Task 2
Documents
CBA:
PID:
Service Description:
Service Policy:
Service Design doc:
Roadmap:
Branding/visibility:
eduKEEP
Target gate: Design
Task 3
Documents
CBA:
PID:
Service Description: Product Output is BCP documents. How to represent?
Service Policy: Product Output is BCP documents. Policy BCP can be developed, is this what is wanted?
Service Design doc:
Roadmap: Product Output is BCP documents.
Branding/visibility: GÉANT/EC to be acknowledged as sponsor of work. Material to be available on GÉANT website as White Papers/BCP documents.
OIDC Standardisation
Target gate: Design? Pilot?
Task 3
Documents
CBA:
PID:
Service Description: Product Output is standards, not a service. How to represent?
Roadmap: Product Output is standards, not a service. How to represent?
Service Policy: Product Output is standards, not a service. How to represent?
Service Design doc:
Branding/visibility: GÉANT/EC to be acknowledged as sponsor of work.
eduroam
Target gate: None, in production.
Task 4
Main Service Documents:
NIF:
CBA:
PID:
Roadmap:
Service Description:
Service Policy:
Service Design Documents:
eduroam Managed IdP
Target gate: Pilot
Target date: Q2 2017
Task 4
Documents:
PID: Draft pending CBA and pilot plan update
CBA: CBA-eduroamManagedIdP-SW-JH-draft20170316.docx
Roadmap: roadmap-eaas.pdf,
Service Description: eduroam Managed IdP (external testing)
Service Policy: idem, chapter 2 - update with additional eligibility to use as discussed 16/2
Service Design Documents:
- Original GN4-1 deliverable 9.3
- Client CA - architecture
- Server CA - architecture
- Components and Workflow
Pilot Plan:
- basic UAT: validate all steps of workflow
initial signup
manual one user creation
CSV user creation
invitation issuance
installer pickup
eduroam usage
credential expiry /revocation - input regarding various design choices
tracing: how important is it group users across credentials with Chargeable-User-Identity?
product exclusivity: Managed IdP XOR normal RADIUS profiles
import: is the choice "manual" and "import by CSV" sufficient? Which other user upload method would people like?
credential communication: is it okay to leave means of sending invitation token to admin? Shall we implement a "Send by email/Skype/Facebook"?
deadman switch: is this appreciated/its necessity understood? What would be a comfortable interval for participants?
end-user import: is the "one time import password" mechanism understood? If any, what are its UX problems?
OS autodetection: does this work well enough - and do end users "get it" that they should visit the download page with the exact device they want to configure?
re-use of invitations: one invitation, one credential, one device? Or should invitation allow multiple devices, or be good for a certain amount of time for an arbitrary number of devices?
Add Pilot plan text for piloting business model.
KPIS (adapted from GN4-1 D9.3):
- NRO Acceptance: within the pilot duration, at least three eduroam NROs promote eduroam Managed IdP to their constituency
- Campus Uptake: within the pilot duration, at least five Identity Providers enable eduroam Managed IdP and provision at least one user account with it
- Positive evaluation by pilot participants: qualitative evaluations in survey show overall positive mood
- Service value proposition: participating IdPs judge whether results and workload induced by using the system is a good trade-off versus other solutions that deliver similar goals (own IdP setup, licensing commercial tools, ...)
Branding: eduroam Managed IdP - agreed with KM. Visible only on parts of user interface. (name-brainstorming)