This version of the notes refined in Slack after the Zoom meeting.


We discussed three issues/pull requests/whatever for the wording in the Charter:

Where the charter discusses scope as

The purpose of these features is to support authentication and authorization flows without compromising security principles for IdPs, RPs, and user agents as well as user privacy.


reword "for IdPs, RPs, authentication intermediaries (such as most of the industry-adopted solutions for MFA and Passwordless technologies), and user agents " to address the variety of exchanges that happen in current auth flows.

For the section of the charter that says "for the purpose of authenticating a user and/or requesting a set of claims in a compatible way OIDC or SAML." 

We are also going to work on the following issues in the refeds conflunce space to submit as issues:

  1. Absence of reasonable support for chained authentication implementations  - including proxies in the process where there are not intimate relationships between OP and IdP
  2. Require support for  Redirect through the login window for MFA (as well as other chaining)
    1. we wanted to require that FedCM implementations that use these 'popup windows' for re-authentication are compatible with these types of redirect flows. They have not said specifically they are not going to be, but that each browser would have a different take, and we would need to figure out/ensure they do, otherwise MFA authn etc. could fail. And we have no idea what they plan yet for the initial login flow yet, other than they suggested a similar popup window (or possible fenced frame ideas).
    2. Maybe stipulate that "any embedded or pop up windows must retain the full set of capabilities that the main browser windows have".
  3. Issues with failure if isloggedin not set
    1. compare to https://github.com/fedidcg/FedCM/issues/442
  4. Issues with discovery -- if i have not set isloggedin yet in my client, i will not see that an IdP i may prefer is accepted by an OP
    1. compare to the multiple IdP support unresolved PR https://github.com/fedidcg/FedCM/pull/438
  5. Scaling – if the user is isloggedin at multiple IdPs, multiple calls must be made to the different IdPs and there are implementation issues
  6. The spec must confirm that if the user islogged in to multiple IdPs the RP has called FedCM with.. all IdPs MUST be shown
  7. The spec must confirm that that even if the isLogged in multiple, even those IdPs that return 0 accounts MUST be shown
  8. --is another multiple IdP issue the Order? That clients can choose to show isloggedin with accounts more prominently than isloggedin with no accounts , but otherwise the list should be in the order specified by the OP?
  9.  if the accounts call can not handle redirects, and the IdP is not handling its own sessions (e.g. proxied), that will fail as well (maybe). Although that leads us back to all those bigger issues about proxies etc.

Live notes

Attending: Judith Bush, Phil Smart, Gary Windham, Chris Phillips,  Scott Cantor

Regrets:

Scribe: Judith

Agenda

  • Cancel the 08-30 meeting or would someone be willing to act as host?


  • Current charter wording
    • The W3C Web Identity Credential Working Group will develop recommendation-track specifications defining an API that allows websites to request a federated identity credential or assertion with the purpose of authenticating a user and/or requesting a set of claims in a compatible way OIDC or SAML.


Notes:

Last FedCM call take away: yank buried challenges and create open issues to be input for the working group. So we need to make first class problems for the working group;

  • Scaling, security elements, discovery, …. REDIRECTS/chained/proxies, not logged in


Note the need for a security test of the design – although standards don’t always require a security test and review. The reviewers need to raise the security concerns against the API

Some discussion with the islogged in is that the browser should have (per Tim Capelli)  a client ID for acting as an RP, but others deny this need.

Scott points again to ECP profile in SAML (ECP is SOAP based around message actors, with pipelines of transactions. ECP creates a communication path from IdP to RP with the browser as a message intermediary. A virtual SOAP channel.) 


Make issues 

  1. CHARTER issues
    1. Fix to and
    2. State compliance : SAML browser SSO ref and OpenID connect core
    3. Add intermediaries The purpose of these features is to support authentication and authorization flows without compromising security principles for IdPs, RPs, and user agents as well as user privacy.
  2. Chained authentication - proxies in the process where there are not intimate relationships between OP and IdP
  3. Support Redirect through the login window for MFA
  4. Initial log in and discovery
  5. Scaling – if the user is logged in at multiple IdPs multiple calls
  6. Confirm that if the user islogged in to multiple IdPs all MUST be shown
  7. Confirm that even if the isLogged in multiple, even those IdPs that return 0 accounts MUST be shown


  •  Who could talk to Duo – see if Nicole could connect us through.
  • No labels