○ Agenda
    § Browser Interactions special call
    § Claims aggregation draft
    § External organizations

    § Browser Interactions special call
        □ Tim: WebID draft evolved: https://github.com/samuelgoto/WebID
        □ Concern of deferral of any problem into a enterprise construct. Anything that needs a SSO. How you determine it is an enterprise context is a hard unsolved issue.
        □ Fork enterprise issue
        □ Microsoft believes in "Work profile" concept, but concern of it becoming a bucket is acknowledged.
        □ How do we prevent someone like google to leverage it for SSO without enterprise's concern
        □ Firm stance - nothing will be dependent on device management, not a requirement for enterprise scenarios. Not against MDM augmenting, but cannot depend on it.
        □ Educating Sam on various use-cases - 1:1 conversations, IETF 
        □ Explicit roadmap section - how it evolves. Not ready for a WG, still a thought experiment. Still identifying all the things that will break with the privacy sandbox
        □ Google is concerned about the larger picture, everyone eles is concerned what breaks after in Jan 2022. what breaks in 2024 (anything like links decoration breaks) - and how you fix it
        12% of users use directed identifiers with Apple - terrible user experience
        □ George: OIDC breaks too - some constructs, but not an OIDC flow
        PAR, does not look like link decoration. Top-level question - any desire how to do what they want to do while preserving existing identity flow
        □ Tim: that is added to a new roadmap section. What can we do to profile these flow and create allow lists for those flows. May be able to classify OIDC flows. Are you ok that for 2 years advertisers leverage identity flows to continue tracking?
        □ George: browsers could do without breaking the flow is what safari does - do you want to log in to this website? If RP can advertise, this is OIDC provider I support. Very few RP open to a random IdP. Easy for the browser to discover - pause issuer redirect and ask do you want to log in - will kill all the advertisers who do not want to involve the users. Option to the user to remember the decision. 
        □ Tim: guess. The minute we ask RPs to make changes - than ask them to use this new API would be Google's answer?
        □ George : implementing a new AS to talk to new - different
        □ Tim: OIDC flow via WebID API. Can't to code flow, need to send access token.
        □ If brokering, 
        □ George: using a new WebID API does change the flow, not OIDC anymore. Are we ok as Connect WG with that?
        □ Tim: back to whether stakeholders need to make changes - not right if this is a transitional solution. If google's solution becomes a specification.
        □ John: W3C standard does not necessarily mean adoption.
        □ George: being identity guy for RPs, RP change over IdP change is a preference
        □ Nat: Putting just one JSON file in RP is easier that new AS.
        □ John: 
        □ Tim: whole RP advertising is not just JSON, invoking API too. Ultimately asking people to ask changes. Need to be careful what to ask.
        □ Mike: we probably only get one shot to ask people to change things. Companies are thinking of multiple phases of changes, but that is chaos. Zero to one opportunities. Many RPs will not change much unless web providers change a lot.
        □ Tim: we are trying to make a case that there are even FIDO. We are getting into user prompts. User will get 5-11 prompts to authenticate. Need to converge these conversations. Need to be more intelligent which credential user uses, to make a choice.
        □ Not only address Sam and team, but 
        □ Nat: why does it have to be calling API? Instead of putting RP metadate file at RP domain
        □ Tim: because that assumes RP supports all IdPs.
        □ George: if RP only change once, WebID should be a smaller priority than decentralized. RP will change whenever necessary to keep the traffic. RPs will need logged in traffic in the best interest of revenue stream. Log in walls if not pay walls. Dealing with decentralized identity is a larger change that the change we are talking about here. Rewriting the code, 
        □ Tim: disagree. processing is different, but transmission of the identifier and assertion remains the same. 
        □ George: no, dealing with a claim signed by a private key of a user is different from a confidential client. Concept is similar but the code is different. Code change for decentralized identifier is important.
        □ Brian: concurring with George in difficulties in making these changes. Decentralized may be similar concept but changes required are larger.
        □ Tim: we have to stop of thinking of DIDs as only for decentralized identity. Why not use a spec as a structured identifier instead of Google creating a new identifier type. It is not only an SSI concept
        □ George: not going to stop RP to say "I received your DID, now give me your email"
        □ Dereference that DID, yes you can use DIDs to build a new process, Apple and Google using pairwise pseudonymous identifiers would be great. Everybody
        □ Mike: potential browser API will only build an ecosystem as far as browsers build it - but Apple is hostile to participate. Unless Apple and Firefox in, we can't change the browser world - WebAuthn proved it. 
        □ John: I would not count on Firefox implementing anything like WebID soon
        □ George: Browser chaos.
        □ Tim: firefox is at least loosely engaged with google. Apple is not even talking
        □ John: talking does not mean having implementation resources.
        □ Tim: smaller group of 4 people will come up with a more detailed agenda to have more structure. We have to ask - as OpenID, are we looking at sustaining things, looking into a long-term solution like account chooser, or..? Microsoft is trying to take a long term view
        □ George: long-term view but recognize there will be implementation hurdles and make sure things do not break unpredictably. 
        □ Tim: we agree with the concepts you proposing but we do not see it realize in 2022.
        □ John: looking at consolidated flows has to be grappled with. Web payments API to prevent extra concents. How we combine Conect, Webauthn so that we have consolidated flows for the user is a high priority.
        □ Tim: if I as RP have to invoke new WebID API to prompt user to authenticate, can query idP that they can use WebAuthn, do we even need to show IdP screen, for example? More discoverability and less prompts?
        □ George: how to make customer journey better? Not just about authentication, but all identity lifecycle including revocation. Next gen OIDC that works with the browsers. 
        □ Do not throw use-cases to extend olive branch..
        □ John: in a privacy preserving way that preserves user experience. Much more free to experiment - Google?
        □ Nat: is there use-cases
        □ George: not in Google repo, but initiated by George and Vittorio
        □ https://github.com/IDBrowserUseCases/docs
        □ Nat: Use-case and privacy considerations are very important - not what Google believes is privacy preserving. For example, Flok is a terrible idea
        □ https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
        □ George: a lot to learn in terms of user experience from webauthn. Do the user understand what it is? Words, UX describing external authenticator is different per implementation…
        □ IdP has the user. If you take the user away.
        □ Tim: whole fact that UI continue to this hostile - will be the devil. In Wifi alliance, got to agree the providers to follow UI/UX guide. It is unacceptable for each platforms. UI/UX certifications!
        □ Even chrome is not internally consistent.
        □ George: Is there a place for foundation to have a stronger voice in UX. Sub working group? Whatever we do at the protocol level should be a straight progression of where we want people to be.
        □ Tim: FIDO has a UI/UX working group that seems to work quite well.
        □ If output is some sort of the document that people are expected to follow, IPR agreement should be present
○ Claims aggregation draft          
        □ Adam: not much to report on. Flows are getting positive reviews as it sits today. 
        □ Is there a way to get a feedback on credential provider before filing issues. External document is tricky.  You need to send the text version of document to the ML, so it is part of the public record.
        □ Contribute the doc before starting to raise issues against claims aggregation draft.