Thoughts on Validation/Introspection naming

[MonkeyJamboree]

So I have mulled this over in my head several times while working on the Introspection spec implementation for the validation endpoint. I believe we should keep in-line with the introspection naming convention set forth by OAuth 2.0 Token Introspection for several reasons:

1. The OIDC Mailing List provides some other valuable info on Introspection as well, and clearly defines it as optional in the spec, however they all use the same terminology.
2. Other implementers use this terminology as well. Examples:
   • IBM WebSphere
   • Gluu
   • PingIdentity
   • MITREid Connect
3. The UMA Protocol (and possibly others built on top of OAuth and OpenID Connect) uses this terminology in its spec.
4. Naming it something else to external users muddies the terminology used and allows for future conflicts. If another/better spec comes along (unlikely) and uses the term validation, it would conflict with the naming this middleware uses. Mostly it is about keeping with what's established though.

I feel pretty strongly about this change as a result, but I'd like some other opinions on it. Thoughts? Suggestions?

@PinpointTownes Thanks for the previous suggestions. Would you mind reiterating why you prefer validation over introspection?

[kevinchalet]

Would you mind reiterating why you prefer validation over introspection?

Sure:

1. introspection is a weird name, and definitely not obvious for non-native English speakers. I asked 2 friends to guess what an introspection endpoint was supposed to do, and they had absolutely no idea. validation endpoint is much more obvious name :smile:
2. the introspection endpoint is clearly more a validation thing than a way to extract the claims contained in a token (the specs even deter you from sharing too many claims). And it's clearly stated in the message you mentioned (http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130909/003945.html):

If the issuer is someone you trust (ie, it's on a list of URLs), do introspection on it with that issuer to make sure it's still valid (and to find out scopes and stuff).

If the validation name causes too much friction despite being properly documented, we'll still be able to rename it :+1:

[MonkeyJamboree]

Related to this topic, with the current naming conventions being validation-based, should the configuration endpoint list the endpoint as introspection_endpoint as most others do, or validation_endpoint and possibly break conventions? This, and the default endpoint address being /connect/introspect versus /connect/token_validation' are the main concerns for me at this point in time. How the middleware andIOpenIdConnectServerProvider` implementations name it doesn't really matter in the end as long as implementers know that it implements the introspection spec.

[kevinchalet]

Neither introspection_endpoint nor validation_endpoint are standard metadata properties, but I prefer introspection_endpoint :+1:

[Igorbek]

+1 for introspection_endpoint, Introspection* naming and default endpoint value as /connect/introspect.

[kevinchalet]

The final result will be a compromise: we'll keep the validation name internally and expose introspection in the metadata stuff :smile:

[MonkeyJamboree]

That seems satisfactory to me since internals or implementations aren't part of the spec anyway.