Re: [PoC] Federated Authn/z with OAUTHBEARER

> On 9 Jan 2025, at 23:35, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>
> On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> + * Find the start of the .well-known prefix. IETF rules state this must be
>> + * at the beginning of the path component, but OIDC defined it at the end
>> + * instead, so we have to search for it anywhere.
>> I was looking for a reference for OIDC defining the WK prefix placement but I
>> could only find it deferring to RFC5785 like how RFC8414 does.  Can you inject
>> a document reference for this?
>
> I'll add a note in the comment. It's in Section 4 of OIDC Discovery
> 1.0: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
>
> (This references RFC 5785, but only to obliquely point out that it's
> not actually compliant with RFC 5785, if the issuer ID has a path
> component. Section 4.1 gives an example.)

Thanks!

>> + if (strcmp(conn->oauth_issuer_id, discovery_issuer) != 0)
>> Shouldn't the scheme component really be compared case-insensitive, or has it
>> been normalized at this point?  Not sure how much it matters in practice but if
>> not perhaps we should add a TODO marker there?
>
> I don't think we should. While I've read some fights about the meaning
> of "identical" in OIDCD Sec 4.3, IETF seems to be pushing hard for
> exact equality of issuer IDs. RFC 9207 says [1]
>
>   This [issuer] comparison MUST use simple string comparison as
> defined in Section 6.2.1 of [RFC3986].
>
> (Simple string comparison being byte/character-wise rather than
> performing a normalization step.) While RFC 9207 doesn't govern the
> Device Authorization flow yet (maybe not ever?), the current OAuth 2.1
> draft refers to its rules as a MUST [2], and I think we should just be
> strict for the safety of future flow implementations.
>
> I'm sure someone's going to complain at some point, but IMNSHO, the
> fix for them is just to use the same formatting and capitalization as
> the discovery document, and move on.

Fair enough, I buy that. Maybe the above could be de-opinionated slightly and added as a comment to help others reading
thecode down the line? 

--
Daniel Gustafsson