- Henry Story
- Aaron Coburn
- Dmitri Zagidulin
- Matthieu Bosquet
- Sarven Capadisli
- Justin Bingham
- Adding meeting notes from 2021-03-01 -- (15 seconds)
- Possible adjustments to meeting time
- Any discussion/follow-ups from last week’s W3C Credentials WG meeting
- Http Sig History missing (3 minutes) - what to do?
- Scope discussion
- Our use of the webid claim in Solid-OIDC and how we can best support DIDs
- Clarifying specific areas of overlap with AuthZ #145
Adding meeting notes from 2021-03-01 -- (2 minutes)
Todo - adjust date
EU and US times are not aligned for the next two weeks. Let's keep authentication panel to 10am ET since the only known conflict is 11am ET.
Http Sig History missing (3 minutes) - what to do?
Git blame shows all contributors. Resolved.
Aaron: The biggest overlap might be DIDs. If you think about the venn diagram, there is a lot of common interest. Having more interaction ____
Dmitri: The confidential storage, then CCG call would be most useful. They are weekly.
- https://github.com/decentralized-identity/confidential-storage/
- https://lists.identity.foundation/g/sds-wg/wiki/18887/94176
- https://lists.identity.foundation/g/sds-wg/wiki Matthieu: See also https://w3c-ccg.github.io/meetings/
Dmitri: it is good to join the CCG mailing list as the agendas for meetings appear there. https://www.w3.org/community/credentials/2020/09/
confidential storage group (encrypted data vaults + identity hubs) - https://identity.foundation/confidential-storage/ (that's the spec) github: https://github.com/decentralized-identity/confidential-storage/ this one: https://lists.identity.foundation/g/sds-wg/wiki
Aaron: Requesting a specific scope of "solid" seems to be more in line with what OIDC does. It would require an extra burden for the client, but it doesn't seem too cumbersome.
Elf: Would it be sufficient to have a webid claim to match what is in the access token's audience claim?
Aaron: When you request the scope, then the ID token and the access token would include that claim and if you don't, it wouldn't be there. It's what happens with email claims for example.
Dmitri: I think requiring a scope is a good idea, it sounds like a decent way to work with the mechanism.
Aaron: Can we get feedback/concerns about client tooling for example?
Henry: we could put a note in the spec linking to the issue so that people can be aware of the question we are asking.
Matthieu: Spec level changelog? Would it be good to have those for all the Solid specs
Aaron: I've seen it in other specs and it is useful.
Sarven: It's specifically useful if you have significant snapshots of the spec (WD, CR, PR, ...)
Henry: Could we use the git history?
Aaron: There's a lot of info in history, it will be there among people fixing less significant things.
Aaron: How to best support DIDs? Right now we have a webid claim and we'd like to support dids. Even though the WebID says it must be an https URL, we sort of signal it could be a DID. We could be more specific and rename the claim to solid. So that would be future proof for supporting VCs, DIDs...
Dmitri: +1 to Aaron's suggestion to have a general solid claim that specifies both WebID and DID.
Matthieu: +1 to Aaron's suggestion.
Justin: That makes a lot of sense.
Aaron: I spoke with Ruben V. last week and he was very supportive, he suggested making the value space for this claim IRIs.
Henry: The problem remains which DID should we support? This was the question Ruben asked initially on the Support DID issue. One could argue that WebIDs could still be extended to cover DIDs. Indeed the WebID group considered for a long time covering more than https URLs. But we ended up adding the limitation in order to help move the WebID XG draft spec forward. After all: DID took another 7 years to mature.
Justin: I like the suggestion of IRIs. To the point that Henry brings up, which URIs would be supported? Could be specified in the spec. Like say did:web is a must, and overtime the protocol spec could expand to different methods. If we have a range of IRIs, we would never need to change after that.
Henry: did:web is just https. Maybe I'll flag a potential simplification in the spec. The server should be able to explain which DIDs it supports with a minimum of http WebIDs.
Dmitri: There is a reason for the extra did:web to https complications :)
Henry: will need to understand that.
Elf: IdP client RS if some of them only support webid https and others did:web and others more, we need a way to make it explicit. It's useful if the client can say I only support https, don't give me did:web. We should consider all the drawbacks. Know what to expect in the token.
Justin: If we were to take the proposal, what's the worry
Elf: Client support only https the client give webid, gets it and then comes the response. If the client got a did:web, it can't get the info it needs. We need to ensure there's a response with a supported protocol for all parties. Maybe it's not a problem but we should consider and think it through.
Henry: I think the same problem applies to HTTPSig I've left it open for key IDs but for credentials I would leave it open. It's kind of content negotiation on URIs.
Matthieu: Are there any specifics at the authentication protocol level for the different kinds of DIDs? Will they all be compatible with Solid-OIDC?
Dmitri: The DID community is specialising on the https://identity.foundation/did-siop/
...: They're trying to centralise on DID authentication protocols. The couple of protocols that there are involve a wallet-based authentication and the self-issued OpenID Connect (OIDC).
Sarven: Wait for maturity for requiring did:web on the Solid protocol level.
Dmitri on Gitter: DIDs have been in W3C WG for about a year now, and they're going to CR either this week, or this past week.
Sarven on Gitter: we are not talking about DID in general... but did:web specifically at the moment
Dmitri on Gitter: +1 agree with Sarven. tho obviously I'm a fan of DIDs, the Solid community needs to get more experience with them, etc.
Justin: What constitutes maturity? If we were to compare DIDs, for example did:web and WebIDs, would there be a big maturity gap?
Sarven: There's a reason why the Solid ecosystem started with WebIDs, replacing WebIDs with DIDs would be premature. They can be compatible and extended.
Henry: There is a reason for WebIDs: HTTP GET PUT POST DELETE using Solid protocol is really mature. You have servers for HTTPS, all you need is a GET and an RDF library. DIDs are more experimental. We should analyse per case.
Aaron: 1 minute left.
...: Long detour on DID protocols. The initial suggestion is not which protocol to support, but do we need the door open to extend support for any kind of such identifiers in the future? Just how would one be able to implement this? Likewise with VCs. By boxing ourselves with WebID, it's pretty narrow; by using "Solid", we're very open to the future.
From Gitter: https://gitter.im/solid/authentication-panel?at=604f75c9823b6654d2aa04a1
justinweb: so i think aaron’s proposal leaves the door open without committing +1 for solid claim, +1 for IRI
bblfish (henry): +1 for leaving the door open, but if we leave the door open, we should specify how extensions are going to work.
matthieu: +1 to leave the door open, +1 for solid claim, +1 for IRI
elf: +1 to keep it open, preferably with explicit discovery / negotiation
csarven: Proposed Action: Rename to solid and IRI range. Solid OIDC editors to document interop re diff IRIs
Aaron: I'll open an issue on the authn panel and point people to it.