Make CliendID URIs a MUST

[elf-pavlik]

This is intended as a conversation starter. If we want to have proper client constraints, for example, acp:client, we need reliable global identifiers for clients. DynReg could be useful during early development, but production systems must always use URIs to denote clients. This way, the redirect_uri gets verified.

related:

• Document issues when relying on HTTP Origin header security-considerations#17

[michielbdejong]

I think (hope) we can still make client-side web apps work securely though, if we resume work on solid/webid-oidc-spec#34

[michielbdejong]

By client-side web apps I mean the "client" is the code running in a specific tab in a specific window of a specific browser on a specific device, even if its source code has a global identifier. Similar for smartphone apps.

[uvdsl]

I do think that client restrictions / client authentication is an important security control.
However, I am not sure to require Client ID URIs (and Documents) to be used by all clients.

In my mind, it is sufficient to allow usage of Client ID URIs (and Documents) such that client restrictions can be applied. If a client uses dynamic registration, then they simply must not be able to access data where access is restricted to certain (identifiable) clients.

Therefore, I think using Client ID URIs (and Documents) should be strongly encouraged rather than required.

[elf-pavlik]

While in https://solid.github.io/solid-oidc/#clientids-oidc
We have requirement on a client for DynReg, nothing requires OP to support DynReg.
Aren't ClientID URLs already the only reliable mechanism in open ecosystem?

Not making it a MUST mostly leaves an option for semi-walled gardens to not use it.

[uvdsl]

Uhm, I beg your pardon, can you elaborate what you mean? I am unable to follow your reasoning...?

[elf-pavlik]

• Dynamic Registration requirement level for OP #216

[uvdsl]

@elf-pavlik, what exactly is the problem you are seeing? I don't get it.
Is it that Solid-OIDC does not require either dereferenceable ClientID URIs to be used nor dynamic registration such that an OP might not support either but only static registration - or what?

[elf-pavlik]

https://solid.github.io/solid-oidc/#clientids-document

Also, the OP MUST dereference the Client ID Document and match any Client-supplied parameters with the values in the Client ID Document.

My understanding is that we already have MUST on OP, so it is the only reliable mechanism given that DynReg is optional for OP.

[uvdsl]

I think you try to say that the spec requires an OP to be able to dereference Client ID URIs (if presented) and not requires an OP to support dynamic registration. Yes?

Please spell out your reasoning why then disallowing dynamic registration altogether is a good idea?

[elf-pavlik]

I'm not saying that we should disallow it, I'm only noticing that it is already unreliable in open ecosystem, and unless client operates in some kind of semin-closed context where it has realiable DynReg, URL Client IDs are the only reliable option on the table.

[uvdsl]

Well, by requiring using a Client ID URI, you are effectively disallowing dynamic registration 🤷 .

I'm only noticing that it is already unreliable in open ecosystem

I don't know where you are getting this from. All major Solid server implementations support dynamic registration...?
Can you define what you mean with the term "reliable"?
Can you elaborate (perhaps with more than repeating one line of the same words used earlier) on why you think dynamic registration is unreliable in open ecosystems?

[elf-pavlik]

Can you elaborate (perhaps with more than repeating one line of the same words used earlier) on why you think dynamic registration is unreliable in open ecosystems?

1. Solid-OIDC doesn't require OP to implement DynReg
2. In open ecosystem user can pick their OP, including providers which don't implement DynReg
3. App which only uses DynReg will not work for the user who has chosen OP that doesn't implement it
4. App which uses URL Client ID will always work since OP MUST support URL Client ID

How about we add it to CG agenda and try to clarify this topic further during the meeting?