Page Comparison

...

• Fulup Ar Foll (Oracle)
• Jonas HHögberg (Ericsson)
• Gaël Gourmelan (Orange)

Apologies

• Ingo Friese (DT)
• Shin Adaci (NTT)
• Sebastian Lampe (Fraunhofer Fokus)

Agenda

1. Cook Book for  massively scalable telco IdM systems
2. Next steps
3. AOB

Minutes

The objective of the meeting was to come up with an idea for the scope of the study so that a preliminary ToC could be produced

1. Cook Book for  Massively Scalable Telco IdM Systems

The work philosophy is to see what the functional requirements are for such massively scalable IdM implementation. This will lead to constraints and a possible technical solutions to address those constrains. Final document should be  detailed and illustrated in a way that someone should be able to implement it as a 'Reference Architecture'. Potential target candidate for implementation could come from industry [eg: ForgeRock, Lasso, Ericsson, ...] or University/ Research [eg: Fraunhofer, ...].

The working assumption for requirements/implementation time frame is ~36 months. Architecture will be declined in three classes going from large to extra/extra-large.

5 areas were identified, namely: Authentication, Attribute sharing, network, scaling and O&M. These areas came out from discussions on what functionality our system should have:

• Authentication, Multi-level authentication (weak -> strong)
• profiling information
• session management
• Multi-pass access (SSO, mail, MSISDN , chat (?))
• Attribute sharing
• Network
• Scaling
• 3rd party

These items were later group to the 5 mentioned beforehand:

• Authentication:
  •  Assurance FW (Basic to Strong)
  • House-hold network authentication
  • MSISDN (2G/3G network authentication)
  • One-time token by SMS
  • Strong authentication  leveraging SIM toolkit
  • GAA/GBA (proper GAA authentication)
  • user/passwd
  • 3rd party authentication: SAML, OpenID, InfoCard.
    
• Attribute sharing
  • Authorisation:
    • OAuth: -- or ++ 'versions'
    • SAML AX ? (in scope?)
    • OpenID AX ? (in scope?)
    • horizon 36 months -> no proprietary protocols/APIs, like today
    • Which attributes do you really need and where are they stored? Service Profile, Personal Profile, Billing (on-bill, off-bill (credit card)), Social Network (APIs)
      • Today, the model is to have a local copy of the data. This is difficult to sustain for the future. Today, discovery is not needed as a local copy is stored.
    • What is our vision on how AS will be done in the future?
    • DST (XPATH (SQL-like way to query attributes stored as XML) is not the value in ID-WSF.
    • ID-WSF -> ITU-T, SOAP-binding, discovery, Sech. Mech.) Use this in our Cook Book?!
    • Privacy, minimal disclosure, right to forget.
    • Assurance FW (for attributes, e.g., postal address, nationality)
    • Leverage Geolocation, presence (delivery -> agree (SMS if not)), messaging (call-back).
    • IPTV:
      • who is watching?
      • multi-device SSO
      • old people (if not watch TV every day or during certain hours -> alert relative
      • children (advertise Mickey Mouse, etc.)
        
• Network
  • Multiple IdP implementation
  • Global DNS distribution
  • Break SSL at Fire Wall => use HW accelerator -> security mechanisms implementation
  • Load balancing
  • Fail-over in network
    
• Scaling
  • Model
  • Distribution of users depending on:
    • subscription (gold, heavy user, etc.)
    • new DB or removal of DB in system
    • multi-country, consolidation might not be possible
      • problems (legal, performance, fail-over) => broker (or proxy), attached to the IdP?
  • Load model
  • Numbers:
    • #sessions
    • how to store sessions
    • #auth/s
    • #acticveSessions
    • life cycle of sessions in general
    • back-end repository
      • read-write/s, provisioning
      • which information shall be stored in the IdP repository vs. attribute sharing
      • make back-end repository as small as possible, 'as small as possible' needs to be defined
      • define relation between IdP repository and attribute (PP, EP, Geolocation, Presence, etc.) repository
        
• O&M
  • User Management, provisioning
  • User migration
  • Adding a new service, adding a new authentication method, adding a 3rd party for something.

2. Next Steps

It was decided that Fulup [Oracle] will start leading the work. The ideas will be presented to the KI TI WG for comments. Later on, the work will be presented to other key people in KI and to the KI e-gov WG, probably during the next KI conference in Paris in October  [Orange Labs]

3. AOB

 None.

Next Meeting

Not know as of now.

• Date: Day, Month Day#, Year#
• Time: X PDT | X EDT | X UTC (Time Chart)
• Dial-In: +1-218-862-7200
• Conference room: 4630912

NOTE: Do not follow the code with a "#" symbol as it may cause the code not to be recognized.