Skip to content

Latest commit

 

History

History
368 lines (278 loc) · 15.4 KB

2022-12-12-notes.md

File metadata and controls

368 lines (278 loc) · 15.4 KB
Raw

FedID CG call notes (Atlantic), 12 December 2022

  • Moderator: Heather Flanagan

  • Scribe: Nicolás, Dmitri

Call-in details: see https://www.w3.org/events/meetings/

Charter: https://github.com/w3c/fedidcg

Agenda

CHAPI slide deck

Notes

  • Heather: I wanted to report on something that happened at Internet 2, which is a conference on higher education and research. It brings together a bunch of federation folks. I had a session on Tuesday morning where I talked about what’s happening in the browser space. The community engaged such that for the rest of the week there were hallway conversations and that community is coordinating a hackathon to understand how those big open projects can take advantage of FedCM. Seamless Access is very much like CHAPI in that they store info to help the user know what credentials to use to login. There are about two dozen people who will meet at the Canary (?) offices in Canada. So that was awesome!

  • Manu: You said that there is overlap with CHAPI. I wonder if you have links to presentations so that we can analyze the overlap.

  • Heather: I’ll put those in the scribing doc:

CHAPI

  • Heather: fully decentralized technologies are out of scope for our work, based on our charter. However, the CHAPI use-case is also looking at the identity space and there is a similar use-case with Seamless Access. So while we’re not trying to change the scope of our group, it would be good to hear what they’re doing.

  • Manu: We’re here to talk about overlaps between the FedCM work and CHAPI. Here is CHAPI in one picture.

    • Three things happen: there is an issuer which issues credentials to a digital wallet, and at some point the individual has an interaction on the web with a verifier. CHAPI is used to exchange verifiable credentials between digital wallets and websites. FedCM API parallels what CHAPI does: it exchanges identity claims between IDPs and websites. In this model, the digital wallet is the IDP.

    • One area of overlap is registration. In FedCM you have an IDP, and it gets integrated with the browser in some way. In CHAPI you can use a website or an app for the digital wallet. There will be a prompt to ask the user if they would like the digital wallet to manage credentials. Later on, when the user is in a different security domain and they click on that website, they get a wallet chooser. Each icon is a different wallet, and the user can pick which one to use. To be clear, this individual has a ton of different wallets, and we generally wouldn’t expect this many.

    • The other big overlap we have is selection. The individual needs to make a selection about which digital wallet to use. They have to choose where to store their credentials. Today, this is polyfilled in all major browsers. We use a combination of 3PC and first-party mode to accomplish the flow. There are large deployments of CHAPI that are going live next year. US Citizen and Immigration Services want to use this later on, as well as some education users. So this is way beyond proof-of-concept.

    • One of the reasons we’re here today is that this 3PC is an issue. The UX we had with 3PC with the wallet picker is what you see in Chrome today. The wallet selection is protected through iframes and such so that the site does not get visibility into the wallets that the user has. With 3PC going away, we cannot have this anymore. We have to now use this image on the right (popup). This has happened for years, i.e. this is how Paypal works. It is not so terrible on mobile but on desktop it is not great. Because 3PCs are going away, the UX is going to get worse.

    • CHAPI has made a lot of interop tests. We had 17 different issuers and 8 different wallets. These companies are moving forward with the polyfill.

    • Before we get into the discussion, I think it is important to set some rules in terms of goals and non-goals. We’re not trying to move people away from SAML and OpenID. We’re just trying to get a mechanism to provide a better user experience. We’re not trying to solve generalized data sharing nor that FedCM needs to pull decentralized identifiers. One goal is to explore the commonalities. CHAPI is built on top of the credential management API. We’d like to not have to downgrade our UX when 3PCs go away. We’d like to replace parts of the CHAPI polyfill with more native calls, if it leads to better UX.

    • The other thing to mention is that a bunch of us met at IIW. Sam did a great job doing a writeup in the FedCM repository (issue 374).

  • Sam: A good TL;DR of the issue is that it asks if there is enough commonality or if this falls into some other API’s responsibility. From Chrome’s perspective, breaking people’s work is not something that we take lightly. Many of the architecture choices that CHAPI has made are things we are excited about. We are excited about the registration of IDP (bring your own). The part I’m most concerned about CHAPI is expressivity: the more CHAPI looks like a general communication channel, the harder it is to keep privacy properties.

  • Heather: We’re trying to fix services that take advantage of 3PCs for IDP discovery. That covers a couple of different options.

  • Manu: That is exactly what CHAPI depends on 3PCs for right now. The authn.io domain uses local storage to know that the person has stored a digital wallet. There seems to be a high degree in terms of the selection menu. As Sam said, there is the danger of making this a general sharing API. We want to be scoped and precise about what we’re trying to solve here.

  • Heather: Regarding the chat question, I think we’re not ready to talk about the end customer perspective.

  • Kris: I do not see IDPs as being purely just identity. It can be identity and role. I’m not against the idea of merging the two streams, but I do think that we should be aware that this would be a major change. The concern I have with the merging is also trying to boil the ocean with one thing. FedCM should be more focused on how to handle federated credentials, and less about the 3PC aspect of it.

  • Ben: I think this is really interesting. This is about viewing info that’s there, adding your own IDP. There’s an idea of a new user interface for identity handling, and there’s how to make federated identity as it currently exists work in the absence of 3PCs. I think perhaps that is something we need to prioritize more clearly. I filed a new proposal last Thursday for something that is more focused on the first: a thought experiment.

  • Judith: I’m with OCLC. We’re returning to activity with this group. I wanted to advocate for wallets as more than just an identifier for a user. A party communicating that a user does have access because of affiliation is a use-case.

  • Marty Reed: We support this. We’re looking to implement CHAPI in 3 US Statewide use cases.

  • James Rosewell: question for Manu — there's a lot of talk in the UK about online safety; legislation going through, hopefully next year. You mentioned Age Verification — can you expand on that more?

  • Heather: great question, but somewhat out of scope for today's discussion.

  • Manu: of course; I'll try to be quick. short answer — yes, CHAPI supports that use case. There's a nationwide US program, TruAge, that's designed to be privacy-preserving. The way it's solved today in the US is — a person hands over their entire drivers license (with 35+ pieces of data). TruAge just compresses it down to one 'I'm over X age' credential. And it's partly based on CHAPI.

  • Heather: listening to the thread of IdP discovery, CHAPI, Seamless Access, etc, and thinking back to the other issues we've identified with Front Channel Logout & other things that will break. I'm a bit worried we'll be distracted by the shiny. There's a lot of things we need to get done. So, let's prioritize carefully, so that people contributing code know what to focus on. (Related links convenience.org | TruAge)

  • John Bradley: I think we're going down a little bit of a rathole on the functionality of VerifiableCredentials. If we step back, both Seamless Access and CHAPI do a discovery function. In the purest form, we should answer — can FedCM actually enable those things, to enable discovery, once 3PCs go away. With normal federation with single logout, you want to share 3PCs between IdP and SP. But here, CHAPI and S.A. are trying to share 3PCs between a discovery service and the SP (so that the browser can display the appropriate discovery dialogue to the user at the SP). So, the first thing we're concerned about is 3PCs, but eventually we'll be talking about fragments & query parameters to curtail tracking. So question to CHAPI folks — this breaks w/o 3PCs, what breaks without query params?

  • Manu: we're not asking for anything specific right now. Both things you outlined, John, seem like good things to explore. if we can continue to do what we're doing today, meaning, having a good UX without a 3PC functionality, that would be an OK outcome. So, we just want to be a part of the conversation and share our usecases, just in case there's a way to solve everyone's problems.

  • Ben VanderSloot: to the smaller issue, the more easy answer to getting this to work despite 3PC deprecation, will be the Storage Access API, an iFrame authenticated to a 1st party cookies, so that API is currently seeking graduation, has interest from Safari, Chrome, Firefox. So that can address the smaller ask. I do agree the bigger ask is interesting, and FedCM is the most direct comparison.

  • Dave Longley: wanted to respond to that, since we went through an implementation cycle using the Storage Access API for CHAPI. It was really challenging to make it work — some browsers implement it differently, have different gating requirements, prompts for the user, etc. We found that it was really difficult to make it work with any good UX for CHAPI, so we moved to a fully 1st-party flow, so we degrade to a first party flow (window popups), since SA API was too challenging.

  • Ben VanderSloot: very good point. in the WebCompat issues wrt Storage Access API, very fair. Depending on when you did that, it might be slightly better (we've reached a new era of rapid convergence on the SA API, so some of the issues should be hammered out, hopefully). The thing that still needs to be implementer-defined is — when a prompt should show up. But we're largely converging on a similar vision for the SA API, and hopefully will be shipping that in the coming year.

  • Anil John: good morning/afternoon, I'm Anil John, Technical Director with DHS. On behalf of Citizenship & Immigration Service, we're moving towards issuing our immigration credentials as digital credentials. One of the decisions that we made is that when issuing those credentials, we need to ensure that the choice of the wallet (where it will get stored) is in the hands of the user. That's the core point for me as the customer — I need it to be baked into the environment, that puts the choice of the wallet in the hands of the user. Currently, the choice is very much about the 21st Century version of Nascar buttons (lots & lots of QR codes). So, what I'm interested in CHAPI in, is specifically the wallet selection. So, I'd make an argument that it is in the interest of any public entity, in the US or elsewhere, to make that a seamless experience in the browser.

  • Heather: so, we have quite a bit to talk about. If you haven't had a chance to look at the relevant GH issues, please do so and comment, so we can prioritize what the team can do.

  • Manu: just to speak real quick about next steps from the CHAPI perspective, we'll be spending Q1 & Q2 next year, prototyping against using FedCM with the CHAPI UI — chrome canary builds, etc. We'll be looking at that from a "let's actually implement some code & see if there's bits and pieces of FedCM that we can use to make the experience better", and then we can report back to this group how the implementation went. Like, do the new StorageAccess API workflows work, are the proposed pieces of FedCM helpful for our workflow, etc. We hope to do some active development incubation and report back to this group, hopefully by end of Q1 next year.

  • Heather: our next call is a week from today, and it's the Pacific call, so ensure you have the calendars right. Then it's the holidays, and our next Atlantic call is Jan 9. I try to keep calendars up to date, and it's not perfect, that's why you see cancellation notices once a month. This has been a really productive year. Go forth, do good things, and we'll see you next year!

Attendees (sign yourself in)

  • Heather Flanagan (Spherical Cow Consulting, chair)

  • Ted Thibodeau (he/him) (OpenLink Software)

  • Zacharias Törnblom (SUNET, Swedish University Computer Network)

  • Dmitri Zagidulin (MIT / DCC)

  • Judith Bush (OCLC)

  • Dave Longley (Digital Bazaar)

  • Manu Sporny (Digital Bazaar)

  • Kimberly Wilson Linson (RANDA Solutions)

  • Kris Chapman (Salesforce, co-chair)

  • Shawn Butterfield (Salesforce)

  • Sarven Capadisli (Inrupt)

  • James Rosewell (51Degrees)

  • Greg Bernstein

  • Anil John (US DHS / SVIP)

  • Brian Campbell (Ping)

  • Marty Reed (RANDA Solutions)

  • Mateusz Ruminski (RTB House)

  • Sophia Yakhno (Preiskel & Co)

  • Patrick Borman (Preiskel & Co)

  • Vittorio Bertocci (Okta)

  • Nicolas Pena Moreno (Google)

  • Michael Knowles (Google Chrome)

  • Yi Gu (Chrome)

  • Sander Engelberts (OCLC)

  • Peter Kotwicz (Chrome)

  • Christian Biesi

  • Brian Daugherty (Google Identity)

  • Jim Goodell (QIP & Chair of IEEE Learning Technology Standards Committee)

  • Dan Moore (FusionAuth)

  • Sam Goto (Google Chrome)

  • Juan Caballero (Centre.io)

  • John Bradley (Yubico)

  • Michael Shea (The Dingle Group)

  • Joe Andrieu (Legendary Requirements)

  • Brent Shambaugh