[keycloak-dev] Client Scope naming

[Schuster Sebastian (INST/ESY1)]

I just checked the UMA 2.0 spec again and I found that the term “client scope” is not used directly. It is just called scope but associated to the client and not the resource server,
See section 3.3.1 Client Request to Authorization Server for RPT in : https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html

scope
    OPTIONAL. A string of space-separated values representing requested scopes. For the authorization server to consider any requested scope in its assessment, the client MUST have been pre-registered for the same scope with the authorization server. The client should consult the resource server's API documentation for details about which scopes it can expect the resource server's initial returned permission ticket to represent as part of the authorization assessment (see Section 3.3.4).

The resource server has its own set of scopes that is also used assess authorizations, see section 3.3.4 Authorization Assessment and Results Determination.

I just fear the term „scope“ is a bit overused…

Best regards,
Sebastian


Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn



From: Pedro Igor Silva [mailto:psilva at redhat.com]
Sent: Mittwoch, 14. März 2018 21:01
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Client Scope naming

I need to take a closer look on what Marek did around client scopes. So far, scopes were basically associated with roles and protocol mappers and that is not really what we need in UMA 2.0.

If scopes now is more abstract and we can remove "authorization scopes" in authz services, I need to take a look ...

In fact, I need to review scope parameter in UMA grant type in order to allow clients to push additional scopes other those already added in a ticket.

On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Hi,

I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ☺ WDYT?

Best regards,
Sebastian

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30 726112-100<tel:%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn



_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev