W3C

– DRAFT –
WebID, a federated SignIn API

29 October 2020

Attendees

Present
Alan, AramZS, aschlosser, Chris_Needham, dom, jeff, jyasskin, kazho, kenrb, lgombos, majidvp, melanierichards, pl_mrcy, Rob, tantek, Travis_, weiler, wseltzer
Regrets
-
Chair
-
Scribe
dom

Meeting minutes

<kenrb> Slides: https://docs.google.com/presentation/d/1Kk4WQIAAbkmzzzMGd5LoDnGq9kfpAxE8SNl4guUrUgw/edit

<daniel> Is there a doc that details the extensibility model for the ID types that are exchanged between the browser and entities interacting with the APIs? I want to make sure we can exchange various types of IDs, for example: the upcoming Decentralized Identifiers standard from the W3C

<weiler> Ken, to what degree are you interested in making it easier for the user to choose an IDP not on the list?

Daniel_MS: we've been working in the DID community (decentralized identifier) - what you call directed identifier, we call them pairwise identifiers
… with such a broad name "webid", are we going to make sure this will be extensible and can include other related technologies such as DID?
… one of the interesting things with DID is not only they're directed, they also contain service endpoints that allow to ask for more information
… have you thought about incorporating things like that?

kenb: we're aware of that
… we're thinking of those use cases and we're trying not to close; this is part of the trade-off we're considering
… when you're think about the first sort of buckets (permission-based), it's very easy - we're just tunnelling a protocol
… and we prompt the user - this allows flexibility on the backend
… it's harder when we do browser mediation, where the browser needs to know what information goes through
… when you talk about sign-in vs other use cases - it gets back to the question of what the browser is knowing about what's going on
… it's useful to get that kind of feedback based on specific user flows

Jeff_Jaffe_W3C: as you noted, this is an amazingly complex area with lots of history and use cases
… at the risk of making it more complex: one use case I'm quite interested in is the area of Web Payments
… with the Payment Request API we're enabling browesrs to play a surrogate role managing credentials for users
… representing identify through UA is becoming increasingly more important
… are you looking at these use cases? prioritizing toward them?

<daniel> DID > lookup DID Doc > query service endpoint for payment details > feed it through browser API

Jeff_Jaffe_W3C: webidl solving all ID problems on the Web, it may be intractable; maybe by choosing a relatively new use cases on the Web and prioritizing for those, we could maybe make faster progress

Ken: Good suggestion - don't have an answer for that
… I interact with the Chrome payments team, been involved with secure payments confirmation

<daniel> (DIDs are kind of like a Rosetta Stone for these use cases, and many others)

Ken: we're aware that the problems are similar but in different spaces
… but no answer yet

alextcone: similar question in the mobile web context where you have OS-based sign-ins (e.g. "log in with Apple")
… have you looked at that upstreaming of the identity flow when the OS provides support for it?

Ken: good question - so far we haven't really
… I don't know how appropriate it would be a Web API to be trying
… making a universal Web API, we have to be careful to tie to specific platform capabilities
… I don't know if there is a general from the platforms that could help us there

alextcone: maybe having something around risk mitigation for the browser and the delegation API
… e.g. if the OS doesn't let you have the mapping between OS and RPs

<daniel> This alludes to the fact that we need a substrate for user IDs that transcends any UA layer

Ken: this has come up; if we're reimagining how identity works and possibly breaking away from existing protocols, should the platform be a bigger part of this than the UA?
… there is a case to be made that this would be true
… we've been focused on shorter term considerations
… it needs to be part of a much broader discussion

weiler: thank you for bringing this up and pushing this
… I appreciate you're prioritizing RP tracking
… how prioritized would be IdP choice? this could also help with RP tracking indirectly

<tantek> weiler is getting at a very good specific example of the power dynamic / disparities that I'm getting at. thank you sam

Ken: we've been making this out of scope (as part of the NASCAR problem)
… if you can vary the IdP, that would be another approach
… I can't say we've looked at that

weiler: I'd like that to be in scope here
… looking at how sites are dealing with the nASCAR problem, RP are only providing 2 or IdP at the moment, not letting the user pick their own

<pchampin> +1

<Zakim> weiler, you wanted to ask to what degree are you interested in making it easier for the user to choose an IdP not on the list?

<tantek> +1 weiler

daniel: what do you see the intersection with strong auth, fido?

ken: they're a little bit orthogonal
… authentication is only a piece of the flow - you authenticate to the IdP who can then assert they've verified your identity
… I think they're complementary
… stronger auth makes the assertion stronger
… preserving federation helps with adopting stronger auths, since IdP have adopted it and are more likely to do it than RPs

Dan: we're working with OpenID on DID sign up, for decentralized identity
… I hope we're working toward a system where users wholly own their identity

tantek: thx for the presentation

<brent> +1 to making sure there is support for DID-based solutions

