<div dir="ltr">Much of what I've done in our OIDC deployment has been guided by a REFEDS white paper, <a href="https://wiki.refeds.org/download/attachments/38895621/20181011-OIDC-WP.pdf">"White Paper for implementation ofmappings between SAML 2.0 and OpenIDConnect in Research and Education"</a><div><br></div><div>In reference to the "email_verified" claim, it says...</div><div>    As in such case it may be assumed the email service being used is</div><div>    under direct administrative control of the Institution, and the requirements</div><div>    for setting email_verified to "True" have been fulfilled.</div><div><br></div><div>I decided I'd send email_verified as part of the "email" scope.  The problem is, <a href="https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims">the spec</a> says, the value for email_verified (and phone_number_verified) are booleans, not strings.  (I imagine you'd have a similar problem if you wanted to send updated_at, which is a number, not a string).</div><div><br></div><div>Acc'd to the <a href="https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AttributeEncoderPluginConfiguration#attributeencoder-plugin-types">wiki for the OIDC plugin</a>, there are three encoder types..</div><div>- string</div><div>- scoped string</div><div>- binary</div><div><br></div><div>I'm guessing with that in mind, we can't actually publish email_verified, phone_number_verified, or updated_at keeping in line with the spec?</div><div><br></div><div>Liam</div></div>