Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 30 02:07

    elf-pavlik on minutes-2022-05-23

    (compare)

  • May 30 02:07

    elf-pavlik on main

    Create 2022-05-23.md Update meetings/2022-05-23.md … Merge pull request #217 from so… (compare)

  • May 30 02:07
    elf-pavlik closed #217
  • May 25 14:27
    elf-pavlik synchronize #217
  • May 25 14:27

    elf-pavlik on minutes-2022-05-23

    Update meetings/2022-05-23.md … (compare)

  • May 25 14:26

    elf-pavlik on main

    Create 2022-05-09.md Apply suggestions from code rev… Merge pull request #215 from NS… (compare)

  • May 25 14:26
    elf-pavlik closed #215
  • May 25 14:26
    elf-pavlik synchronize #215
  • May 25 14:25

    elf-pavlik on minutes-2022-05-16

    (compare)

  • May 25 14:25
    elf-pavlik closed #216
  • May 25 14:25

    elf-pavlik on main

    minutes 2022-05-16 Apply suggestions from code rev… Merge pull request #216 from so… (compare)

  • May 25 14:25

    elf-pavlik on minutes-2022-05-16

    Apply suggestions from code rev… (compare)

  • May 25 14:25
    elf-pavlik synchronize #216
  • May 23 15:17
    elf-pavlik opened #217
  • May 23 15:17

    elf-pavlik on minutes-2022-05-23

    Create 2022-05-23.md (compare)

  • May 16 14:43
    elf-pavlik opened #216
  • May 16 14:43

    elf-pavlik on minutes-2022-05-16

    minutes 2022-05-16 (compare)

  • May 12 12:06
    NSeydoux opened #215
  • May 04 12:24

    elf-pavlik on main

    Create 2022-04-25.md Apply suggestions from code rev… Apply suggestions from code rev… and 1 more (compare)

  • May 04 12:24
    elf-pavlik closed #213
Justin Bingham
@justinwb
:tada:
Aaron Coburn
@acoburn
I created a HackMD document for the 4 April meeting: https://hackmd.io/YoWe5OuGRB6LLzNayhVhPw
elf Pavlik
@elf-pavlik
I added a link to https://tabatkins.github.io/bikeshed/#metadata-status I think we should discuss which ones are we going to use. CG-DRAFT adds an Unofficial Draft watermark to the background.
Aaron Coburn
@acoburn

I am sort of hoping that the Spec editors could provide some guidance on this; otherwise we just have to guess. Should we use CG-DRAFT / CG-FINAL or rather FPWD / CR / TR? Given that we're operating under a W3C Community Group, the CG-DRAFT / CG-FINAL status values seem the best fit, but it's probably most important to align with the expectations of the SolidProject conventions

/cc @csarven

Sarven Capadisli
@csarven
I'll join the call later. THanks.
Sarven Capadisli
@csarven
I'm reviewing the Solid OIDC PRs (on solid/specification) but not ready to submit. I'll make sure to submit this week.
elf Pavlik
@elf-pavlik
I may not be able to attend today, should we postpone the meeting until next week?
Aaron Coburn
@acoburn
Let's postpone -- I'd like to wait for the Solid-OIDC PRs to be published. Then we will have more to talk about
Aaron Coburn
@acoburn
Today is a holiday for many countries and we don't have an agenda (we are still waiting on reviews from the spec editors). I would advocate postponing our meeting to next week. Any thoughts?
elf Pavlik
@elf-pavlik
:+1:
elf Pavlik
@elf-pavlik
Let's meet today to discuss processing all the https://github.com/solid/solid-oidc/issues ?
Aaron Coburn
@acoburn
Yes, I'd like to start prioritizing those open issues. E.g., which are slated for 0.2 and which for later
Aaron Coburn
@acoburn
Here is a HackMD for today: https://hackmd.io/ctg2_B0oSXOJof4QGgrZQw
elf Pavlik
@elf-pavlik
:+1:
Aaron Coburn
@acoburn
@elf-pavlik it seems you were disconnected from the jitsi meeting
Aaron Coburn
@acoburn
HackMD for today's meeting https://hackmd.io/ctg2_B0oSXOJof4QGgrZQw
2 replies
Aaron Coburn
@acoburn
Let me try that again: here's the correct link https://hackmd.io/gEa8yut7Q-akvIX3hl9gdg
Abel Van den Briel
@AbelVandenBriel
I don't seem to have the rights to edit the file (maybe that's intentional :) ). Would it be possible to discuss the role of dynamic client registration in today's meeting?
Inrupt's podbrowser for example seems quite dependent on it, eventhough it is not actually a MUST to implement according to the spec. I feel that they should use a Client ID document instead.
Zwifi
@NSeydoux
Hi, I'm attending a workshop at the Knowledge Graph Conference so I won't be able to be present for the panel today
Aaron Coburn
@acoburn
@AbelVandenBriel if you are signed in, you should be able to edit the document
Sarven Capadisli
@csarven

