Zurich Open Space - 12 February 2014

Raised Topics:

1. How to make OpenID Connect work for Higher Education (Roland H)
2. Provide temporary eduroam to Guests (Paul D)
3. Token Translation as a Service (Licia)
4. uApprove Next Generation - Detached from Shibboleth for OAuth, UMA & OpenID Connect (Ken)
5. Scalable Solution to SAML Attribute Release - Entity Categories, CoC and more... (Olivier)
6. Structured Attributes
   
   1. Attribute Aggregation -> Structured (Maarten)
      
   2. Structured Attributes - More Just Strings (Thomas L)

NOTES

The scope of the discussion is about SAML attributes and how to transfer more complex attributes. Whether the attributes are transferred from the IdP to the SP or from an AP to an SP is not very relevant.

Several aspects were considered:

•  the value attached to the attributes a possible architecture to aggregate attributes from different sources
• a possible architecture to aggregat attributes from different sources

Clearly if attributes become more complex, applications would need to adapt their APIs to process them. Do we have use-cases for more structured attributes? Do SPs need structured attributes?

Olivier mentioned that some use-cases for more structure attributes appeared in the e-Learning sector.

One way would be to provide both the simple value as well as the structured value. Those applications that cannot process the structured value would just ignore it.

We should be careful not to ship too much information for each authN. Maybe AP should be shipping the structured attributes.

It was agreed to decouple the problem in:

1. Define the structured attribute

2. Define who wants structured attributes and how to make them consumable for SPs. A couple of use-cases were presented (Roland, Clarin, Olivier).

3. How do you present the aggregate attributes from different source?

Action: for those attending this section, to provide use-cases that would benefit from structured attributes. Ideally the use-case should be presented with:

 - describe the authorisation decision in words

 - list potential attributes to support this

 - identify the sources of these attributes

1. Test IdPs for eduGAIN (Lukas)
2. Getting EAP Config on to a device in an optimal way (Tomasz)
3. Non-Web SSO
   
   1. The real Truth about Moonshot (Rhys)
   2. Single AAI for Web and non-Web Apps (Rok)
   3. Can we compile "best practice" for non-Web SSO? (Joost)
4. AAI for Services: Can we make it easier (Licia + Ann)
5. Authentication Context and LoA
   
   1. Solving the easy part of LoA: AuthnContext (Brook)
   2. LoA on Attributes (Ken)
      
   3. What (king of) Attributes should a VO release (Kristof)
6. eduGAIN
   
   1. Convince CLARIN to go eduGAIN rather than SPF (Kristof)
      
   2. WTF is eduGAIN? Is it a service, project, broker, funding source, unicorn wrangler or something else (Nicole)
   3. Pragmatic Interfederation (Dieter)
7. EMC2 needs a ToR: Help me write it! (Brook)
8. OCSP is dead. Long live... (Brook + Joost)
   
   1. Certificate Transparency (Brook)
   2. What to do with DANE/Certificate Transparency/Pinning (Joost)
    

Rejected Topics:

• EMC2 needs a ToR: Help me write it! (Brook)
• Periodic Table of Trust Elements (Ken)
• IdP Deployment (Anders)
• Why multi-factor authentication is NOT a good idea (Jean-Francois)