tantek: people have already touched on important issues, in particular sam's questions
… I wanted to bring the question of power disparities between users, RPs, IdPs
… How does the design of Web ID seek to alter these dynamics? who should have agency over what in your spec?
… if it's not asserting, I would encourage you to look at what dynamics it creates

Ken: we're trying to promoted directed idnetifiers which give users better control of their identifiable information
… I think you may be asking whether this can be used without a centralized IdP, which we're not really looking at

Tantek: well, one question is what choice users have if only 2 or 3 IdP get offered to the user
… what agency users have in picking their own IdP to have actual federation?

<weiler> tantek++

Tantek: we have to confront the power disparities
… and have a stance on them, on whether to change or disrupt them

Ken: that's not our explicit goal

<daniel> To really make this extensible and generative, to take into account what Tantek is talking about, I should be able to have an agent somewhere on my machine that registers an IDP channel with the WebID APIs

<daniel> 1+

<daniel> oops

Ken: it has bearance on some of the trade offs
… when we're trying to change the protocols, adopt new paradigms, we should be asking this question

<daniel> We have long needed to modernize the protocol handler portions of the browser

<daniel> this may be a good opportunity to do so

<Zakim> tantek, you wanted to ask about power disparities between users, IDPs, RPs and what choices about who should have how much control/power/agency does this design make and/or default to, amplifying (or inverting?) existing disparities

aschlosser: thanks for the presentation - I think we had a lively discussion on github on the different trade-offs of the various proposals
… it's going to be challenging, e.g. when you look at cross-device scenarios
… the aim is also about classifying traffic for IdP from others to provide different primitives to protect from covert tracking
… would this create a special container for the data that would only be available to the IdP in that specific context, using a SameFrame approach with elevated rights?

Ken: that's what we're trying to look at indeed
… whether it is indeed a sealed container is still up in the air, but at the high level, that's how we're thinking about it
… some of the specifics of that depend on where the primitives go
… there is a lot of ongoing discussions in how to make the Web more privacy preserving
… which would impact the particular direction we would need to take

aschlosser: the specifics don't matter to me too much - the overall secured environment for IdP flow is what I think is the key model

weiler: going back to fido/webauthn - I think there are more related than you think
… WebAuthn solves the privacy problem by preventing RP tracking
… it has its own challenges
… but maybe to solve RP/IdP problem, we need to move everything to WebAuthn
… I described we need a clear story for Federated?

aschlosser: WebAuthn still needs an account to authenticate against
… IdP can use WebAuthn to remove the password

weiler: you can create an accout with just a WebAuthn credential

Ken: this is a bit off our mission - it's a great question though
… would that be ideal world, with no need for federation?

<tantek> Aside: prior federated identity work at W3C: https://www.w3.org/TR/indieauth/ - adopted and being iterated by the IndieWeb community as a living standard: https://indieauth.spec.indieweb.org/

<daniel> DIDs solve for this as well

Ken: there are questions about backup for these auths, which lead back to a service to manage this
… it's possible to envision a future that have these properties
… signing-in and authenticated have been approached together but they probably benefit from being dealt with separately
… but this sounds longer term
… but in the meantime, federated identity is far superior to have user/password on every web site
… so we want to see how to make it continue to work as the web is getting more privacy-preserving

Daniel: having the ways for IdP to promote themselves to the RP when they integrate this new flow, this owuld help

John_Bradley: as one of the authors of OpenId COnnect, we're looking at self-issued IdP
… the identifiers for that IdP will be changed to also include DIDs of several flavors, but not exclusively DIDs
… having lived through the history of account choosers and openYOLO
… in order to get around omnidirectional identifiers and do true pairwise identifiers, having @@@ is a requirements so it's disappointing that it's out of scope

<daniel> Really can't be out of scope, unless we want to engrain the relative status quo

John_Bradley: for enterprise IDPs, research & education - logging out is actually a harder problem than logging in
… a solution that doesn't allow for session termination won't be a complete solution
… I look forward to having more discussions with the Connect WG, the FIDO & WebAuthn WG with this group

<timc> I'll put my comment here. We need to be careful with the blanket statement that federation is better in consumer. Yes, at a high level, one highly secure account is better than multiple weak passwords, but we're seeing first hand the impact of a single identity tied back to hardware / software vendors and the potential for having account access restricted or removed for some RPs.

John_Bradley: to come up with a more fulsome solution
… Clearly we need better instrumented APIs in the browser to help solve the risks of browsers breaking them as they stop invesive tracking

<tantek> thank you kenrb for presenting & facilitating

Minutes manually created (not a transcript), formatted by scribe.perl version 124 (Wed Oct 28 18:08:33 2020 UTC).

Diagnostics

Succeeded: s/ID/IDP/

Succeeded: s/ID/IDP/

Succeeded: s/ID/IdP/

Succeeded: s/agencies/agency/

Succeeded: s/think/described/

Succeeded: s/@@@/YOLO/

No scribenick or scribe found. Guessed: dom

Maybe present: alextcone, Dan, daniel, Daniel_MS, Jeff_Jaffe_W3C, John_Bradley, Ken, kenb