Adjust the primer towards OIDC Federation #208

elf-pavlik · 2022-11-21T14:06:23Z

Part of #207
This draft is intended as collaborative scratchpad. We can use inline suggestions to propose and discuss changes.

TODO

OP advertises automatic registration
authentication request should use Request Object or PAR
RP should publish the trust chain
OP should validate the trust chain
in the abstract en intro, refer to OpenID Federation, next to OpenID Connect;
switch "Client ID Document" to "Entity Statement" or "Entity Configuration".

acoburn

This is a great start. How much detail should go into the validation steps involved? i.e. the Resolving Trust Chain and Metadata section

acoburn · 2022-12-05T19:22:48Z

primer/index.bs

@@ -235,6 +235,8 @@ Response Body:
 }
 ```

+Issue: OIDC Federation defines `client_registration_types_supported`, should it be addedhere, to `.well-known/oidc-federation` or both?


This should definitely be added to OpenID Metadata resource (/.well-known/openid-configuration) for OPs that support clients from a federation.

If the OpenID Provider participates in a federation, the OP federation metadata would also contain this information (note the resource path: .well-known/openid-federation).

As I have been considering this change, I have been imagining the relying parties participating in an OIDC federation, but that it would entirely optional for an OpenID Provider to participate in a federation. Or are you thinking that this would be a requirement for Solid OIDC Providers as well?

Thanks! I'm going to add it to /.well-known/openid-configuration.

I think we should start with the minimum required, probably enough for RPs to act as entities in federation.

At first I agreed, but now I'm fairly certain that the Federation spec only means to add that to the .well-known/openid-federation config, not change anything about the OIDC configuration. As long as we're not talking about OPs from a federation perspective, I thus think it should not be added anywhere.

elf-pavlik · 2022-12-05T20:42:35Z

@acoburn I think we should have a simplest case with all the details. Since this is a primer I don't see a problem with showcasing something which isn't specified directly in Solid-OIDC but in OIDC Federation or DPoP.

woutermont

Some inline questions, and two things more general still to do:

in the abstract en intro, refer to OpenID Federation, next to OpenID Connect;
switch "Client ID Document" to "Entity Statement" or "Entity Configuration".

woutermont · 2022-12-06T18:31:04Z

primer/index.bs

@@ -235,6 +235,8 @@ Response Body:
 }
 ```

+Issue: OIDC Federation defines `client_registration_types_supported`, should it be addedhere, to `.well-known/oidc-federation` or both?


At first I agreed, but now I'm fairly certain that the Federation spec only means to add that to the .well-known/openid-federation config, not change anything about the OIDC configuration. As long as we're not talking about OPs from a federation perspective, I thus think it should not be added anywhere.

woutermont · 2022-12-06T18:50:00Z

primer/index.bs

- `client_id=https%3A%2F%2Fdecentphotos.example%2Fclient_id`: Usually the client id of a Solid
-    application is the app's URI (in our case `https://decentphotos.example/client_id`) as seen here.
+- `client_id=https%3A%2F%2Fdecentphotos.example`: Usually the client id of a Solid
+    application is the app's URI (in our case `https://decentphotos.example`) as seen here.
 - `code_challenge_method=S256`: Tells the OP that our code challenge was transformed using SHA-256.
 - `code_challenge=HSi9dwlvRpNHCDm-L8GOdM16qcb0tLHPZqQSvaWXTI0`: The [=code challenge=] we generated before.

 Note: If the app doesn't have a URI, you can either register an app using static registration


Do we want to keep mentioning static registration?

now I'm farily certain that the Federation spec only means to add that to the .well-known/openid-federation config

For an OP that is not part of a federation, how would a client know that the OP supports automatic registration? Unless you are suggesting that all such OPs must also participate in a federation? I had not been making that assumption.

Not sure how that is related to (not) mentioning static registration? Did you mean to respons to the other conversation on client_registration_types_supported, @acoburn?

To answer to your question: I was assuming that a Solid-OIDC compliant OP would always adhere to the OpenID Federation spec, regardless of it being part of an actual federation or not; so every OP would always have a .well-known/openid-federation with the client_registration_types_supported list. Since that list has no defined meaning in OpenID Connect, however, I don't think it has any role in .well-known/oidc-configuration. But that's just how I initially interpreted it; might be wrong.

Aside: @woutermont this is in a different thread because the GH interface, for some inexplicable reason, will not allow me to comment on the relevant thread.

