Re: [keycloak-dev] Client Scope naming

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 | <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG... GERMANY | www.bosch-si.com Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100 <+49%2030%20726112100> | Sebastian.Schuster(a)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@redhat.com] *Sent:* Mittwoch, 14. März 2018 21:01 *To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com&gt; *Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; *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(a)bosch-si.com&gt; 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> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev