Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 24 10:58
    bblfish commented #315
  • Sep 24 10:57
    bblfish commented #315
  • Sep 24 10:43
    kjetilk commented #310
  • Sep 24 09:02
    csarven transferred #167
  • Sep 24 09:02
    csarven transferred #166
  • Sep 24 09:01
    csarven transferred #53
  • Sep 24 09:01
    csarven transferred #52
  • Sep 24 09:01
    csarven transferred #51
  • Sep 24 09:01
    csarven transferred #168
  • Sep 24 09:01
    csarven transferred #278
  • Sep 24 09:00
    csarven transferred #155
  • Sep 24 08:59
    csarven transferred #300
  • Sep 24 08:59
    csarven transferred #299
  • Sep 24 08:59
    csarven transferred #296
  • Sep 24 08:59
    csarven transferred #295
  • Sep 24 08:58
    csarven transferred #294
  • Sep 24 08:58
    csarven transferred #289
  • Sep 23 12:22
    elf-pavlik commented #315
  • Sep 23 11:11
    csarven edited #315
  • Sep 23 11:00
    csarven edited #315
Fred Gibson
@gibsonf1
It doesn't seem a stretch to add an key/value to /.well-known/openid-configuration end point, like "request_landing_page" which the server could ignore or not depending on the origin or whether server supports that
Aaron Coburn
@acoburn
Here is the situation: there is a vibrant and mature identity ecosystem based on OpenID Connect. To the extent that Solid can use that ecosystem, that will be a win for Solid. To the extent that Solid tries to change that ecosystem, Solid will find itself in a very long and slow uphill battle. Do you really think Solid will get Google to change its identity infrastructure?
Fred Gibson
@gibsonf1
There is no need for anyone else to change anything about the spec or their implementations for Solid to have this option added I don't think?
Aaron Coburn
@acoburn
It just means that it won’t get implemented unless you want to implement your own IdP. And that is precisely what we want to avoid
Encouraging the Solid community to write servers that manage user credentials is exactly the opposite of what we want developers to be doing
Fred Gibson
@gibsonf1
or actually, since registration_endpoint is already there, and we use that for directing to registration, maybe its a key/value such as initiate_registration = true
Does Inrupt have their own IdP?
Aaron Coburn
@acoburn
The only full-blown, Solid-based IdP that I am aware of is NSS. And I for one have concerns about how credentials are managed in that piece of software
Fred Gibson
@gibsonf1
I didn't realize that, so TrinPod then will be the second one. We manage credentials which are encrypted in an index pod for the server which persists in a graphdb. On installing a TrinPod on a machine with the install script (a single script initiation does it) the system installs all dependencies, starts the system, and creates both an index pod for managing the pods on the system and a digital twin pod of the system
there is no access to the index pod of course, other than the internal system itself
(where from a graphdb perspective, pod = a separate graph in the graphdb)
elf Pavlik
@elf-pavlik

or actually, since registration_endpoint is already there, and we use that for directing to registration, maybe its a key/value such as initiate_registration = true

from: https://openid.net/specs/openid-connect-discovery-1_0.html

registration_endpoint
RECOMMENDED. URL of the OP's Dynamic Client Registration Endpoint [OpenID.Registration].

I don't think it has anything to do with user registration

Fred Gibson
@gibsonf1
that is where we store the path to the IdP registration page
elf Pavlik
@elf-pavlik
do you implement Dynamic Client Registration? https://openid.net/specs/openid-connect-registration-1_0.html
Fred Gibson
@gibsonf1
Yes
elf Pavlik
@elf-pavlik
if you use the same URL for Dynamic Client Registration and to show User registration page it seems like peculiar detail of your implementation, to my understanding registration_endpoint only has requirements specific to DynReg
Fred Gibson
@gibsonf1
I'm not exactly sure on that, @roger-perry-gmx was in charge of building that system
Aaron Coburn
@acoburn
I would echo what @elf-pavlik states above. Using registration_endpoint for something that isn’t OpenID Dynamic Client Registration is unconventional
Roger Perry
@roger-perry-gmx
we use the registration_endpoint for dynamic registration only
Fred Gibson
@gibsonf1
I think I have a way to solve the new user flow issue brought up earlier that will make our UX team smile. solid/authentication-panel#46 By simply modifying the redirect-url used for login, we can send information to control server behavior in the query string, such as start=registration
Aaron Coburn
@acoburn
@gibsonf1 using a state parameter would likely be a better fit for OIDC flows. If you encode state information in the redirect_uri, you will need to make sure that the server has all the various permutations of these query paramters, which ultimately is not very flexible
Fred Gibson
@gibsonf1
@acoburn How can that be done with the session.login function?
Aaron Coburn
@acoburn
What is the client.login function? Is that a software library?
Fred Gibson
@gibsonf1
solid-client-authn-js
Aaron Coburn
@acoburn
I would take it up with the authors of that library. Ask them to add support for state parameters. It is part of the OAuth2 protocol
Fred Gibson
@gibsonf1
Thanks @acoburn !
Sarven Capadisli
@csarven
GoodNewsEveryone.jpg

