Tess: This probably isn't the worst idea... but taking some steps back... peoiple use fedcm because they don't want to create an account on every single thing. Why? They don't use a password manager and don't use passkeys? FedCM is fixing "the wrong problem"... It's ok - you use fedcm, google knows you have an account there... we shouldn't have got to that place where this is a necessary change... We should push them towards technologies they can create accounts they don't have to care about... If we're trying to move the web to something more private we shouldn't be encouraging people to use fedcm...

Dan: I use federated identity because there's a relationship... e.g. github to dev.to....

Jeffrey: you're weird. ;-)

Tess: yes.

Dan: accepted.

Peter: i do agree with your point... the counter-argument is some Fedcm use cases... I also use it as Dan does... Other counter-argument... for some places there is a strong bias for using SSO because it's phishing resistant... That's also mitigated by passkeys, etc... I also question if fedcm is addressing that use case properly...

Jeffrey: Yes we should be pushing people away from fedcm... but none of those impact the answer for this particular issue... Once you've connected identities in some way the 2 sites can be connected. So we should not object to this suggestion...

Peter: One thing I would like to see: FedCM not tied to speciic IDPs. I'd love to run my own personal IDP and use that to log in everywhere... Scared of a FedCM world where only a few top IDPs are used...

Dan: you're weird.

Hadley: I'm with you but if I'm a RP don't I choose who I'm going to trust?

Peter: yes - not sure how to reconcile... FedCM allows you to "bring your own IDP".. but RP cant just trust any old IDP...

Matthew: +1 to both Peter and Hadley... Just to say that we both briefly touch on this in discussion with Sam ... we did touch on that in this meeting... minutes from last f2f

Peter: adding friction to log into another IDP...

Dan: should we be encouraging a pattern where web sites don't need people to log in unless necessary... Thinking of the multiple web experiences I've had recently using web payment where I haven't had to create an account...

Peter: can we decouple that the IDP... similar to trust tokens...

Jeffrey: VCs can do something similar where the issuer doesn't know who you've logged into - except with cooperation you can...

Pater: we can't prevent a back-channel but maybe we shouldn't allow storage access...

Jeffrey: ... for fingerprinting ... moving to active...

Tess: we don't have a general agreement to change passive to active fingerprinting.. some should do away...

Jeffrey: if we want to take this away, what does it give us?

Peter: I would argue that any valid use case for giving an IDP storage access.. should be given to fedcm itself...

Tess: we want developers to call the storage access API if they want access ... this is saying that in the case where they use fedcm, it resolves faster...

Peter: the valid use cases should be

some discussion

Peter: it should be mediated by the fedcm ...

Jeffrey: this is in conflict with the frustration with being sent extensions to fedcm...

Peter: I'm also pushing back on all the three dozen extensions... giving them storage access is giving them all of it...

Dan: what's the use case? the user need that we're trying to solve?

Peter: yeah - what uses for storage...