[Openid-specs-fastfed] Meeting Notes from December 12, 2019
McAdams, Darin
darinm at amazon.com
Sat Dec 14 00:21:56 UTC 2019
Attendees:
* Dick Hardt, SignIn.org
* Erik Gustavson, Google
* Brian Rose, Sailpoint
* Matt Domsch, Sailpoint
* Wesley Dunnington, Ping Identity
* Pam Dingle, Microsoft
* Zhen Chien Chia, Microsoft
* Darin McAdams, Amazon
* Sing-Yoong Khew, Amazon
Notes:
This was a 7 hour in-person meeting in Seattle. The main thrust was to test the spec against a wide range of edge cases, such as retries and updates, that hadn’t previously been examined together. There was a great deal of whiteboarding and deliberation.
By-and-large, it held up. We did accumulate the following list of suggested updates:
* 7.2.2.2 – Clarify that last paragraph is non-normative best practice guidance.
* 7.2.2.3 – Clarify that the 3rd paragraph is normative. IdP WILL make a choice of the preferences.
* Double-check if any UX guidance in the normative spec should be moved into a best practices doc.
* Clarify that the list of Capabilities in the App Metadata are specific to the FastFed relationship. (App could return different capabilities to different audiences.)
* Today, “Provider” and “Tenant ID” are two separate fields. Implementors must combine them to form a unique string for a given Provider+Tenant. It can be a non-trivial task to concatenate safely (“what’s the right delimiter?”) with security implications if done naively. To remove this risk and be consistent (and less confusing) compared to other standards, require a unique ID in the metadata. Similar to SAML EntityID. Can still include the separate fields in metadata, as they serve other purposes.
* Update the JWTs used by FastFed to use the unique ID (prior bullet) in the “iss”. Remove “sub”.
* Clarify Section 7.2.4 Handshake Finalization to emphasize that all pipes must be connected and ready when this step is done.
* Be more prescriptive on how to handle changes in the underlying SAML/SCIM/OIDC metadata. For example, the SAML Profile is currently prescriptive about certificate rotation, but is silent regarding how to behave if other attributes in the SAML Metadata are mutated.
* Clarify that the FastFed Handshake is applicable to both the initial creation + update scenarios. Clarify how to handle updates, either in the spec or best practices.
* If the federation data is accidentally wiped by one Provider, verify that FastFed can be used to re-establish the relationship. Specifically, it shouldn’t choke because one party still holds the configuration. (We think this is true, should test during implementation.)
* Add an example showing the use of SCIM schema extensions in the list of required attributes.
* Provider Contact Information is accidentally missing in the App Metadata
* Terminology discussion:
* Consider using “IdP Discovery” instead of just “Discovery”
* Consider using “Desires” (or similar) when describing the capabilities the App is sharing with the IdP.
* Consider using “Contract” (or similar) when describing the contents of the registration flow, to distinguish from the other metadata.
The following were discussed, but not resolved:
* Should we be able to mimic an IdP-initiated FastFed flow that simply redirects to the right page in the App? This allows IdPs to provide a catalog of apps with SSO setup instructions. The challenge is that each customer within an application may have different, tenant-specific, URLs for setting up SSO with FastFed. Can’t just put 1 URL into an IdP catalog. Also, not clear how the IdP administrator would hand-over the flow to the App administrator when they are different people. IdP owners to ponder the desired experience in more depth.
* Should it be possible to setup multiple authentication protocols in parallel? E.g. both SAML and OIDC. This is possible in migration scenarios, especially as people shift from SAML->OIDC. While FastFed supports this, the majority of the attendees are currently unable to persist multiple authn protocols for a single app. Should the spec allow providers to signal if they support multiple protocols? Requires more thought. Darin to include a strawman approach in next spec revision.
Next Deadlines for the WG:
* Jan 17: Darin finishes incorporating existing feedback into the spec. Update the revision to ‘02’.
* Jan 20 – March 1: WG applies final polish to the spec.
* March 1: Working Group submits the spec to OpenID Foundation members as proposed implementation draft. (Mandatory 45-day wait period before vote.)
* April 27: OpenID Foundation Meeting. Vote on Implementors Draft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191214/11637e85/attachment-0001.html>
More information about the Openid-specs-fastfed
mailing list