[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