Good news everyone!

We're in contact with the W3C Credentials CG and the chairs are discussing coordinating introductory presentations from each group to each group in order to jump start collaboration -- this will likely happen in February.

Date:
We may be able to put two sessions on the same day with breaks or do it on different dates. February 17 and 24 appear to be the next possible dates; Solid CG has a meeting slot on Wednesday at 16:00-17:00 CET and Credentials CG has its at 19:00-20:00 CET, so we can reuse them or come up with something else that works better.

Sessions:
The format of the sessions will be roughly that each group gives an intro their area / work-items and have a Q&A (exact timing needs to be worked out but assume ~1h for now). Sessions will be minuted and the audio may be recorded. We can arrange future sessions to dive deeper on any topic.

From our end, I propose that we cover our work along these lines (DRAFT - let's update together):

  • Ecosystem (5m): @timbl ( @csarven @RubenVerborgh )
  • Protocol (10m): @csarven ( @RubenVerborgh )
  • Identity (5m): @bblfish ( @dmitrizagidulin @acoburn )
  • Authentication (10m): @acoburn ( @dmitrizagidulin @elf-pavlik )
  • Authorization (10m): @bblfish ( @csarven )
  • Data Interoperability (10m): @justinwb ( @ericprud @joshdcollins )
  • Q&A (10m)

Again, I don't mean to exclude anyone so please take above as just suggestions and if I've overlooked anyone or would like to be more involved, say so. Folks in brackets can jump in.. or alternates if people can't make it?

(Tim, the "Protocol" bit will leave the details on identity, authn/z to others)

Questions:
What questions on the Credentials work would you like answered? We already have some issues documented in some of our repositories but I suggest to create new ones as well. We can compile a list and pass it to the Credentials CG prior to the meeting day. It'll be useful for us to record/track for consideration in the Solid ecosystem. Suggestions on areas we should touch:

  • Identity/Identifiers: WebID, DID
  • Access control / Capability-based security models: ACL, OCAP
  • VC data model
  • Signatures/Encryption
  • All sorts of Security and Privacy Considerations

TODO:

  • Decide on dates. For starters, how does Feb 17 with two session blocks for everyone here? Should we try different slots?
  • Decide on questions.

w00t!

Justin Bingham
@justinwb
@csarven very cool - are others beyond named participants above able to join these as flies on the wall
Sarven Capadisli
@csarven
OH, good that you brought that up. Yes, everyone is welcome. Think of it is as normal CG meetings.. just a bigger circle.
I'll look into whether participants in the call need to join the CGs or not. I suspect that we can all attend as guests.. and respect the common W3C code of conduct / PWE..
Justin Bingham
@justinwb
like join the w3c credentials cg in addition to solid cg?
or at least one
Sarven Capadisli
@csarven
At least one.
Henry Story
@bblfish
Oh, I see. A lot of preparatory work then. :-)
Justin Bingham
@justinwb
cool - i can assist with you and @bblfish on authz if you can add me to that one.
Matthias Evering
@ewingson
@justinwb am inactive member of authn and would like to be fly on the wall
Alain Bourgeois
@bourgeoa
@csarven That is very good news. Hope that it will make solid/specification and solid ecosystem better known and can receive a broader approval.
Dmitri Zagidulin
@dmitrizagidulin
@csarven very cool
Benoît Alessandroni
@balessan
Interested in attending the call at least
Fred Gibson
@gibsonf1
is there ontology for a solid pod user, something like solid:User ? (I'd like to have the various required properties needed for a user use this class as the domain)
Fred Gibson
@gibsonf1
For now we've made 2 new classes
neo:solid-user  --> rdfs:subClassOf  neo:ldp-user  --> rdfs:subClassOf pext:User --> rdf:subClassOf foaf:Agent
the second ldp-user was to capture the ldp:inpox property as common to both ldp and solid users
Sarven Capadisli
@csarven
I don't understand what's needed / use case.
There is http://www.w3.org/ns/solid/terms#account
Sarven Capadisli
@csarven
Oh nm, apparently it is already up. Thanks..
Fred Gibson
@gibsonf1
@csarven I need to have a class that has domain of the property solid:account as well as the other properties such as preference files, trusted apps, type indexes. These I think are properties of the agent using the account, so to declare these properties as a domain of a class, we need a class for a solid user and I think also an ldp user as ldp:inbox would have domain of ldp:inbox, and the solid user would inherit that
solid:User would be nice to have