One perspective is that, if a Solid-OIDC OP is going to support the processing of RP Federation trust chains, it would make sense to also require the OP to participate in a Federation. After all, the OP is already implementing most of OIDC Federation, it could sure support the remaining APIs easily enough.

The other perspective is that the specific need on the part of Solid-OIDC is to be able to uniquely and securely identify RPs. Adding requirements to OPs above and beyond the needs of Solid only adds a burden to implementers.

I suspect that many Solid-OIDC OP implementations will also participate in a Federation, but I am wary of adding requirements that are not strictly necessary. It will be important to ensure that there is nothing in the text of the specification that prevents an IdP implementer from adding full OP support for federation.

I totally agree, @acoburn! We should not make it any more difficult for OPs than necessary.

I just don't see how my suggestion (not including client_registration_types_supported in .well-known/oidc-configuration) would do that. As I see it, the only thing we really require from OPs is that they support Automatic Registration, and declare that in their .well-known/openid-federation statement. There is no need to also declare it in .well-known/oidc-configuration, because it has no meaning for clients reading that configuration.

Unless I am mistaken, this entails no other requirements from the OP.

woutermont · 2022-12-06T18:52:11Z

primer/index.bs

 - `code_challenge_method=S256`: Tells the OP that our code challenge was transformed using SHA-256.
 - `code_challenge=HSi9dwlvRpNHCDm-L8GOdM16qcb0tLHPZqQSvaWXTI0`: The [=code challenge=] we generated before.

 Note: If the app doesn't have a URI, you can either register an app using static registration
 via some UI on the OP or use [dynamic registration](https://openid.net/specs/openid-connect-registration-1_0.html).

-<h4 id="authorization-code-pkce-flow-step-7" class="no-num">7. Fetch RP Client ID Document</h4>
+<h4 id="authorization-code-pkce-flow-step-7" class="no-num">7. Fetch RP Metadata</h4>

 If an app URI is provided as the client id (see note above to see other options), we must


I'd expect a break or header here to indicate that we're now switching from the app perspective to the OP perspective. Strange I haven't missed that before.

woutermont · 2022-12-06T18:53:25Z

primer/index.bs

-  "client_id": "https://decentphtos.example/client_id",
-  "client_name": "DecentPhotos",
-  "redirect_uris": [ "https://decentphotos.example/callback" ],
-  "post_logout_redirect_uris": [ "https://decentphotos.example/logout" ],


Post-logout redirect URI disappeared?

[primer] initial changes towards OIDC Federation

923e86e

elf-pavlik requested a review from acoburn November 21, 2022 14:06

elf-pavlik mentioned this pull request Nov 21, 2022

Reconsider Client Identifiers in light of OpenID Federation Entities #207

Open

acoburn reviewed Dec 5, 2022

View reviewed changes

woutermont reviewed Dec 6, 2022

View reviewed changes

bumblefudge mentioned this pull request Dec 5, 2023

OAuth and/or OIDC profile work for Mastodon and/or for AP more generally? swicg/general#38

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adjust the primer towards OIDC Federation #208

Adjust the primer towards OIDC Federation #208

elf-pavlik commented Nov 21, 2022 •

edited

acoburn left a comment

acoburn Dec 5, 2022 •

edited

elf-pavlik Dec 5, 2022

woutermont Dec 6, 2022 •

edited

elf-pavlik commented Dec 5, 2022

woutermont left a comment

woutermont Dec 6, 2022 •

edited

woutermont Dec 6, 2022

acoburn Dec 6, 2022

woutermont Dec 12, 2022

woutermont Dec 12, 2022

acoburn Dec 12, 2022

woutermont Dec 13, 2022

woutermont Dec 6, 2022

woutermont Dec 6, 2022

Adjust the primer towards OIDC Federation #208

Are you sure you want to change the base?

Adjust the primer towards OIDC Federation #208

Conversation

elf-pavlik commented Nov 21, 2022 • edited

TODO

acoburn left a comment

Choose a reason for hiding this comment

acoburn Dec 5, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

woutermont Dec 6, 2022 • edited

Choose a reason for hiding this comment

elf-pavlik commented Dec 5, 2022

woutermont left a comment

Choose a reason for hiding this comment

woutermont Dec 6, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elf-pavlik commented Nov 21, 2022 •

edited

acoburn Dec 5, 2022 •

edited

woutermont Dec 6, 2022 •

edited

woutermont Dec 6, 2022 •

edited