Skip to content

Latest commit

 

History

History
185 lines (176 loc) · 10.7 KB

2024-10-08-notes.md

File metadata and controls

185 lines (176 loc) · 10.7 KB
Raw

FedID CG/WG Telecon notes, 2024-10-08 (Atlantic)

  • Moderator: Heather Flanagan

  • Scribe: Phil Smart

Agenda

Notes

  • Heather:
    • Reminder, if here you are a member of the CG/WG.
    • Re-charting process, objection is going to the council for review
      • Side meetings during TPAC, suggested W3C team is going to get through this as quickly as possible. Maybe hear something back in the next few weeks w3c/tpac2024-breakouts#98
    • Simone, do you want to add something
  • Simone,
    • Nothing to add
  • Heather:
    • Notes from breakout posted at: w3c/tpac2024-breakouts#98 , https://www.w3.org/2024/09/25-credential-threats-minutes.html
    • More admin: meeting schedule, next week we are on schedule as not many people are going to Authenticate next week. So holding CG/WG call (atlantic), the week after is a WG call (pacific).
    • Next month is IIW. Great conference. Ticket sales close soon, max 250 attendees. Hosted at the Computer Museum (P.S. I assume in SFO).
    • TPAC: Wendy sent out an email to the mailing list, linked in the agenda. Want consensus on what is moving from one stage to the next, also a blog summary ‘cheat sheet’ to read to understand what happened. Ask questions on Slack if you want.
  • Wendy:
    • Echo thanks to all those who participated. No objections were seen to the consensus calls in the email. Thanks to everybody who presented the work they've done, for showing interest and demand and comparing alternatives. The next step for these in Stage 2 is getting into the guts of the specification text. Also great discussion on things still in stage 1. Lightweight FedCM. If you want to be involved in the discussion around Login Status API, there are two branches of work on that, one in FedID and one in PrivacyCG — Johann has added descriptions and summaries of the work in issue 8 – please comment.
  • Heather:
    • Help part. Horizontal reviews. Over to Wendy
  • Wendy:
    • To move forward in the W3C process, we need to make sure our API and specs meet the needs of our horizontal communities — privacy, accessibility, I18n, security, etc. (There are more!) Need for reviewers. Some people have done work like this before, and maybe those experienced can take on some of that work. Critical to take on this work, do we have anybody who is interested in championing one of those reviews?
  • Heather:
    • Do not need to be an expert in this, but a good opportunity to learn
  • Simone
    • The main output of this review process on the WG side, is to create a github issue following a template. It’s important to help the external reviewers understand what we’re building
  • Heather:
    • If you are interested in signing up, see issue 652: w3c-fedid/FedCM#652.
    • We are doing PR reviews today. We have two we want to go through, the Params API and the continuation API.
    • Starting with 661 (Params API)
  • Christian:
    • 661 should be straightforward, but some discussion on which params to allow. Is Aaron on the call (no). Should we allow a Map from String to Any, or should we allow a Map from String to <SomethingElse>? Any thoughts?
  • Elf:
    • I was thinking about allowing objects or simple values. You can also JSON parse a JSON object.
  • Sam:
    • The IdP can always call JSON parse. What happens if you JSON.stringify a number?
  • Ben:
    • Making it an ‘any’ type is probably best…the thing you put in might not be the same as the thing you get out (if you stringify).
  • Elf (from chat)
    • Trying to JSON parse “foo” does not work, but that is not valid JSON either.
      • (PS) updated this in the chat and it worked.
  • Sam:
    • JSON.stringify is stable wrt to JSON.parse. Things you stringify you get back using JSON.parse
  • Ben:
    • Some numbers lose precision if you do that.
      • Stringify you lose precision
  • Sam:
    • JSON.stringify and JSON.parse will cover all the important cases correctly.
  • Christian:
    • Change from Map<String, String> to ‘Any’
      • Will check precision
      • ‘Any’ might be slightly more limiting than people might think, but the main thing is that … it works for all practical cases as ‘Any’.
  • Sam:
    • Can we make that change, and then do we approve the PR or merge the PR?
  • Heather:
    • Queue, hear from Elf and then Wendy
  • Elf:
    • Discussion using a JSON content type, but should we use stringified JWTs?
  • Christian:
    • Can you rephrase the proposal
  • Elf:
    • Are we going with JSON stringify ‘things’ in the params API
    • But in some places in OAuth — like PAR, and JAR, and OIDC — they are using JWTs to represent some data as a string
      • Like a base64 encoded compact JSON serialised string
  • Sam:
    • JSON.stringify is a superset of everything we would need. So does not preclude you from adding a JWT into a param.
  • Elf:
    • Weird to encode a JWT then stringify it?
  • Sam:
    • An IdP knows which params it accepts. If it knows it is taking a string, it does not necessarily need to JSON.parse.
  • Wendy:
    • Adding a note to the issue to the PR, pointing to the minutes from this meeting. Sounds as if we have a conceptual agreement on the direction. Do we have people who can review the final before it goes to merge, for example, Elf?
  • Elf:
    • I think it is fine, just checking the options
  • Wendy:
    • It already has several reviewers, so with the satisfaction of those reviewers it is ready to merge. Do we need another meeting for approval? [No one requested more time]
    • Christian has the go ahead to mark ready for merge
  • Phil:
    • Is this now a stage 2 thing? Yes, it is.
  • Heather:
    • Move to continuation API
  • Christian:
    • Ben has reviewed it, thanks. The primary concern from Ben was a race condition, so I changed the wording
  • Ben:
    • Multiple IdentityProvider.resolve happening in parallel. I think this allows the interleaving of results and does not require a lock
  • Christian:
    • Changed the wording to say ‘waiting for the first to happen (close or resolve)’.
  • Ben:
    • That might do it.
  • Christian:
    • Same level of spec knowledge as Ben, so if somebody has better wording would be happy to hear it.
  • Heather:
    • No other feedback
  • Phil
    • The initial request to the assertion endpoint which triggered the continuation. I wanted to send those parameters back to the continuation endpoint. I need to check again if I added it as query parameters.
  • Christian:
    • Allow arbitrary strings in the resolve call.
    • There is a request to allow object for both of those
    • If you want to allow arbitrary objects from one but not the other.
  • Sam:
    • It would be good to decouple the problem; we want the ability to add in a backwards-compatible kind of way.
  • Christian:
    • Don’t think so, we can alter the API
  • Sam:
    • But that might break clients
    • …
  • Christian:
    • Yes, it could break compatibility or require updates to the RP
  • Sam:
    • Up to the IdP what they pass in the resolve function if we take arbitrary strings
    • Changing the ‘resolve’ API needs thought.
    • (P.S. and other comments that I could not catch, sorry)
  • Heather:
    • Continuation API might require a little bit more work before being merged
  • Christian:
    • Yes, that matches my understanding
  • Heather:
    • What are the PRs you might bring to the next call
  • Sam:
    • Start from the least controversial to the most controversial.
    • ‘Active mode’ spec exists, so might discuss that next. Or;
      • Fields API
      • Account Labels
  • Heather:
    • This makes sense.
  • Wendy:
    • Thanks, it helps when people note that they have reviewed the PRs. With asynchronous reviews, we can make the on-call review faster.
  • Heather:
    • Anything else we want to cover? Or end a few minutes early
  • Elf:
    • Getting ready to implement IdP registration. Would like to support both FedCM and Lightweight FedCM. Believe Aaron is passing auth_code in FedCM, asking Ben if it makes sense to send auth_code in Lightweight FedCM.
  • Ben:
    • Idea is, we are fetching the token from a ‘token URL’ in the same way as regular FedCM. Would make sense to put the auth_code through that.
  • Sam:
    • Chrome has IdP registration API in Canary, but not yet the Lightweight FedCM version. Maybe in a week or a month you will get that.
  • Elf (chat):
    • Thanks
  • Heather:
    • We all have homework. Please look to champion horizontal reviews and PRs.

Attendees

  • Heather Flanagan (Spherical Cow Consulting)
  • Sam Goto (Google Chrome)
  • Christian Biesinger (Google Chrome)
  • Alan Buxey (MyUNiDAYS Ltd.)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Phil Smart (Shibboleth/Jisc)
  • Benjamin VanderSloot (Mozilla)
  • elf Pavlik (independent, Solid CG)
  • Joel Antoci (Shopify)
  • Zachary Tan (Google Chrome)
  • Steffi Dobretzberger (DAASI International)
  • Wendy Seltzer (Tucows, Invited Expert)
  • Brian Daugherty (Google Identity)
  • Simone Onofri (W3C)
  • Tim Cappalli (Okta)