- changed status to open
openid2 scope should be ignored if not supported
It would be better for an OP to ignore an "openid2" scope value, instead of rejecting an authentication request with "invalid_scope", when it doesn't want to return an OpenID 2.0 identifier. Ignoring it would be consistent with OpenID Connect 1.0 section 3.1.2.1. that says scopes values that are not understood SHOULD be ignored. Ignoring it makes it safer for RPs to support migration because there is less risk of triggering errors.
Section 7 of the migration spec notes that even OPs that support migration may start returning invalid_scope values in future. This seems to add more risk to RPs that implementing migration could trigger errors at some future point.
Delete section 4.1.1. "Scope "openid2" Not Supported". Delete the note in section 7. Probably worth explicitly saying (in section 2 or 4?) that an OP should ignore the openid2 scope if it is not supported or there is no OpenID 2.0 identifier.
Comments (5)
-
-
Returning errors would provide a disincentive for RPs to use the feature. Better to ignore it.
-
Accept.
Delete section 4.1.1. "Scope "openid2" Not Supported". Delete the note in section 7. Probably worth explicitly saying (in section 2 or 4?) that an OP should ignore the openid2 scope if it is not supported or there is no OpenID 2.0 identifier.
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
Migration: Fixed
#963- openid2 scope should be ignored if not supported→ <<cset 2f6cebf22ba7>>
- Log in to comment
Need to discuss on list. Is there a real use case for returning this error. It forces the Client to back off and retry without the scope. That may be a problem for simple Clients.