<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">It occurred to me that RFC 8414 and OpenID Connect Discovery while being functionally very close, define different REQUIRED metadata. Specifically OpenID Connect is a superset of the REQUIRED metadata in RFC 8414, adding jwks_uri, subject_types_supported, and id_token_signing_alg_values_supported as required metadata fields.<div><br></div><div>As a client, if I want to support both specifications, and want to enforce the presence of required metadata, is there a way to know from the document itself whether a metadata document is following OpenID Connect Discovery rather than RFC 8414 in order to enforce the additional required fields?</div><div><div><br></div><div>Direct links to the relevant sections:</div><div><a href="https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata">https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata</a></div><div><a href="https://tools.ietf.org/html/rfc8414#section-2">https://tools.ietf.org/html/rfc8414#section-2</a><br></div><br class="gmail-Apple-interchange-newline"></div><div>Currently this client (AppAuth) will operate in "OpenID Connect" mode when given a discovery doc with an issuer, and "OAuth 2.0" mode when not. One possible resolution could be that the mode should no longer be inferred by whether or not a discovery doc is supplied (now that OAuth also has metadata), and rather that this should be an explicit choice by the developer. Another resolution (which would be the simplest option) is that since the client doesn't actually need those required fields for its own operation, we can relax the rule and only validate RFC 8414 required fields.</div><div><br></div><div>William</div></div></div></div></div></div>