15:54:06 <RRSAgent> RRSAgent has joined #webid
15:54:06 <RRSAgent> logging to https://www.w3.org/2020/10/29-webid-irc
15:54:08 <Zakim> RRSAgent, make logs Public
15:54:09 <Zakim> Meeting: WebID, a federated SignIn API
15:57:17 <mknowles> mknowles has joined #webid
15:57:32 <majidvp> majidvp has joined #webid
15:58:51 <cpn> cpn has joined #webid
15:59:41 <weiler> weiler has joined #webid
16:00:02 <jeff> jeff has joined #webid
16:00:09 <jeff> present+
16:00:18 <lgombos> present+
16:00:18 <dom> Present+
16:00:29 <cpn> present+ Chris_Needham
16:00:30 <AramZS> AramZS has joined #webid
16:00:34 <tm> tm has joined #webid
16:01:10 <lionel_basdevant> lionel_basdevant has joined #webid
16:01:41 <weiler> present+
16:01:46 <Travis_> Travis_ has joined #webid
16:01:51 <kenrb> present+
16:01:54 <Rob> Rob has joined #webid
16:01:55 <kenrb> Slides: https://docs.google.com/presentation/d/1Kk4WQIAAbkmzzzMGd5LoDnGq9kfpAxE8SNl4guUrUgw/edit
16:01:56 <Travis_> present+
16:02:01 <dmarti> dmarti has joined #webid
16:02:02 <Rob> present+
16:02:08 <majidvp> present+
16:03:17 <AramZS> present+
16:03:44 <Alan> Alan has joined #webid
16:05:37 <pl_mrcy> pl_mrcy has joined #webid
16:05:43 <pl_mrcy> present+
16:06:17 <kris_chapman> kris_chapman has joined #webid
16:06:25 <yigu> yigu has joined #webid
16:09:21 <tantek> tantek has joined #webid
16:10:10 <jyasskin> jyasskin has joined #webid
16:12:37 <melanierichards> melanierichards has joined #webid
16:12:44 <melanierichards> present+
16:13:22 <pchampin> pchampin has joined #webid
16:13:53 <daniel> daniel has joined #webid
16:14:05 <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
16:14:42 <weiler> Ken, to what degree are you interested in making it easier for the user to choose an ID not on the list?
16:14:55 <weiler> s/ID/IDP/
16:15:44 <aschlosser> aschlosser has joined #webid
16:15:48 <kazho> kazho has joined #webid
16:15:49 <aschlosser> present+
16:15:51 <Hirsch_msft> Hirsch_msft has joined #webid
16:16:00 <tanvi> tanvi has joined #webid
16:16:01 <goto> goto has joined #webid
16:16:06 <John_Bradley> John_Bradley has joined #webid
16:16:11 <kazho> present+
16:16:56 <dom> q+ jordan_mitchell
16:18:52 <Alan> present+
16:19:21 <jyasskin> present+
16:20:07 <aaronpk> aaronpk has joined #webid
16:20:36 <Travis_> q?
16:22:07 <AramZS> AramZS has joined #webid
16:22:59 <tantek> present+
16:23:30 <Jemma> Jemma has joined #webid
16:26:18 <alextcone> alextcone has joined #webid
16:26:46 <timc> timc has joined #webid
16:26:56 <timc> +q
16:29:09 <timc> q-
16:30:37 <daniel> q+
16:31:05 <Jeff_deA> Jeff_deA has joined #webid
16:31:50 <dom> ack jordan
16:32:20 <dom> Daniel_MS: we've been working in the DID community (decentralized identifier) - what you call directed identifier, we call them pairwise identifiers
16:32:44 <dom> ... 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?
16:33:13 <dom> ... 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
16:33:14 <jeff> q+
16:33:20 <dom> ... have you thought about incorporating things like that?
16:33:27 <dom> kenb: we're aware of that
16:33:59 <dom> ... we're thinking of those use cases and we're trying not to close; this is part of the trade-off we're considering
16:34:16 <dom> ... when you're think about the first sort of buckets (permission-based), it's very easy - we're just tunnelling a protocol
16:34:27 <dom> ... and we prompt the user - this allows flexibility on the backend
16:34:28 <alextcone> +q
16:34:41 <dom> ... it's harder when we do browser mediation, where the browser needs to know what information goes through
16:35:06 <weiler> q+ to ask to what degree are you interested in making it easier for the user to choose an ID not on the list?
16:35:14 <dom> ... 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
16:35:28 <dom> ... it's useful to get that kind of feedback based on specific user flows
16:35:35 <dom> q?
16:35:50 <wseltzer> wseltzer has joined #webid
16:35:51 <dom> ack daniel
16:36:00 <weiler> s/ID/IDP/
16:36:07 <dom> Jeff_Jaffe_W3C: as you noted, this is an amazingly complex area with lots of history and use cases
16:36:26 <dom> ... at the risk of making it more complex: one use case I'm quite interested in is the area of Web Payments
16:36:36 <tantek> vq?
16:36:47 <dom> ... with the Payment Request API we're enabling browesrs to play a surrogate role managing credentials for users
16:36:47 <tantek> ack j
16:36:59 <dom> ... representing identify through UA is becoming increasingly more important
16:37:11 <dom> ... are you looking at these use cases? prioritizing toward them?
16:37:41 <daniel> DID > lookup DID Doc > query service endpoint for payment details > feed it through browser API
16:37:42 <dom> ... 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
16:37:50 <dom> Ken: Good suggestion - don't have an answer for that
16:38:04 <dom> ... I interact with the Chrome payments team, been involved with secure payments confirmation
16:38:06 <wseltzer> rrsagent, pointer?
16:38:06 <RRSAgent> See https://www.w3.org/2020/10/29-webid-irc#T16-38-06
16:38:17 <daniel> (DIDs are kind of like a Rosetta Stone for these use cases, and many others)
16:38:17 <dom> ... we're aware that the problems are similar but in different spaces
16:38:23 <dom> ... but no answer yet
16:38:29 <dom> RRSAgent, draft minutes v2
16:38:29 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/29-webid-minutes.html dom
16:38:37 <dom> q?
16:38:53 <dom> ack alextcone
16:38:55 <daniel> q+
16:39:23 <dom> alextcone: similar question in the mobile web context where you have OS-based sign-ins (e.g. "log in with Apple")
16:39:39 <dom> ... have you looked at that upstreaming of the identity flow when the OS provides support for it?
16:39:58 <dom> Ken: good question - so far we haven't really
16:40:13 <dom> ... I don't know how appropriate it would be a Web API to be trying
16:40:26 <dom> ... making a universal Web API, we have to be careful to tie to specific platform capabilities
16:40:33 <tantek> vq?
16:40:35 <dom> ... I don't know if there is a general from the platforms that could help us there
16:40:55 <dom> alextcone: maybe having something around risk mitigation for the browser and the delegation API
16:41:14 <dom> ... e.g. if the OS doesn't let you have the mapping between OS and RPs
16:41:41 <daniel> This alludes to the fact that we need a substrate for user IDs that transcends any UA layer
16:41:44 <dom> 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?
16:41:52 <dom> ... there is a case to be made that this would be true
16:42:02 <dom> ... we've been focused on shorter term considerations
16:42:03 <tantek> q+ 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
16:42:08 <dom> ... it needs to be part of a much broader discussion
16:42:08 <dom> q?
16:42:25 <dom> weiler: thank you for bringing this up and pushing this
16:42:35 <dom> ... I appreciate you're prioritizing RP tracking
16:42:55 <dom> ... how prioritized would be IdP choice? this could also help with RP tracking indirectly
16:43:04 <tantek> weiler is getting at a very good specific example of the power dynamic / disparities that I'm getting at. thank you sam
16:43:11 <dom> Ken: we've been making this out of scope (as part of the NASCAR problem)
16:43:18 <aschlosser> q+
16:43:30 <dom> ... if you can vary the IdP, that would be another approach
16:43:35 <dom> ... I can't say we've looked at that
16:43:44 <dom> weiler: I'd like that to be in scope here
16:44:13 <dom> ... 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
16:44:14 <pchampin> +1
16:44:26 <dom> ack weiler
16:44:26 <Zakim> weiler, you wanted to ask to what degree are you interested in making it easier for the user to choose an ID not on the list?
16:44:27 <tantek> +1 weiler
16:44:37 <dom> daniel: what do you see the intersection with strong auth, fido?
16:44:37 <wseltzer> ack daniel
16:44:38 <weiler> s/ID/IdP/
16:44:47 <dom> ken: they're a little bit orthogonal
16:45:08 <dom> ... authentication is only a piece of the flow - you authenticate to the IdP who can then assert they've verified your identity
16:45:13 <dom> ... I think they're complementary
16:45:26 <dom> ... stronger auth makes the assertion stronger
16:45:52 <dom> ... preserving federation helps with adopting stronger auths, since IdP have adopted it and are more likely to do it than RPs
16:46:06 <weiler> q+
16:46:20 <dom> Dan: we're working with OpenID on DID sign up, for decentralized identity
16:46:29 <brent> brent has joined #webid
16:46:41 <dom> ... I hope we're working toward a system where users wholly own their identity
16:46:57 <dom> tantek: thx for the presentation
16:47:00 <brent> +1 to making sure there is support for DID-based solutions
16:47:09 <dom> ... people have already touched on important issues, in particular sam's questions
16:47:25 <dom> ... I wanted to bring the question of power disparities between users, RPs, IdPs
16:47:44 <dom> ... How does the design of Web ID seek to alter these dynamics? who should have agencies over what in your spec?
16:48:02 <wseltzer> s/agencies/agency/
16:48:05 <dom> ... if it's not asserting, I would encourage you to look at what dynamics it creates
16:48:26 <dom> Ken: we're trying to promoted directed idnetifiers which give users better control of their identifiable information
16:48:50 <dom> ... I think you may be asking whether this can be used without a centralized IdP, which we're not really looking at
16:49:09 <dom> Tantek: well, one question is what choice users have if only 2 or 3 IdP get offered to the user
16:49:24 <dom> ... what agency users have in picking their own IdP to have actual federation?
16:49:34 <weiler> tantek++
16:49:36 <dom> ... we have to confront the power disparities
16:49:55 <dom> ... and have a stance on them, on whether to change or disrupt them
16:50:06 <dom> Ken: that's not our explicit goal
16:50:12 <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
16:50:15 <daniel> 1+
16:50:18 <daniel> oops
16:50:18 <dom> ... it has bearance on some of the trade offs
16:50:19 <daniel> q+
16:50:36 <dom> ... when we're trying to change the protocols, adopt new paradigms, we should be asking this question
16:50:40 <dom> q?
16:50:41 <daniel> We have long needed to modernize the protocol handler portions of the browser
16:50:49 <daniel> this may be a good opportunity to do so
16:50:50 <wseltzer> ack tan
16:50:50 <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
16:50:53 <Zakim> ... to, amplifying (or inverting?) existing disparities
16:50:55 <wseltzer> ack asch
16:51:10 <dom> aschlosser: thanks for the presentation - I think we had a lively discussion on github on the different trade-offs of the various proposals
16:51:25 <dom> ... it's going to be challenging, e.g. when you look at cross-device scenarios
16:52:13 <dom> ... the aim is also about classifying traffic for IdP from others to provide different primitives to protect from covert tracking
16:52:24 <erynrwells> erynrwells has joined #webid
16:52:48 <dom> ... 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?
16:53:03 <dom> Ken: that's what we're trying to look at indeed
16:53:21 <dom> ... 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
16:53:31 <dom> ... some of the specifics of that depend on where the primitives go
16:53:46 <dom> ... there is a lot of ongoing discussions in how to make the Web more privacy preserving
16:53:57 <dom> ... which would impact the particular direction we would need to take
16:54:35 <dom> 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
16:54:39 <jeffh> jeffh has joined #webid
16:55:00 <dom> ack weiler
16:55:15 <dom> weiler: going back to fido/webauthn - I think there are more related than you think
16:55:28 <dom> ... WebAuthn solves the privacy problem by preventing RP tracking
16:55:33 <dom> ... it has its own challenges
16:55:45 <dom> ... but maybe to solve RP/IdP problem, we need to move everything to WebAuthn
16:55:57 <dom> ... I think we need a clear story for Federated?
16:56:11 <dom> aschlosser: WebAuthn still needs an account to authenticate against
16:56:36 <dom> ... IdP can use WebAuthn to remove the password
16:56:54 <dom> weiler: you can create an accout with just a WebAuthn credential
16:57:04 <dom> Ken: this is a bit off our mission - it's a great question though
16:57:11 <weiler> s/think/described/
16:57:21 <dom> ... would that be ideal world, with no need for federation?
16:57:24 <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/
16:57:27 <daniel> DIDs solve for this as well
16:57:35 <cpn> cpn has joined #webid
16:57:42 <dom> ... there are questions about backup for these auths, which lead back to a service to manage this
16:58:03 <dom> ... it's possible to envision a future that have these properties
16:58:25 <dom> ... signing-in and authenticated have been approached together but they probably benefit from being dealt with separately
16:58:25 <weiler> q+ JohnBradley
16:58:31 <dom> ... but this sounds longer term
16:58:44 <dom> ... but in the meantime, federated identity is far superior to have user/password on every web site
16:59:04 <dom> ... so we want to see how to make it continue to work as the web is getting more privacy-preserving
16:59:08 <timc> +q
16:59:10 <dom> ack daniel
16:59:33 <dom> Daniel: having the ways for IdP to promote themselves to the RP when they integrate this new flow, this owuld help
16:59:33 <stpeter> stpeter has joined #webid
16:59:47 <dom> ack John_Bradley
16:59:51 <weiler> ack Joh
17:00:05 <timc> -q
17:00:10 <dom> John_Bradley: as one of the authors of OpenId COnnect, we're looking at self-issued IdP
17:00:27 <dom> ... the identifiers for that IdP will be changed to also include DIDs of several flavors, but not exclusively DIDs
17:00:37 <dom> ... having lived through the history of account choosers and open@@@
17:00:52 <weiler> s/@@@/YOLO/
17:00:53 <Alan> Alan has left #webid
17:01:00 <rhiaro> rhiaro has joined #webid
17:01:16 <dom> ... 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
17:01:26 <daniel> Really can't be out of scope, unless we want to engrain the relative status quo
17:01:29 <dom> ... for enterprise IDPs, research & education - logging out is actually a harder problem than logging in
17:01:39 <dom> ... a solution that doesn't allow for session termination won't be a complete solution
17:01:54 <dom> ... I look forward to having more discussions with the Connect WG, the FIDO & WebAuthn WG with this group
17:01:56 <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.
17:02:05 <dom> ... to come up with a more fulsome solution
17:02:31 <dom> ... Clearly we need better instrumented APIs in the browser to help solve the risks of browsers breaking them as they stop invesive tracking
17:03:11 <tantek> thank you kenrb for presenting & facilitating
17:03:18 <wseltzer> present+
17:03:23 <dom> RRSAgent, draft minutes v2
17:03:23 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/29-webid-minutes.html dom
17:07:20 <timc> present+
17:14:54 <pchampin> pchampin has left #webid
18:31:26 <erynrwells> erynrwells has left #webid
19:03:47 <stpeter> stpeter has joined #webid
19:08:12 <Steven> Steven has joined #webid
19:08:27 <brent> brent has left #webid
21:04:34 <Zakim> Zakim has left #webid
23:31:31 <jeff> jeff has joined #webid