Just a heads up that there is a Test Suite Panel meeting next week at a timeslot that's at the same time as the authentication-panel's weekly meeting. (It was tentatively accepted based on those that originally agreed but I don't think people were necessarily aware of the meeting here).

The draft agenda is at solid/test-suite-panel#1 .. if anyone would like to attend this meeting but can't make it at that time, please chime in at the PR or in solid/test-suite chat. We can find a more suitable time.

I'm aware of Solid OIDC's test suite location / access controls etc and will bring that up in the meeting where applicable.

Aaron Coburn
@acoburn

Thank you, @csarven . Given the time conflict, I will not be able to attend the test suite panel. If this is an ongoing conflict, it would be unfortunate.

There was a conversation about the Solid-OIDC test suite in this week's AuthN panel meeting, and we decided to move the code into the same repository as the Solid-OIDC specification itself. Given that the maintainers of that test suite are the editors of the specification, this made sense to us. It also avoids multiple moves of the test suite based on changing processes.

Given that the Solid-OIDC test suite is a static JavaScript app, it would be ideal to host it under https://solidproject.org (subject to Solid Editor approval, of course)

Sarven Capadisli
@csarven
Test Suite Panel doesn't meet often.. so this particular timing is just a one off for now. I prefer to reschedule but would like to hear from others that they'd like to attend.
Sarven Capadisli
@csarven
Perhaps of interest, Authenticated Data eXperiment (ADX) Overview Summary: https://github.com/bluesky-social/adx/blob/main/architecture.md
Abel Van den Briel
@AbelVandenBriel

The Solid OIDC specification in section 5.1 pertaining Client ID documents: "When a Client Identifier is dereferenced, the resource MUST be serialized as an application/ld+json document unless content negotiation requires a different outcome."

If the resource MUST be application/ld+json, how would content negotiation require a different outcome? Shouldn't a server just error if a Client ID document is retrieved with a content-type other than application/ld+json?

elf Pavlik
@elf-pavlik
@AbelVandenBriel, this aims at supporting Client ID publishers to support content negotiation. So if they receive a request with no Accept header, or Accept: application/ld+json, they MUST respond with Content-Type: application/ld+json. On the other hand, if the request comes with Accept: text/turtle they may honor it and respond with Content-Type: text/turtle
elf Pavlik
@elf-pavlik
I was sick most of the last week, I'm still recovering and I will not be able to join today's meeting. At the same time, I'm starting to catch up with things here and on github :eyes:
Aaron Coburn
@acoburn
@elf-pavlik I hope you are feeling better. We do not have anything on the agenda for today, so I expect that it will be a short meeting. I also am continuing to work through the various GH issues

The HackMD document for today's meeting: https://hackmd.io/EWMDnxbMSceiPd1cqSvfjA

The meeting itself may be rather short

Aaron Coburn
@acoburn
The HackMD document for the 16 May meeting (today) is at https://hackmd.io/paraBN7HR4i0JD8WFaTRNQ
elf Pavlik
@elf-pavlik
elf Pavlik
@elf-pavlik
pad for today (May 23rd): https://hackmd.io/mq25Ls3USvG0342J0mRzLw
Zwifi
@NSeydoux
Hi, sorry I won't be able to attend today
elf Pavlik
@elf-pavlik
ok, we may cut the meeting short today
Sarven Capadisli
@csarven
There is an issue in the test suite panel to "specify criteria for assessing tests and results": solid/test-suite-panel#7 that's of interest to authors/editors . Please chime in.
elf Pavlik
@elf-pavlik
@/all Given the Memorial Day in US on next Monday, we decided that we will skip the meeting next week and resume in 2 weeks (Jun 6th)
Abel Van den Briel
@AbelVandenBriel

Question about Dynamic Client Registration. The solid oidc spec says the following (section 5.2):
"For non-dereferencable identifiers, the Client MUST present a client_id value that has been registered with the OP via either OIDC dynamic or static registration. See also [OIDC-DYNAMIC-CLIENT-REGISTRATION].

When requesting Dynamic Client Registration, the Client MUST specify the scope in the metadata and include webid in its value (space-separated list)."

While the spec mentions that if a client does not use a dereferencable identifier, they must present a client_id that was registered with the OP either statically or dynamically. However, it doesn't specifically mention if dynamic registration should be supported by an OP. Section 3 contains teh following statement: "This means that client registration, whether dynamic, or static, is entirely optional."

Optional on the part of the client, the OP or both?

Basically what I'm asking is: MUST an OP provide dynamic client registration per the solid oidc specification?

Aaron Coburn
@acoburn

MUST an OP provide dynamic client registration per the solid oidc specification

Short answer: No.

But if the OP does, it MUST advertise its support in the .well-known/openid-configuration resource.

Abel Van den Briel
@AbelVandenBriel

Okay, that's how I interpreted it as well.
I think with it being called optional in section 3, and then in section 5.2 it states that the client MUST present a client_id that was registered via either dynamic or static registration is what confused me.
I guess the "either" is what gives away that you don't have to implement dynamic client registration, because you could also just be using static registration.

I don't think it would be a bad idea to be a bit more explicit though, especially when it comes to what the OP must and must not implement.
Something like "An OP MUST/SHOULD/MAY implement Dynamic Client registration".

A few weeks ago I think there was a discussion about adding a "summary" section of sorts, where all the musts, shoulds, and mays for each participant would be listed. While I don't remember exactly what the conclusion was there, it might be an interesting point to discuss again?
Aaron Coburn
@acoburn

I would argue that any requirements around Dynamic Client Registration are beyond the scope of Solid-OIDC. What is required is that a client MUST present a client_id. Where the client gets that value is up to the client.

Solid-OIDC only defines how a client might use a globally dereferencable client_id (a Client Identifier). But that doesn't mean that a client (RP) must or must not use a different sort of identifier and it also doesn't mean that a server (OP) must or must not support those different sorts of identifiers.

Abel Van den Briel
@AbelVandenBriel
Okay, that makes sense. Thanks @acoburn
Zwifi
@NSeydoux
I'm sorry, but I won't be able to join the call today.
Aaron Coburn
@acoburn
I am also not able to make it this week
Sarven Capadisli
@csarven
Zwifi
@NSeydoux
Is there an authentication panel call this week?
Christoph Braun
@uvdsl
Hi all, I am currently looking at SOLID-OIDC in depth for the first time, the primer is gold.
Question regarding the request flow, step 6 "check DPoP token URL and METHOD" as the AS.
I assume that "check" refers here to matching URL and METHOD between the HTTP request and the DPoP token? yes?
Does it also already include ACL checking? Or when should that happen?
elf Pavlik
@elf-pavlik

Hi @uvdsl

I assume that "check" refers here to matching URL and METHOD between the HTTP request and the DPoP token? yes?

Yes, we may need to tighten up terminology and use DPoP proof in a consistent manner. Also please feel free to make PR if you can think of improved wording.

Does it also already include ACL checking? Or when should that happen?

soloid-oidc tries hard to say out of authorization and only focuses on authentication. There are also ongoing discussions in the Authorization panel where access policy would rely on some other credential than identity, in that case, solid-oidc would not even come into play.

relevant example can be found in: https://github.com/solid/authorization-panel/discussions/290

IMO we should even consider rethinking an assumption that ID Token gets pushed to the AS and let AS request it using required_claims. Possibly specifying that client MAY push ID Token eagerly, but if it doesn't AS MUST request it using required_claims if it expects it.

Christoph Braun
@uvdsl
Ah, I see! Thank you!
re: discussion/290 VC-based Auth, I can image that will be a long discussion, especially regarding privacy considerations, the diversity of signature schemes, etc