FAST FED Part II

Fast Fed Part 2

Wednesday 4A

Convener: Dick Hardt

Notes-taker(s): Sing Yoong Khew

Tags for the session - technology discussed/ideas considered

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

During the session, Pam presented a list of attributes that may need to be part of the FastFed metadata document and we discussed whether or not it needed to be included.

Consensus was easily reached for most of the attributes. Below are some that were discussed further:

-Login URL: in a double federated scenario, may need to know where to send the user to after successful authentication. Pam has action item to provide a concrete example. Tentatively, this field is not required.

-JIT provisioning/attributes dictating logic: spent a lot of time discussing this but did not reach consensus. Some thought that it should be part of the metadata so the IdP can implement specific logic to handle specific application tenants. Others insist on a simpler IdP setup and keeping FastFed more prescriptive, each application can interpret the standard user schema the way they need to.

-Provisioning/behavior on delete: did not reach consensus. Some applications suspend the user to keep historical context, while others can delete. Issues may arise when the same identifier gets resurrected.

-Provisioning/set password supported: some RP only wants provisioning and not federation. Is this a good idea?

Other interesting notes:

-Fields that doesn’t affect the functionality of federation should not be included.

-Standard user schema will be part of the FastFed spec, explicitly mapping attributes in FastFed metadata document not required.

-In the lifecycle of a (SaaS) app, the FastFed spec should provide best practice for RP in migration from a system that does not support federation to a system that supports federation

-Spec should provide recommendation how RP should handle usernames, especially in a multi tenant service (e.g. Salesforce) where the same email cannot be reused in a different tenant.

Note: Pam Dingle will provide the spreadsheet that was presented.