|Room Green/Grüner||Room Yellow/Gelber|
|Agenda setting: 9:30 - 10:30|
|Session 1: 11:00 - 11:45||Structured Attributes / attribute aggregation|
|Session 2: 11:45 - 12:30||AAI for services: how can we make their life easier?||Authentication Context vs LoA|
|LUNCH: 12:30 - 13:30|
|Session 3: 13:30 - 14:15||EAP Configuration on devices||Interfederation|
|Session 4: 14:15 - 15:00||Moonshot / non-web SSO||Test IdPs|
|COFFEE: 15:00 - 15:30|
|Session 5: 15:30 - 16:15||OpenID Connect for Higher-Ed|
|Wrap-up: 16:15 - 17:00|
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:
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:
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