Meeting minutes
Introductions and announcements
Action items
acoburn: only action item is weekly overview of use-cases, are there any closed issues?
hadrian: No, there are no closed issues. There is a closed PR; with a lot of changes from Pierre Antoine resolving glossary terms and linking to various parts of the document and removing external references
<acoburn> merged PR
<gb> MERGED Pull Request 145 add cross-link to glossary definition in the glossary (by pchampin)
Discussion: Authentication and related use cases
acoburn: We have been having an open-ended discussion around portability. There will be more conversation, but we have have a general sense of the scope. We don't want to add a requirement that will prevent portability (e.g. requiring that all resources are HTTPS URLs).
… : We now need to move on and discuss other areas - starting with Authentication.
… authentication is how you validate the identity of an entity (user, agent application etc.)
… there are a number of use cases around authentication, e.g. #51 passkeys, #41, and #39 and #40 are about browser authentication. #90 and #147 are also about attestation of client identity
<gb> Issue 51 not found
<gb> Issue 41 not found
<gb> Issue 39 not found
<gb> Issue 147 not found
<gb> Issue 90 not found
<gb> Issue 40 not found
acoburn: there are two requirements (127 and 128) which are about identity providers and service providers - and the requisite trust for these providers
… there are 3 high level things in all of this. Browser based authentication, non-browser authentication, and common to both: how one proves an identity is to be trusted
… historically in Solid, there was WebId-TLS which was more of a server-server mechansim. There were a lot issues which made this challenging to use
… today most Solid servers use some version of OIDC which is well defined and much wider than Solid
… the Solid CG produced a specification called Solid OIDC which defines a mechanism for making use of OIDC in the context of Solid. It describes how identity validation happens
… OIDC works well for a browser context. I suspect that when we talk about authentication in the browser, OIDC will be a significant part of that. It falls apart when we talk about server-server communication.
… I've tried to get OIDC working for server-server communication, it sort of works, but not well
<Zakim> ericP, you wanted to ask how openid fails in server-to-server
acoburn: It is also worth noting that there are also a number of other specifications for authentication like SAML and GNAP
ericP: Mechanically what goes wrong with OIDC server-server authentication
acoburn: OIDC is based on OAuth2. You can do server-server communication fine in OAuth2, but OIDC is all about one particular flow in OAuth2
… which is about interactions in a browser
… so doing this outside of a browser is uncomfortable at best
<Zakim> hadrian, you wanted to ask about scope
hadrian: Authn and AuthZ are fairly complex. I assume we don't want to tie ourselves to a particular AuthN spec, or boil the ocean.
<bendm> +1 on Hadrian's comment
hadrian: so can our requirement be that we turn up to the resource server with some kind of token and not mandate the authN spec by which that is obtained
ericP: The question of whether it goes in the spec is more editorial
… when we introduce profiles in specs, it creates complexity and people tend to resist
… so in our context, say we are offering an Identity server that OIDC and another uses SAML, and we want a resource server that works with both of those; then we'd want to define ???
… the question of whether it is orthogonal or not depends on whether ???
dmitriz I agree with everything that Aaron said. We want the least amount of choice for implementors. We also want upgrade paths as new AuthN protocols come along.
… the most impactful thing this group can do is say here are the requirements that an authentication mechanism needs to have (identify the agent, identify the user, work well with delegation, whenever possible support a dereferencable metadata document like a WebID).
… that gives flexibility for implementors evaluating the criteria to work out if it fits
<Zakim> kaefer, you wanted to ask about webid+tls
kaefer3000: WebID+TLS have gotten bad press largely because of the way a particular browser implemented it, so I wanted to encourage a more neutral stance on that specification
… If I have time I can find a piece describing this
dmitriz: I know the opinion piece justifying WebID+TLS. I would encourage this group to ignore it because all browsers have dropped support
kaefer3000: If you supply your browser with a certificate it works perfectly
dmitriz: That doesn't really work well right now
kaefer3000: The UX may be bad, but it is implementable
acoburn: The positions are well laid out. I don't want to get into the nuances. As it currently exists, it is very hard from a user perspectives - but there are interesting parts of it that may be useful for server-server authentication. As a browser protocol it has severe limitations
csarven: I agree with acoburn and dmitriz, but there are also some parts of WebID+TLS that we can pull out. If I recall correctly they were also trying to do authentication on the wrong layer. The Technical Architecture Group wrote a draft Finding on this in 2015, the associated repo is now being archived https://
HTML5.
… I like the approach, and think it is efficient, but I'm not sure how smooth this thing can be
… we also have things like HTTP signatures which hint in that direction
<Zakim> gibsonf, you wanted to say that having defaults that all LWS servers will support will enable any application to work at minimum with default
gibsonf: For these kind of decisions, it would be great to have the lowest common demonator of requirements that will be a MUST to make sure there is at least a way of all apps working with all servers
<Zakim> csarven, you wanted to mention more specific limitations of (Solid-)OIDC in the browser in the context of a "decentralised" ecosystem
acoburn: The tightrope we all there is that we don't want to require something that is insecure or deprecated, but we do want to allow some level of interop
csarven: My understanding of OIDC and SOLID OIDC in general is that when we are talking about the browser and web platform; it is important to distinguish the aspects we are talking about within the context of the Web Browser. We have the application layer, things that are native to the Web browser, and the extension layer. This all happens within
the desktop or mobile browser. In Solid we have a URI which is bound to where they started off and where they are redirected to when authentication finishes.
… this breaks when we have extensions which want to be statically registered
… as users can trigger extensions on any web page
… so the user will not be able to get back to where they started off in the extensions as the IDP will not be aware of it
… so there are things in SOLID-OIDC today which do not work well in the browser either
… in dokeli it doesn't seem like static registration will work out - as dokeli can also work as a browser extension
… so we should be careful about how we select the kind of use cases that we want to enable
… e.g. I cannot annotate web pages via a Solid-OIDC's static registration with a browser extension
acoburn: It comes down to how one can identify an application, and whether this is ephemeral (e.g. dynamic) or ongoing in the case of static client
jeswr: re WebID+TLS, my understanding of the new WebAuthN (w/ Passkeys) provides a similar set of features
… that's not to say that we should require it, but we should be able to use that
acoburn: I am a big fan of passkeys, and what we do should not get in the way of that
<dmitriz> (very different functionality, unfortunately. (passkeys vs webid tls))
hadrian: When it comes to scale, we cannot assume all providers will use the same technology. Some adaptation needs to happen in the infrastructure which is a detail that we will need to account for later
acoburn: We have largely talked about browser-server interactions so far. OIDC is one answer to that. There are and likely will be others. I want to leave the server-server conversation for next week.
<csarven> s/dokieli/dokieli ( https://
acoburn: there are existing solutions for server-server Client Credentials, emergent solutions like HTTPSig, and a range of other solutions e.g. DIDComm
… today none of that is within the Solid CG specifications
… We need to get shared context of our scope, and understand how we will approach that in a tractable way in the context of the specification
dmitriz: On the difference between passkeys and webbed tls
… WebID tls was cross domain, the identity stays the same across all services. I.e. my identity dmitri.com can stay the same across all websites I visit. A key generated by a passkey, unlike a WebID certificate is generated by a browser and narrowly scoped to the domain I am authenticating into.
… Note that passkeys refer to WebAuthn plus platform-mediated key replication e.g. where google and apple replicate the keys across devices
… The authors of the spec narrowly meant it to be a replacement for username and password for a single server
… I agree with acoburn, it is an important tool in our toolbox, but can't replace WebID+TLS
acoburn: We should also keep in mind the various architectures that people will have when writing applications. Everything from (1) a single page application - which cannot effectively manage secrets over the course of their lifetime, (2) a frontend to backend architecture where your application talks to a backend which talks to solid server (3) a
… native app, where it is possible to manage secrets securely (4) a server-server interaction with an automated system or bot (5) server-server where the server is acting on behalf of a particular agent; e.g. refresh tokens in an OAuth2 context
… we can't look into the crystal ball to know what the next auth architecture is going to be. But we don't want to make it hard or impossible to implement
hadrian: For this reason I don't think we should try and find the best solution - this is a fools errand. I would rather spending the time focussing on interoperability.
acoburn: Rather than specifying which authentication protocol should be used, we could instead define which token should be used to access a secure resource (e.g. it should identify the user, it should identify the application). Then in a separate document we could then say how that would play out with OIDC and other protocols
Use cases update
hadrian: With use cases my plan is to be done by the end of the month for categorising. I am almost done, there are some branches I am creating PRs for.
… there are several use cases that took time to decide what to do with because they are broad
acoburn: Next week we may want to continue discussing server-server authentication. If UCS is ready for review should we focus on that instead?
hzerbaca: We didn't discuss how we feel about local-first, and other things
acoburn: Hadrian, is there anything that this group can help out with, in the meantime? or wait til PRs come and review at that point?
hadrian: no, not at this point
… I appreciate the conversations on this topic, and group should continue
… another thing that was asked by other people (PAC?) is how do we start making progress on the Protocol Spec per se
acoburn: yes. first step, we make sure we have a clear Use Cases and Reqs doc that we have consensus on
… then basically the chairs will need to identify some editors
… who will then go forth and begin writing spec language to encapsulate answers to the requirements
… Eric, anything you'd like to add?
<csarven> s/dokieli\//dokie.li\/
acoburn: (eric's offline). Hadrian, anything else about Use Cases update?
… any other business to discuss?
… then I think we can end a few mins early