Google "iss" value missing https://

[Michael Jones]

Google uses the string "accounts.google.com" as its "iss" claim value in ID Tokens, even though the spec requires it to be a URL using the https scheme. This difference from the spec wasn't caught early in their implementation and now it would be hard to change.

At a minimum, we probably need to add a note to implementers saying that they'll need to allow this as a special case to interop with Google. We should also probably say that omitting the https:// should not be allowed in the general case.

[John Bradley]

The alternative is to say that leading https:// may be omitted from iss.

This saves 8 characters from every id_token but the comparison rule for the client is slightly more complicated.

Where SAML went with entityID being a string caused a lot of problems, so relaxing the rule that it is a https: URI would be bad. Saying that it is a https: URI but that the scheme may be omitted for space is a possible compromise.

[Michael Jones]

When we decide this issue, we may also need to say something additional about the value of the Discovery "issuer" value, should we decide to allow "iss" claim values without the https:// scheme.

[Nat Sakimura]

I, like others in the WG, am weary of changing the normative text at this point unless it is clearly a bug. This is not. Do we really need to deal with it?

[Vladimir Dzhuvinov]

I would suggest to leave the current "iss" spec as it is and let client / library implementers work around the Google case. That wouldn't be hard to do in Nimbus OIDC SDK, actually not at all.

[Michael Jones]

We will add an implementer's note about Google's iss not actually following the spec at the time of this writing, but that implementations should be prepared for them to do so in the future, should they fix their implementation.

[Michael Jones]

Fixed #876 - Described that Google's "iss" value currently omits the required "https://" prefix

→ <<cset 80eaa07d01d0>>