No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
If this is your first time, welcome! please introduce yourself.
Scribes
Virginia
Huw
Introductions
name: text
Topics
SC: Today's topics are intended for awareness and build engagement as opposed to solving technical details here.
SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed, as it stands).
Inconsistency in identifiers for apps: WebIDs and ClientIDs
TH: We're running into this issue where customers build apps, for each of these customers apps we provide both a WebID and ClientID, running into issues because as we use them now, there are two separate identifiers for the same thing (app). If they're referring to same thing, we wonder if we could merge them. They currently contain inconsistencies, some examples are in the issue, I can elaborate.
SC: More detail would be great.
TH: Specs state WebId is used as primary identifier for both users and apps. Apps are currently identified by both. Several issue: interop spec 7.1.2, an endpoint is defined for agent ??? discovery, as an app you should be able to discover agent registration by doing a ??? to an endpoint, token point to app WebID should retrieve agent registration, but in the registries of interop spec it is implied that ???. Example: assuming they mean the same thing, if semantic nuances, then this issue is irrelevant. If they mean the same, thsey should be merged or some other solution to go from one to the other and vice-versa.
eP: In the implementation of authorization agent (SAI) I used them as the same identifier. Publish as a ??? id to fit solid-oidc requirements, but it doesn't validate WebID spec in any way. We probably need to reconsider to change from JSON-LD to ???
AC: Important thing is client ids are use for authn, webids are used to describe things, you can do this in same doc, but they are two different things and different URIs. I encourage to separate them, or considering it a common use case. OIDC is a JSON world and Solid is RDF world. Client identifiers in open id connect have to json. There can be other methods, and you can use them, but OpenID Connect has to be JSON. IF doc can respond to json in expected format, and also respond by content negotiation to the RDF format you can also that, but I encourage to keep separate.
TH: They are used in two separate ways, but these are practical consideration. I do believe semantically they do identify the same object, so they should be merged. We should find a way around the practical considerations, but main question is: do they refer to same entity or not?
AC: They are different semantically.
TH: Elaborate?
AC: WebID defines an agent (person), and then you go down the chain of delegation. A physical person identified with wa WebID might be using a browser, which is using an agent ??? solid app, which is different, and that solid app might be delegating to another solid app. But client_id is identifying the client, not the user. If I am a user (person) I'd have a client which would be identified separately. If I have a client like a robot acting on its own behalf, it is possible for the client to identify itself, and the WebID and CLient identifier re unified. In this case WebIDand client ID can be used for authn and description. Even if you unify, they do radically different things, so I caution against it.
eP: In the issue I pointed to one possible approach: client ID is OIDC specific and can be isolated to that interaction. Solid global application WebID could be mapped both ways. OpenID provider, based on what it finds on Entity Statement based on client ID URI, for Authorization and other Solid components the application WebID can be used instead of client ID which is specific just to OIDC.
HS: You can think that an app ID is a subset of a WebID. They are still two different things. Agree with AC that you want the app id to be different from your WebID to distinguish between app you're using and yourself. Format for app id should be json, but that's I believe compatible with JSON-LD. In both cases the same logic applies to WebID (we have a URL that denotes an agent). You could say it's a WebID if you wanted to, but have two WebIDs one for the app and one for the person. In the end, both will be WebIDs. If the problem is that the WebID spec specifies Turtle, then I would not let that be a blockage. We could change that spec to allow JSON-LD too. If it becomes widely used, then it can be put in the spec. (We just don't want to start requiring every RDF format to be understood by the server) Two ways of going at things. We need to be careful of getting stuck in discussion.
TH: I can elaborate. We are running into this in a practical way when trying to implement interop spec, so we need to solve. Flemish gov is treating it same as us (merging). I don't see a big difference between the two. For a client they're the same. Only difference is the format because of OpenID Connect, but besides that I don't see them being different things aside from practical implications.
MB: Another way to look at this: how do we arrive at asserting that someone is using a certain client? We use an existing mechanism to asserts agent identity and client being used is really what is claimed. From a Solid POV, client corresponds to an OAuth 2.0 client and to OpenID relying party… many ways to refer to the same concept… more information can go in there from authz POV, for example the User-Agent (e.g. browser) could matter. But the root of trust remains the one agent with access to a resource and we need to assert in a safe way the client used is the client it claims to be, and we do that via standard OIDC, but with a URI which needs to dereference to a json doc. I don't think we need to discuss the semantics, the separation of agent and client is well-known. It seems important to not rabbitholing into creating a new protocol for client or ID assertion, and just say client is an important type of restriction, and that claim is asserterd via standard OpenID connect.
KK: Question to AC to describe relation between webid and client id. clientid is the final artifact in delegation path.
AC: correct.
AC: From a different perspective: interoperability and solid into the larger ecosystem of technologies. we are building on existing technologies and protocol. for authn oAuth2 and openId Connect, so we need to play that same. That's how client id comes in. OpenID Connect doesn't care about WebID. Probably never will. We need to play those games, unless we wanna invent our own authn mechanism we need to play by those rules: json, clienids, and identifying apps in this way. Only mechanism they have for app identification. This is why they should be distinct identifiers. Because we allow client ID to be jsonld, you can interpret that as a full webid, turtle, but OIDC Federation specification describes in broader way same thing with solid-oidc client id: we can remove the whole client id from solid-oidc and use oidc federation. Haven't made a decision but looks good. Using something broader and bigger. If that happens that is pure json. So I encourage to keep separate, conflating is trouble in long term.
HS: I wonder what the Reason is that client identifier and WebID are found to be the same in the government use case. Is it because gov is assuming you will be using only this one app. HTTP signature: you need a client identifier, has a much bigger role, in oAuth client gets a token that can be passed on to anybody else. Perhaps less important in other systems.
TH: Ultimately comes down to the question: do we want to drop traditional OIDC support or not… If we do not care about traditional OIDC support, we could require an accept header. However, this should not be presented as a false dichotomy as we are talking about simply requesting an accept header whilst we're making a request to this document. We can still use OIDC, but we won't be compliant with traditional OIDC, that's true.
eP: Invite everyone to follow up on the issue. If we go with OpenID Connect federation rest of ecosystem can use App WebID resolving to WebID Document, while OIDC uses client_id resolving to Entity Statement (which also states the App WebID).
SC: Let's continue discussion in the issue. We can have an action to follow up. If you feel it's worth clarifying sign up to an action.
KK: Auxiliary resources have been with us in the form of ACL files and .meta files for a long time. There's a use case around redirect ??? and they share general characteristics. ACL files are attached to lifecycle of resource, whereas ??? are not deleted when resource is deleted. We should be looking at these use cases ??? if we combine these characteristics you have an auxiliary resource of a certain type. You can see the issue, and all the issues grouped by a tag on Github. There are many things with common characteristics, and settling this aux resource is something we should focus on.
SC: +1, we should hash out and consolidate common parts of aux resources.
AC: (on Jitsi chat): "Validation" as an Auxiliary resource too.
MB: +1
eP: Question: status about capturing creator of a resource?
SC: There is an issue, "define creator", is a call for implementations. We need implementations to know things are real, tangible and workable.
SC: This topic comes up a lot. Auxiliary resources and how to work that through. Whether they are discoverable as part of containment or not, through a resource but not containment… there are questions where we made assumptions early on, and not written in stone so if we have different view on storage we can revisit.
KK: https://github.com/solid/specification/issues/191 for basic resource types. Most interesting part of this exercise is getting to the commonalities: what kind of properties the different things are. So that we can build out a new type based on the dimensions that are defined that server implementations and clients can relate to. You can go to description document snd see that a resource is append only and server managed, so server only accepts that.
HS: Do we know what TBL thinks about this? This is quite fundamental aspect of how a server should work and I'd like to know what his intuitions are.
KK: I don't know. There are several kinds of aux., resources that were in original solid design, acls, .meta.. back in the day it was index.ttl, used to ??? data in a container. That would be an auxiliary resource. Talked about problems with sever-managed timestamps, and it is problematic to update container with this because changes all the way to the root. He expressed being open to the idea to have that. I think this is something he'd be looking at favorably.
KK: Given how many things need aux. resources, we should discuss.
SC: Issues come back. Whether we should enable apps to set how URI persistence and representation are managed. Proposals in the community dealing with redirects. We can dedicate a part of a meeting to review the category of those issues toiuching on aux. resources. If this is something that if we solve that we can solve the other issues.
SC: Adding a licence or referring to it in our specs. One way to do it is link to a licence doc (MIT), with information about the entity that had copyright and licence/rights others have. Other way is specifically indicate entities in the document, and so on. IANAL, any lawyers in the room?
SC: There is a PR…??? to point to HTML/RDF document using the MIT licence still but ??? because right now we only link to template. The PR is saying: include the Solid CG in that document. Thoughts? Invited to comment the PR, and your lawyer friends.
eP: There's licence.md which is the Github boilerplate based is the goal making an hTML version of this? from legal point no difference between .md format and HTML. Experimenting with HTML and diverge a bit from GitHub default. I don't understand the point of the exercise.
SC: Main point is when you go to GH and look at MIT licence, the licence does say current year and w3c communituy group. In specs, what they link to, it's just the template. Doesn not include years or entity that holds right. Difference between what's ion GH and what's on specs. We have the ability to include rights information about our specs if you want to extend.
HS: Does W3C already have this?
SC: There are contributor licences, but they're not for the docs that we publish. If you're working on the WG setting there is patenting: https://www.w3.org/Consortium/Patent-Policy/ . That is clear. Whoeever holds the rights indicates the licence.
KK: Licencing we do is to grant rights: if you have not been granted rights to spec, you can't make copies, etc. That makes me think (and IANAL) that if anybody has a problem with the way that it says MIT licence ??? shouldn't they speak up? Because it does say MIT licence on the doc. From a non-lawyer perspective that seems good enough. If it's not enough and required to because it might not be a valid licence grant not worth paying attention too, since we're not lawyers.
SC: What could go wrong?
HS: MIT is for source code. CC more appropriate for documents.
SC: Yes. Had that discussion. Specs are code and important data we use to drive tests and apps that use the data. It is one component we're we indicate the rights. Issue PR links to is about expressing right.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe