Messages - 2.1.2. scope namespacing

[Torsten Lodderstedt]

The scope values "email", "profile", "address", and "phone" seem fairly generic and may cause clashes with scope values used by other services on the same authorization server, e.g. an e-mail service. I therefore suggest to add the "openid_" prefix to the before mentioned scope values, e.g. "openid_email"

[John Bradley]

Not a unreasonable idea, though it increases the size of requests.

From a practical point of view a server with a conflict could close to interpret the scopes based on the presence of the openid scope.

What would help us evaluate this is feedback on if their is a real deployment issue for someone or a hypothetical one. If this other scope use is sometime in the future they could use google_profile if the conflict is a problem.

On the other hand name spacing scopes is something I prefer, but is not a OAuthy thing to do.

John B.

[Michael Jones]

I disagree with this proposal, as it is unnecessary. Yes, there could be a conflict with the usages of these names without also including the "openid" scope, but including the "openid" scope already unambiguously specifies that these other scope names are to be interpreted in the manner specified in the OpenID Connect specs. The prefix would add no semantic value.

Also, the prefix would make the request unnecessarily larger.

[Torsten Lodderstedt]

(Reply via [e-mail]):

suppose a client wants to get access to identity data (openid) _and_ the email account of an end-user.

the email service is identified by the scope value "email"

the identity data the client is interested in is the email address. So the resulting concatenated scope would be:

"openid email email"

What do you expect the authz server to do?

regards, Torsten.

Am 20.02.2012 20:05, schrieb Bitbucket:

[Michael Jones]

This seems like an artificial example, as a client could gain access to the email account of the end-user using the email claim from the OpenID UserInfo endpoint. In this case, the request would be an normal OpenID Connect request with scope value "openid email".

If you need a different e-mail address than the normal one returned by the OpenID Connect request and you're making the request using OpenID Connect, the normal thing to do would be to give it a different claim name and request it in the claims section of an OpenID Request. For instance, you might request the claim http://example.com/claims/email.

[Nat Sakimura]

Like we have talked about in the call today, I guess Torsten is talking not about email as a claim but email as a service, so that some kind of client can gain access to their IMAP and SMTP service etc. and calling the combination of IMAP and SMTP access as 'email', though for this example, the scope name 'email_read_send' may be more appropriate.

If it is not an existing service, one could always elect to use some other scope name. Only the instance that I know of using scope 'email' is Facebook, and that is compatible with our use.

So, do you actually have such a service at your location, Torsten?

If not, I will close this ticket with 'wontfix', as it was the recommendation of the WG call today.

[Torsten Lodderstedt]

(Reply via [e-mail]):

The client in my example wants to access the email account in order to retrieve and send e-mails on behalf of the end-user. I could imagine to use IMAP/SMTP in combination with Oauth for that case. So what the client needs is a suitable token. A claim about the end-users e-mail address could be helpful, but it does not authorize the client for anything.

regards, Torsten.

Bitbucket <[e-mail]> schrieb:

[Nat Sakimura]

So that is a hypothetical service that does not exist for the time being.

I shall then close this ticket as 'wontfix' since it does not have required support in the WG, and facebook is already using email as the scope name, which is real.

I agree that the authorization for imap/smtp is useful however. Perhaps we shall try to create a registry of standard scope vocabulary.