Peter: browser mediated take on SAML... trying to fix the things that will break when we lose third party cookies... It smells like an early review. They have a manifest - browser calls an identity provider for basic information like branding. They should add light and dark color modes and follow some of the examples of the webapp manifest. Concern: they have an accounts endpoint which could be abused... Not sure how to get around. The browser can hit an IDP and ask "does this user have an account on this service" - not sure how they identify this. A nonce? They say many places they haven't worked out the details... Needs to be designed so crawlers can't just scrape all your accounts. Renamed evolutiuon of WebID...

Dan: todo: link to WebID discussion with Sam Goto...

Dan: I felt quite positive about the initial WebID propsoal.

Peter: overall the direction is good the approach is good.. reusing as much as you can... you won't have to rewrite everything if you're building an IDP... We need more data.

Peter: SAML and OIDC require public key crypto ... don't see anything here doing that. They do also have section on privacy.. will look at that more and leave some feedback.

Amy: see the cg report. A list of existing auth scenarios - only a few small parts actually break in absence of 3p cookies. Someone who knows more about js apis than I do should review the explainer.

Peter: in OIDC or SAML the IDP signs the response so the RP knows to trust the IDP. I don't see anything about signatures, does it implicitly trust the UA

Amy: Not sure, seems so?

Peter: Hard to believe they would have just ignored that. ID token itself is maybe a JWT? Kind of vague.

Amy: Has there been much discussion in privacycg?

Tess: we've had a couple of joint meetings. Specific topics. PrivacyCG doesn't do privacy reviews, so nothing to point at. Eg. we met on the relationship between fedCM and the login status api. At least one other, generally about when 3p cookies go away.

Peter: ability to scrape accounts api? But looks like you have to have a cookie to access that, so signed in once with the IDP before you can get back the accounts.

Amy: not clear there's anything to stop IDP tracking you across sites, they need to know what you're logging into

Peter: yep, more of a feature, for session management

Peter: is it possible to spoof the logout endpoint and log people out of sites? You should be able to go to the IDP and say log me out of everywhere - that's a feature. But not for other people.

Tess: out of scope for this is logging into the IDP itself right? Reasonable to assume the IDP would gate that button.

Peter: can I go to RPs and say by the way Tess logged out? More of a DOS attack than a leakage. Apparently an API call from the UA to the RPs. Not sure what that handshake looks like. Other than that generally looks fine to me. Minor things in the fedcm.json, they have colours and branding - dark mode support?

Amy: intent to trial on chrome status..

Peter: where does it go from here?

Peter: already an issue about light mode vs dark mode

Amy: could ask about feedback from their origin trial? and from devs?

Peter: token is a JWT, just not clear in the spec.

Amy: seems to always require name and picture... not all sites will want that. What's the bare minimum to identify an account?

Tess: username probably

Hadley: Amy are you happy with sam's response ?

Amy: yes - although "web identity API" is not my favourite naming... could be "web identification API"... identity is a controversial word.. invites potential scope creep or general confusion or upset..

Hadley: I think it would be useful to tell them that.

Amy: I'll leave a comment to say "thanks looks good" and leave that comment.

Hadley: name and picture always involved? Sam says it's an undersirable shortcoming. If we're going to sign off on the review can we say something like that?

Amy: At this stage of early review - just that they know it's an issue is good enough.

discussion on venue

Peter: It would be nice if a working group had this on their radar...

Amy: have they liaised with web app sec? I will leave a comment and set it to proposed close.

plenary

Dan: do we think this is going in the right direction?

Rossen: check of directionality.

Tess: I'm fine with it as long as it's understood that it's an early review and there's no enormous red flags.

Rossen: Not a license to ship.

Rossen: maybe mark as preliminary OK label?

Dan: could we ask them to file subsequent reviews when they get further?

Rossen: all the API I assume they will bring back to us when they are more solid.

Dan: propose: "Thanks for the opportunity to review this work. We largely think it's going in the right direction. this is not a full endorsement of the current API or architecture as specified in the CG report. As this is a big piece of work with multiple moving pieces, we'd like to suggest you come back to us to request indivdual reviews of these components once they reach an appropriate stage of maturity / consensus."?

agreement to close with the above comment