- Sarven
- Matthieu
- Henry Story
- Pavlik
- Adding meeting notes from 2021-02-25 -- (2 minutes)
- Web Credentials meeting next week
- PR #125: Http Sig extension for Credentials and DIDs: (10 min)
- Raise questions / feedback to #125 (All) ✅
- mv master main branch.. (Aaron) ✅
- Gather implementations: https://github.com/solid/authentication-panel/issues/128 (All) ✅
Approved
Meeting with the W3C Credentials CG March 10th: 15:00 UTC & 18:00 UTC.
The Self Sovereign Identity by Manning helps figure out the links between different specs and build a holistic view of identity, Henry recommends the read.
Self Sovereign Identity https://www.manning.com/books/self-sovereign-identity
Http Sig Original branch at PR is 125
Sarven: It's a good continuation of the work. It is not a spec, but helps to integrate a lot of other work.
Elf: Merge but move it to the proposals directory
Henry: ok.
Sarven: All panels have proposals directories, Pavlik's suggestion makes sense.
A place to document implementations issue 128.
Sarven: If parts of the specification have specific roles they would count as an implementation by themselves. Do Pavlik and Dimitri have implementation work underway? Aaron has.
Pavlik: Can't commit to implement Solid-OIDC. As there are issues with Authorization that need to be worked out. [see below] IdP, Resource Server & Client would be the three main "roles" in regards to implementation - spec.
Sarven: Proposal 2 Actions:
- The spec should have a conformance section and list all those parts (IdP, Resource Server & Client) -- done: https://github.com/solid/authentication-panel/issues/133
- Edit issue 128
Henry: Show on the front page README.md a link to issue 128 under "implementations", that link can later be changed to the final "implementation" document.
Elf: We need to Clarify how Authorization works with IDP.
Henry: How to signify to the Client which credentials can be used to access a specific resource? Can we use a URL eg </grp/Sdssdsd> with an opaque group name, where that group has an ACL allowing only members of that group to access. See
Elf: mentions the point he has made before of how Solid-OIDC spec does not allow the client to have a number of credentials to be used for different origins.
Henry: Yes, I remember Elf making this point a year ago a number of times when Solid-OIDC was being speced out. I was not in a position to make a call on that, as I was not in a position to implement OIDC.
Henry: These two panels (authorization and authentication) connect exactly here: use case: privacy minimal credential disclosure & requirement for the client being able to work out what credential to present. See also Nascar Flag problem which is how this appears in the OIDC world: a relying party has to present a number of icons for the humanuser to decide which IDP to use. Our use case though pushes us towards each Pod being also an IDP, and apps jumping around from Pod to pod to collect the data, each one potentially knowing the user under a different ID. We would need an OpenId type login box to allow the user to enter the credential. For our use case then, a human won't be able to remember which ID is required on which Pod. (I already have trouble remembering on some web sites which one I used) So we need a machine readable answer to the problem, so that agents can make these decisions for us and avoid authentication pop-up fatigue.