Subject: [GNAP] Comments on the GNAP Wiki Terminology

From: Denis <[email-masked]>
Date: Fri, 18 Dec 2020 17:47:33 +0100

FYI, the wiki page is 
there:https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology

      FYI first, there is a useful web page where you can find all the
      ISO definitions as well as the text for any ISO standard (up to
      its definition section only):
      https://www.iso.org/obp

      This may provide some ideas and you will notice that a given term
      may be used in different ISO standards with a different definition.

      I have nine comments (each one being numbered).
      _
      1) Current definition of AS_:

      The current definition is:

      *Authorization Server (AS) *
            Definition: server that grants privileges to a particular
      end-user and that provides them to a client in the form of an
      access token

      This is fine in general (but see later another comment about it),
      but the word privileges is left undefined.
      _
      2) Definition of a privilege__
      _

      A suggested "privilege" definition has been proposed in the wiki
      page: "A privilege is the right to perform an operation (or
      action) on a Resource." See also other def
      <https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67568310/Privilege+Dictionary+Entry>
      .
      In the "other def.", the term is considered to be a synonym of a
      permission.

      ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

            privilege
      access right
      permission
      authorization to a subject (3.15)
      <https://www.iso.org/obp/ui#:term:3.15> to access a resource
      (3.14) <https://www.iso.org/obp/ui#:term:3.14>

      Note 1 to entry: Privilege is a necessary but not sufficient
      condition for access. Access occurs when the access request is
      granted according to its access control policy.
                                     The access control policy is based
      on privileges and may include other environmental factors (e.g.
      time-of-day, location, etc.)

      Note 2 to entry: Privileges take the form of data presented by a
      subject or obtained for a subject that is used by a Policy
      Decision Point in order to grant or deny an operation
                                     that a subject is willing to
      perform on a resource.
      (...)

      I propose the following:

      *privilege*: right or attribute associated with an end-user

      with:
      *right*: ability given to an end-user to perform a given operation
      on an object under the control of a RS

      *attribute*: characteristics or property related to an end-user

      __

      _3) Definition of a Client

      _

      The current definition is:

      *Client *
            Definition: application that consumes resources from one or
      several RSs, possibly requiring a negotiation of access privileges
      with one or several ASs

            Note: this specification differentiates between a specific
      instance (the client instance, identified by its public key) and
      the software running the instance
                     (the client software). For some kinds of client
      software, there could be many instances of a single piece of
      client software.
      Example: a client can be a mobile application, a web application, etc.

      Previously, I proposed:

      *Client*: application used by an end-user to interact with an AS
      or a RS

      The current definition is missing to indicate who is operating the
      client. It is an end-user, i.e. it is not another application, nor
      a process, nor an entity.
      The definition should capture this point.

      A second point: the current definition is using the wording
      "requiring a negotiation". There is no "negotiation". Either the
      AS has or has not the "access privileges".
      The words "a negotiation of" should be deleted.

      This raises the point where this definition of a "Client" is using
      the wording "/access privileges/" whereas the definition of an
      "Authorization Server (AS)"
      is using the word "/privileges/". We should make both definitions
      consistent. I have a slight preference for "access privileges",
      but I could also live with "privileges".

      Hence my proposals:

      *     Client *
            application /operated/ /by an end-user /that consumes
      resources from one or several RSs, possibly requiring /access
      privileges from/ one or several ASs
      *
      **    Authorization Server (AS) *
            server that grants /access/ privileges to a particular
      end-user and that provides them to a client in the form of an
      access token

      _4) Definition of a Resource Server (RS)
      _
      The current definition is:
      *
      **     Resource Server (RS) *

            Definition: server that provides operations on /protected
      /resources; such operations require that the client provides valid
      access tokens issued by an AS

      A RS may offer both public resources and protected resources.
      Valid access tokens are only needed for protected resources.
      I propose the following definition while merging the two sentences:

      *Resource Server (RS) *
             server that provides operations on resources /where/
      protected operations require that the client provides /one or
      more/ valid access tokens issued by /one or more ASs/

      In theabove modification I added "/one or more /". I am presuming
      that GNAP will allow the presentation of more that one access
      token from different ASs
      in order to allow an end-user to perform one operation on a
      protected resource.

      _5) Definition of Resource Owner_ _
      _
      The current definition is:

      *Resource Owner (RO) *
            Definition: personal or organizational entity that may grant
      privileges on resources it has authority upon
      Note: the act of granting privileges may be manual (i.e. through
      an interaction) or automatic (i.e. through predefined rules).

      I don't know what a "personal entity" is but I know what a
      "natural person" is.

      Furthermore, a Resource Owner is not granting privileges (or
      access privileges) in the same way an AS is doing.

      It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4
      where Resource Owner (RO) is defined as:

             responsible party for the Resource(s)
             Note 1 to entry: The Resource Owner is responsible for
      granting, denying, and revoking Access to Resource(s).
             Note 2 to entry: The responsible Resource Owner is
      determined by the concrete Resource.

      I propose:

      *Resource Owner (RO) *
      /natural person /or organizational entity that may grant or deny
      operations on resources it has authority upon
      Note: the act of /granting or denying/ an operation may be manual
      (i.e. through an interaction) or automatic (i.e. through
      predefined rules).
      __

      _
      6) Definition of Access Token__
      _

      The current definition is:

            Access token
            Definition: digitally signed data that contains specific
      rights and/or attributes
      Note 1: the access token can be issued to an end-user (usually
      requiring his authentication) and subsequently refreshed.
      The AS usually provides a method for the RO to revoke the
      privileges at any point in time.
           Note 2: an access token may act as a capability (i.e. bearer
      token) or require an additional authentication by binding to a key
      (i.e. bound token)

      The definition is fine, but not the two Notes.

      The second sentence from the Note 1 is stating: "The AS usually
      provides a method for the RO to revoke the privileges at any point
      in time".
      Revoking "the privileges" is different from revoking an "access
      token". The second sentence of this Note 1 which is supposed to be
      about access token is confusing.
      The privileges may be changed at any point in time using a
      management function. Access tokens can be short-lived and thus
      don't need to be revoked.
      Any call-back from a RS to an AS should be avoided in order to
      respect the user's privacy.

      Therefore, I propose to remove the second part of this Note 1 and
      to replace "the" by "a" at the beginning of the first sentence.
      Note 2 is stating:
      Note 2: an access token may act as a capability (i.e. bearer
      token) or require an additional authentication by binding to a key
      (i.e. bound token)

       From the discussion on the list, I believe that we don't consider
      bearer tokens. Note 2 should be removed.

      So my proposal is as follows:

      *     Access token *
            digitally signed data that contains specific rights and/or
      attributes
      Note: an access token can be issued to an end-user (usually
      requiring his authentication) and subsequently refreshed.
      __

      _
      7) Definition of Grant__
      _

      The current definition is:

      *     Grant *
            Definition: (verb): to permit, as a privilege given to an
      end-user to exercise some rights and/or assert attributes during a
      specific duration
      Definition: (noun): the act of granting

      The words ", as a privilege given to" are unnecessary"

      I propose:

            Grant
            (verb): to permit an end-user to exercise some rights and/or
      /to/ assert /some /attributes /at a specific time and /during a
      specific duration
      (noun): the act of granting

      _8) Definition of Resource_ _
      _

      The current definition is:

      *     Resource *
             Definition: protected API served by a RS and accessed by a
      client, if and only if a valid access token is provided

      This definition is incorrect. This definition would be fine for a
      Protected Resource. Change it into "Protected Resource":

      *     Protected Resource *
            protected API served by a RS and /that can be /accessed by a
      client, if and only if a valid access token is provided

      If a definition of a Resource is needed, I propose:

      *     Resource **
      ***public or protected resource from a RS

      _
      9) Definition of Subject Information
      _
      The current definition is:

      *Subject Information*
      Definition: claim asserted locally by an AS about a person,
      organization or device
      Source:
      https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06
      <https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06>
      (unless we plan to use something specific to GNAP)

      This is information returned by an AS about an end-user.

      I would thus simply propose instead:
      *
      **     Subject Information *
            information returned to a Client by an AS about an end-user

      Denis

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 18 Dec 2020 18:02:09 +0100

Thanks Denis, that's a really useful feedback. I'll review that in more
detail, but something that's really not clear to me is the last one,
subject information.

1) is it about the end-user ? or the RO ? (as is the current definition in
V02)
2) why do we even need to call it subject information ? For instance if
it's about the end-user, it should only be end-user information.
3) do we want to use entity or subject in the definitions ? (cf RO for
instance). Regarding natural person vs entity we had a discussion on the
mailing list previously.

Cheers,
Fabien

On Fri, Dec 18, 2020 at 5:47 PM Denis <[email-masked]> wrote:

> FYI, the wiki page is there:
> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology
> FYI first, there is a useful web page where you can find all the ISO
> definitions as well as the text for any ISO standard (up to its definition
> section only):
> https://www.iso.org/obp
> This may provide some ideas and you will notice that a given term may be
> used in different ISO standards with a different definition.
>
> * 1) Current definition of AS*:
>
>      Definition: server that grants privileges to a particular end-user
> and that provides them to a client in the form of an access token
> This is fine in general (but see later another comment about it), but the
> word privileges is left undefined.
>
> * 2) Definition of a privilege*
> A suggested "privilege" definition has been proposed in the wiki page: "A
> privilege is the right to perform an operation (or action) on a Resource."
> See also other def
> <https://www.iso.org/obp/ui#:term:3.15> to access a resource (3.14)
> <https://www.iso.org/obp/ui#:term:3.14>
>
> condition for access. Access occurs when the access request is granted
> according to its access control policy.
>                               The access control policy is based on
> privileges and may include other environmental factors (e.g. time-of-day,
> location, etc.)
>
> subject or obtained for a subject that is used by a Policy Decision Point
> in order to grant or deny an operation
>                               that a subject is willing to perform on a
> resource.
> (...)
> I propose the following:
>
>         *right*: ability given to an end-user to perform a given
> operation on an object under the control of a RS
>
> *3) Definition of a Client * The current definition is:
>      *Client *
>      Definition: application that consumes resources from one or several
> RSs, possibly requiring a negotiation of access privileges with one or
> several ASs
>
>      Note: this specification differentiates between a specific instance
> (the client instance, identified by its public key) and the software
> running the instance
>               (the client software). For some kinds of client software,
> there could be many instances of a single piece of client software.
>       *Client*: application used by an end-user to interact with an AS or
> a RS
>
> The current definition is missing to indicate who is operating the client.
> It is an end-user, i.e. it is not another application, nor a process, nor
> an entity.
> A second point: the current definition is using the wording "requiring a
> negotiation". There is no "negotiation". Either the AS has or has not the
> "access privileges".
> This raises the point where this definition of a "Client" is using the
> wording "*access privileges*" whereas the definition of an "Authorization
> Server (AS)"
> is using the word "*privileges*". We should make both definitions
> consistent. I have a slight preference for "access privileges", but I could
> also live with "privileges".
>
> Hence my proposals:
>
> *     Client *
>      application *operated* *by an end-user *that consumes resources from
> one or several RSs, possibly requiring *access privileges from* one or
> several ASs
>
> *    Authorization Server (AS) *
>      server that grants *access* privileges to a particular end-user and
> that provides them to a client in the form of an access token
>
>
> *4) Definition of a Resource Server (RS) *
> *     Resource Server (RS) *
>      Definition: server that provides operations on *protected *resources;
> such operations require that the client provides valid access tokens issued
> by an AS
> A RS may offer both public resources and protected resources. Valid access
> tokens are only needed for protected resources.
>       server that provides operations on resources *where* protected
> operations require that the client provides *one or more* valid access
> tokens issued by *one or more ASs*
> In the  above modification I added "*one or more *". I am presuming that
> GNAP will allow the presentation of more that one access token from
> different ASs
> in order to allow an end-user to perform one operation on a protected
> resource.
>
> *5) Definition of Resource Owner*
>
>     * Resource Owner (RO) *
>     Note: the act of granting privileges may be manual (i.e. through an
> interaction) or automatic (i.e. through predefined rules).
>
> I don't know what a "personal entity" is but I know what a "natural
> person" is.
>
> Furthermore, a Resource Owner is not granting privileges (or access
> privileges) in the same way an AS is doing.
>
> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where
> Resource Owner (RO) is defined as:
>
>       Note 1 to entry: The Resource Owner is responsible for granting,
> denying, and revoking Access to Resource(s).
>       Note 2 to entry: The responsible Resource Owner is determined by the
> concrete Resource.
> I propose:
>      *Resource Owner (RO) *
>      *natural person *or organizational entity that may grant or deny
>     Note: the act of *granting or denying* an operation may be manual
> (i.e. through an interaction) or automatic (i.e. through predefined rules).
>
> * 6) Definition of Access Token*
>      Definition: digitally signed data that contains specific rights
> and/or attributes
>     Note 2: an access token may act as a capability (i.e. bearer token)
> or require an additional authentication by binding to a key (i.e. bound
> token)
> The second sentence from the Note 1 is stating: "The AS usually provides
> a method for the RO to revoke the privileges at any point in time".
> Revoking "the privileges" is different from revoking an "access token".
> The second sentence of this Note 1 which is supposed to be about access
> token is confusing.
> The privileges may be changed at any point in time using a management
> function. Access tokens can be short-lived and thus don't need to be
> revoked.
> Any call-back from a RS to an AS should be avoided in order to respect the
> user's privacy.
>
> Therefore, I propose to remove the second part of this Note 1 and to
> replace "the" by "a" at the beginning of the first sentence.
> Note 2 is stating:
>       Note 2: an access token may act as a capability (i.e. bearer token)
> or require an additional authentication by binding to a key (i.e. bound
> token)
> From the discussion on the list, I believe that we don't consider bearer
> tokens. Note 2 should be removed.
>      digitally signed data that contains specific rights and/or attributes
>
>     Note: an access token can be issued to an end-user (usually requiring
> his authentication) and subsequently refreshed.
>
> * 7) Definition of Grant*
>      Definition: (verb): to permit, as a privilege given to an end-user to exercise
> some rights and/or assert attributes during a specific duration
>      (verb): to permit an end-user to exercise some rights and/or *to*
> assert *some *attributes *at a specific time and *during a specific
> duration
> *8) Definition of Resource*
>       Definition: protected API served by a RS and accessed by a client,
> if and only if a valid access token is provided
>      protected API served by a RS and *that can be *accessed by a client,
> if and only if a valid access token is provided
>      public or protected resource from a RS
>
> * 9) Definition of Subject Information *
> Definition: claim asserted locally by an AS about a person, organization
> or device
> Source:
> *     Subject Information *
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Denis <[email-masked]>
Date: Fri, 18 Dec 2020 18:06:15 +0100

Hi Fabien,

My mistake.  :-(

The last definition (9) should be about "end-user information".

*end-user information*: information returned to a Client by an AS about 
an end-user

Denis

> Thanks Denis, that's a really useful feedback. I'll review that in 
> more detail, but something that's really not clear to me is the last 
> one, subject information.
>
> 1) is it about the end-user ? or the RO ? (as is the current 
> definition in V02)
> 2) why do we even need to call it subject information ? For instance 
> if it's about the end-user, it should only be end-user information.
> instance). Regarding natural person vs entity we had a discussion on 
> the mailing list previously.
>
> Cheers,
> Fabien
>
> On Fri, Dec 18, 2020 at 5:47 PM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     FYI, the wiki page is
>     <https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology>
>
>
>           FYI first, there is a useful web page where you can find all
>           the ISO definitions as well as the text for any ISO standard
>           (up to its definition section only):
>           https://www.iso.org/obp <https://www.iso.org/obp>
>
>
>           This may provide some ideas and you will notice that a given
>           term may be used in different ISO standards with a different
>           definition.
>
>                Definition: server that grants privileges to a
>           particular end-user and that provides them to a client in
>           the form of an access token
>
>
>           This is fine in general (but see later another comment about
>           it), but the word privileges is left undefined.
>           _
>           A suggested "privilege" definition has been proposed in the
>           wiki page: "A privilege is the right to perform an operation
>           (or action) on a Resource." See also other def
>           In the "other def.", the term is considered to be a synonym
>           of a permission.
>
>           condition for access. Access occurs when the access request
>           is granted according to its access control policy.
>                                         The access control policy is
>           based on privileges and may include other environmental
>           factors (e.g. time-of-day, location, etc.)
>
>           Note 2 to entry: Privileges take the form of data presented
>           by a subject or obtained for a subject that is used by a
>           Policy Decision Point in order to grant or deny an operation
>                Definition: application that consumes resources from
>           one or several RSs, possibly requiring a negotiation of
>           access privileges with one or several ASs
>
>                Note: this specification differentiates between a
>           specific instance (the client instance, identified by its
>           public key) and the software running the instance
>                         (the client software). For some kinds of
>           client software, there could be many instances of a single
>           piece of client software.
>           *Client*: application used by an end-user to interact with
>           an AS or a RS
>
>           The current definition is missing to indicate who is
>           operating the client. It is an end-user, i.e. it is not
>           another application, nor a process, nor an entity.
>           "requiring a negotiation". There is no "negotiation". Either
>           the AS has or has not the "access privileges".
>           This raises the point where this definition of a "Client" is
>           using the wording "/access privileges/" whereas the
>           definition of an "Authorization Server (AS)"
>           is using the word "/privileges/". We should make both
>           definitions consistent. I have a slight preference for
>           "access privileges", but I could also live with "privileges".
>
>           Hence my proposals:
>
>           *     Client *
>           resources from one or several RSs, possibly requiring
>           /access privileges from/ one or several ASs
>           *
>           end-user and that provides them to a client in the form of
>           an access token
>
>                Definition: server that provides operations on
>           /protected /resources; such operations require that the
>           client provides valid access tokens issued by an AS
>
>
>           A RS may offer both public resources and protected
>           resources. Valid access tokens are only needed for protected
>           resources.
>           protected operations require that the client provides /one
>           or more/ valid access tokens issued by /one or more ASs/
>
>
>           In theabove modification I added "/one or more /". I am
>           presuming that GNAP will allow the presentation of more that
>           one access token from different ASs
>                Definition: personal or organizational entity that may
>           grant privileges on resources it has authority upon
>           Note: the act of granting privileges may be manual (i.e.
>           through an interaction) or automatic (i.e. through
>           predefined rules).
>
>           It is interesting to take a look at ISO 20078-1:2019(en),
>           3.1.4 where Resource Owner (RO) is defined as:
>
>           /natural person /or organizational entity that may grant or
>           deny operations on resources it has authority upon
>           Note: the act of /granting or denying/ an operation may be
>           manual (i.e. through an interaction) or automatic (i.e.
>           through predefined rules).
>           __
>
>
>           _
>                Definition: digitally signed data that contains
>           specific rights and/or attributes
>           Note 1: the access token can be issued to an end-user
>           (usually requiring his authentication) and subsequently
>           refreshed.
>               Note 2: an access token may act as a capability (i.e.
>           bearer token) or require an additional authentication by
>           binding to a key (i.e. bound token)
>
>
>           The second sentence from the Note 1 is stating: "The AS
>           usually provides a method for the RO to revoke the
>           privileges at any point in time".
>           Revoking "the privileges" is different from revoking an
>           "access token". The second sentence of this Note 1 which is
>           supposed to be about access token is confusing.
>           management function. Access tokens can be short-lived and
>           thus don't need to be revoked.
>           Any call-back from a RS to an AS should be avoided in order
>           to respect the user's privacy.
>
>           Therefore, I propose to remove the second part of this Note
>           1 and to replace "the" by "a" at the beginning of the first
>           sentence.
>           Note 2 is stating:
>           token) or require an additional authentication by binding to
>           a key (i.e. bound token)
>
>
>           From the discussion on the list, I believe that we don't
>           consider bearer tokens. Note 2 should be removed.
>
>
>                Definition: (verb): to permit, as a privilege given to
>           an end-user to exercise some rights and/or assert attributes
>           during a specific duration
>                (verb): to permit an end-user to exercise some rights
>           and/or /to/ assert /some /attributes /at a specific time and
>           /during a specific duration
>                 Definition: protected API served by a RS and accessed
>           by a client, if and only if a valid access token is provided
>
>
>           This definition is incorrect. This definition would be fine
>           for a Protected Resource. Change it into "Protected Resource":
>
>
>           *     Protected Resource *
>                protected API served by a RS and /that can be /accessed
>           by a client, if and only if a valid access token is provided
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 18 Dec 2020 12:42:30 -0500

There’s a subtlety about “subject information” that I think we need to be careful not to lose, in that it’s the intersection of two different aspects of data rights being given to the client. I’m not sure how best to frame this, so apologies if this sprawls a bit:

First, there’s the dimension of how the data is transmitted to the client. This is a fundamental difference between rights associated with an access token and data being sent back directly to the client in a response message from the AS. The access token is handled by the “resources” request (pending proposed restructure/rename, but that’s the current spec). This tells the AS the things the token can do, but as we all know a big part of that in practice is about what data the token can be used for, and therefore what data the client has access to. The other information is what’s sent directly to the client, and it’s somewhat “new” for GNAP. OpenID Connect showed us the value of passing back an assertion directly to the client, and GNAP is making this kind of “Direct returned information” a first-class citizen, to the point that mechanisms for returning this is in our charter. This could be wrapped in an assertion or returned as raw data, and GNAP currently allows both.

The second dimension is what the data is about, regardless of how it gets back. There are lots of ways to look at this, but one fundamental question is whether the data is :about: the end user or not. Identity is far from the only use case for GNAP, but we know that it’s going to be a driving one for many developers. And when you’re talking about identity information, the distinction between the RQ and RO really comes into sharp relief: are you asking about the current user, or about some other user on a different system, and are they the same person?

So in total it’s something like this:

                   |     Delivery Method       |
                   |                           |
                   | Direct      |  Resource   |
-----------------------------------------------+
          End User | Subject     |  UserInfo   |
    Data           | Information |  Endpoint   |
 Subject  -------------------------------------+
            Other  | ???         |  Resource   |
                   |             |  Server API |
-----------------------------------------------+

Is this a useful diagram and distinction to make in our discussion?

Also for what it’s worth, the OpenID Connect “claims” language would cover everything in that square. It’s primarily about the end user, but doesn’t have to be as the OIDC spec itself stats that it provides methods for "Claims about the End-User and the Authentication event”. In other words, a “claim” is any statement made by an potentially authoritative source, the AS.

 — Justin

> On Dec 18, 2020, at 12:02 PM, Fabien Imbault <[email-masked]> wrote:
> 
> Thanks Denis, that's a really useful feedback. I'll review that in more detail, but something that's really not clear to me is the last one, subject information.
> 
> 1) is it about the end-user ? or the RO ? (as is the current definition in V02)
> 2) why do we even need to call it subject information ? For instance if it's about the end-user, it should only be end-user information. 
> 3) do we want to use entity or subject in the definitions ? (cf RO for instance). Regarding natural person vs entity we had a discussion on the mailing list previously. 
> 
> Cheers,
> Fabien
> 
> On Fri, Dec 18, 2020 at 5:47 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> 
> FYI, the wiki page is there:  https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology <https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology>
> FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only): 
> This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition.  
> 
> 1) Current definition of AS:  
> 
>      Authorization Server (AS) 
>      Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token 
> This is fine in general (but see later another comment about it), but the word privileges is left undefined.  
> 
> 2) Definition of a privilege 
> A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def <https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67568310/Privilege+Dictionary+Entry> . 
> In the "other def.", the term is considered to be a synonym of a permission.  
> 
>     authorization to a subject (3.15) <https://www.iso.org/obp/ui#:term:3.15> to access a resource (3.14) <https://www.iso.org/obp/ui#:term:3.14> 
> 
>     Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy. 
>                               The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.) 
> 
>     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation 
>                               that a subject is willing to perform on a resource. 
> (...) 
> I propose the following: 
> 
>         privilege: right or attribute associated with an end-user 
> with: 
>         right: ability given to an end-user to perform a given operation on an object under the control of a RS 
> 
>       attribute: characteristics or property related to an end-user 
> 
> 3) Definition of a Client 
> 
>      Client 
>      Definition: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs 
> 
>      Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance 
>               (the client software). For some kinds of client software, there could be many instances of a single piece of client software. 
>       Client: application used by an end-user to interact with an AS or a RS 
> 
> The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity. 
> A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges". 
> This raises the point where this definition of a "Client" is using the wording "access privileges" whereas the definition of an "Authorization Server (AS)" 
> is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges".  
> 
> Hence my proposals: 
> 
>      Client 
>      application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs 
> 
>     Authorization Server (AS) 
>      server that grants access privileges to a particular end-user and that provides them to a client in the form of an access token 
>  
> 4) Definition of a Resource Server (RS) 
> 
>      Resource Server (RS) 
>      Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS 
> A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources. 
>       Resource Server (RS) 
>       server that provides operations on resources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs 
> In the  above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs 
> in order to allow an end-user to perform one operation on a protected resource. 
>  
> 5) Definition of Resource Owner  
> 
>      Resource Owner (RO) 
>      Definition: personal or organizational entity that may grant privileges on resources it has authority upon 
>     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules). 
> 
> I don't know what a "personal entity" is but I know what a "natural person" is. 
> 
> Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing. 
> 
> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as: 
> 
>       Note 1 to entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s). 
>       Note 2 to entry: The responsible Resource Owner is determined by the concrete Resource. 
> I propose: 
>      Resource Owner (RO) 
>      natural person or organizational entity that may grant or deny operations on resources it has authority upon 
>     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules). 
> 
> 6) Definition of Access Token  
>      Definition: digitally signed data that contains specific rights and/or attributes 
>     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
>                 The AS usually provides a method for the RO to revoke the privileges at any point in time.      
>     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token) 
> The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time". 
> Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing. 
> The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked. 
> Any call-back from a RS to an AS should be avoided in order to respect the user's privacy. 
> 
> Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence. 
> Note 2 is stating: 
>       Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token) 
> From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed. 
>     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed. 
> 
> 7) Definition of Grant  
>      Definition: (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration 
>      (verb): to permit an end-user to exercise some rights and/or to assert some attributes at a specific time and during a specific duration 
> 8) Definition of Resource  
>      Resource 
>       Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided 
> This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource": 
>      Protected Resource 
>      protected API served by a RS and that can be accessed by a client, if and only if a valid access token is provided 
>      Resource 
> Subject Information 
> Definition: claim asserted locally by an AS about a person, organization or device 
> Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 <https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06> (unless we plan to use something specific to GNAP) 
> 
>      Subject Information 
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 18 Dec 2020 18:45:37 +0100

Yes that's useful. In that case we're closer to the definition that we have
in my previous email, than to that proposed by Denis.

Le ven. 18 déc. 2020 à 18:42, Justin Richer <[email-masked]> a écrit :

> There’s a subtlety about “subject information” that I think we need to be
> careful not to lose, in that it’s the intersection of two different aspects
> of data rights being given to the client. I’m not sure how best to frame
> this, so apologies if this sprawls a bit:
>
> First, there’s the dimension of how the data is transmitted to the client.
> This is a fundamental difference between rights associated with an access
> token and data being sent back directly to the client in a response message
> from the AS. The access token is handled by the “resources” request
> (pending proposed restructure/rename, but that’s the current spec). This
> tells the AS the things the token can do, but as we all know a big part of
> that in practice is about what data the token can be used for, and
> therefore what data the client has access to. The other information is
> what’s sent directly to the client, and it’s somewhat “new” for GNAP.
> OpenID Connect showed us the value of passing back an assertion directly to
> the client, and GNAP is making this kind of “Direct returned information” a
> first-class citizen, to the point that mechanisms for returning this is in
> our charter. This could be wrapped in an assertion or returned as raw data,
> and GNAP currently allows both.
>
> The second dimension is what the data is about, regardless of how it gets
> back. There are lots of ways to look at this, but one fundamental question
> is whether the data is :about: the end user or not. Identity is far from
> the only use case for GNAP, but we know that it’s going to be a driving one
> for many developers. And when you’re talking about identity information,
> the distinction between the RQ and RO really comes into sharp relief: are
> you asking about the current user, or about some other user on a different
> system, and are they the same person?
>
> Also for what it’s worth, the OpenID Connect “claims” language would cover
> everything in that square. It’s primarily about the end user, but doesn’t
> have to be as the OIDC spec itself stats that it provides methods for
> "Claims about the End-User and the Authentication event”. In other words, a
> “claim” is any statement made by an potentially authoritative source, the
> AS.
>
>  — Justin
>
>> privileges and may include other environmental factors (e.g.
>> client. It is an end-user, i.e. it is not another application, nor a
>> process, nor an entity.
>> negotiation". There is no "negotiation". Either the AS has or has not
>> the "access privileges".
>> wording "*access privileges*" whereas the definition of an
>>      application *operated* *by an end-user *that consumes resources
>> from one or several RSs, possibly requiring *access privileges from* one
>> or several ASs
>>
>> A RS may offer both public resources and protected resources. Valid
>> access tokens are only needed for protected resources.
>>      Definition: (verb): to permit, as a privilege given to an end-user
>> to exercise some rights and/or assert attributes during a specific
>> duration
>>      protected API served by a RS and *that can be *accessed by a

---

From: Tom Jones <[email-masked]>
Date: Fri, 18 Dec 2020 10:17:33 -0800

you really need to focus privacy concerns on the subject.
Where the end-user is not the subject, the security concerns about the
end-user should be limited to the leakage from the authn, not other claims.
Certainly the end user will often be the subject, but in the most general
case the RO is the subject. the end-user is the authenticated entity that
can pass on consent from the RO to release subject information.
Peace ..tom

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 21 Dec 2020 09:43:10 +0100

Hi,

Terminology is probably not the right place to define the requirements.

I suggest we keep "subject" for now (and use it as a replacement of
"entity" in the RO definition), and have a more detailed discussion about
how we support privacy in general. If we later see that we need to restrict
the definition because we always have the requirement, we can still do
that.

Fabien

On Fri, Dec 18, 2020 at 7:17 PM Tom Jones <[email-masked]>
wrote:

>>> A second point: the current definition is using the wording "requiring
>>> a negotiation". There is no "negotiation". Either the AS has or has not
>>> the "access privileges".
>>> from one or several RSs, possibly requiring *access privileges from*
>>> one or several ASs
>>>
>>>      server that grants *access* privileges to a particular end-user
>>> In the  above modification I added "*one or more *". I am presuming
>>> that GNAP will allow the presentation of more that one access token from
>>> different ASs
>>> provides a method for the RO to revoke the privileges at any point in time".

---

From: Denis <[email-masked]>
Date: Mon, 21 Dec 2020 12:13:45 +0100

Hi Justin,

I read your explanations several times and I must admit that I fail to 
grasp your point of view.

 From my point of view, there are two kinds of information that can be 
sent back by an AS to a Client:

 1.     an access token that contains in particular a subset of the
    claims about an end-user (among other data), or
 2.     information about the end-user.

Let us focus on the second case. The AS holds personal information about 
the end-user but this does not means that all that information
can/will become a claim that will be included into an access token. In 
particular, the end-user information may contain data that will never
be included into an access token. As a conclusion, the claims about an 
end-user are a subset of the end-user information.

In other words, a “claim” is NOT any statement made by an potentially 
authoritative source, the AS.

In Europe, we now have in force the GDPR (General Data Protection 
Regulation), i.e. the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT
AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons 
with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC.

It is available in 24 languages here: 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679

Article 15 which is about the "Right of access by the data subject" states:

1. The data subject shall have the right to obtain from the controller 
confirmation as to whether or not personal data concerning him
or her are being processed, and, where that is the case, access to the 
personal data and the following information:

    (a)    the purposes of the processing;
    (b)    the categories of personal data concerned;
    (...)

Let us use an example to illustrate this. Some banks require to know the 
marital name of the mother of the end-user or/and her first name.
It is an information that the end-user knows and will not forget. Such 
marital name is not intended to be included into an access token.
It is used to authenticate the end-user when he/she is making a phone 
call to the bank. If such information has been collected, the marital name
of the mother of the end-user may be returned in the "information about 
the end-user".

The information retuned by an AS to a Client about the end-user should 
include at least:

    (a) the categories of personal data concerned,
    (b) the personal data and
    (c) the purposes of the processing (e.g. may be included as a claim
    into an access token).

So I believe that my proposal is still adequate:

    end-user information: information returned to a Client by an AS
    about an end-user

In the core of the document, we may provide more explanations.

Denis

> Yes that's useful. In that case we're closer to the definition that we 
> have in my previous email, than to that proposed by Denis.
>
> Le ven. 18 déc. 2020 à 18:42, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>     There’s a subtlety about “subject information” that I think we
>     need to be careful not to lose, in that it’s the intersection of
>     two different aspects of data rights being given to the client.
>     I’m not sure how best to frame this, so apologies if this sprawls
>     a bit:
>
>     First, there’s the dimension of how the data is transmitted to the
>     client. This is a fundamental difference between rights associated
>     with an access token and data being sent back directly to the
>     client in a response message from the AS. The access token is
>     handled by the “resources” request (pending proposed
>     restructure/rename, but that’s the current spec). This tells the
>     AS the things the token can do, but as we all know a big part of
>     therefore what data the client has access to. The other
>     information is what’s sent directly to the client, and it’s
>     somewhat “new” for GNAP. OpenID Connect showed us the value of
>     passing back an assertion directly to the client, and GNAP is
>     making this kind of “Direct returned information” a first-class
>     citizen, to the point that mechanisms for returning this is in our
>     charter. This could be wrapped in an assertion or returned as raw
>     data, and GNAP currently allows both.
>
>     The second dimension is what the data is about, regardless of how
>     it gets back. There are lots of ways to look at this, but one
>     fundamental question is whether the data is :about: the end user
>     or not. Identity is far from the only use case for GNAP, but we
>     know that it’s going to be a driving one for many developers. And
>     when you’re talking about identity information, the distinction
>     between the RQ and RO really comes into sharp relief: are you
>     asking about the current user, or about some other user on a
>     different system, and are they the same person?
>
>     Also for what it’s worth, the OpenID Connect “claims” language
>     would cover everything in that square. It’s primarily about the
>     end user, but doesn’t have to be as the OIDC spec itself stats
>     that it provides methods for "Claims about the End-User and the
>     Authentication event”. In other words, a “claim” is any statement
>     made by an potentially authoritative source, the AS.
>
>      — Justin
>
>>     On Dec 18, 2020, at 12:02 PM, Fabien Imbault
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Thanks Denis, that's a really useful feedback. I'll review that
>>     in more detail, but something that's really not clear to me is
>>     the last one, subject information.
>>
>>     2) why do we even need to call it subject information ? For
>>     instance if it's about the end-user, it should only be end-user
>>     information.
>>     3) do we want to use entity or subject in the definitions ? (cf
>>     RO for instance). Regarding natural person vs entity we had a
>>     discussion on the mailing list previously.
>>
>>     Cheers,
>>     Fabien
>>
>>               FYI first, there is a useful web page where you can
>>               find all the ISO definitions as well as the text for
>>               any ISO standard (up to its definition section only):
>>               This may provide some ideas and you will notice that a
>>               given term may be used in different ISO standards with
>>               a different definition.
>>
>>               particular end-user and that provides them to a client
>>               in the form of an access token
>>
>>
>>               This is fine in general (but see later another comment
>>               about it), but the word privileges is left undefined.
>>               _
>>               A suggested "privilege" definition has been proposed in
>>               the wiki page: "A privilege is the right to perform an
>>               operation (or action) on a Resource." See also other
>>               def
>>               <https://www.iso.org/obp/ui#:term:3.15> to access a
>>               resource (3.14) <https://www.iso.org/obp/ui#:term:3.14>
>>
>>               Note 1 to entry: Privilege is a necessary but not
>>               sufficient condition for access. Access occurs when the
>>               access request is granted according to its access
>>               control policy.
>>                                             The access control policy
>>               is based on privileges and may include other
>>               environmental factors (e.g. time-of-day, location, etc.)
>>
>>               Note 2 to entry: Privileges take the form of data
>>               presented by a subject or obtained for a subject that
>>               is used by a Policy Decision Point in order to grant or
>>               deny an operation
>>               *right*: ability given to an end-user to perform a
>>               given operation on an object under the control of a RS
>>
>>                    Definition: application that consumes resources
>>               from one or several RSs, possibly requiring a
>>               negotiation of access privileges with one or several ASs
>>
>>               specific instance (the client instance, identified by
>>               its public key) and the software running the instance
>>               client software, there could be many instances of a
>>               single piece of client software.
>>               *Client*: application used by an end-user to interact
>>               with an AS or a RS
>>
>>               A second point: the current definition is using the
>>               wording "requiring a negotiation". There is no
>>               "negotiation". Either the AS has or has not the "access
>>               privileges".
>>               This raises the point where this definition of a
>>               "Client" is using the wording "/access privileges/"
>>               whereas the definition of an "Authorization Server (AS)"
>>                    application /operated/ /by an end-user /that
>>               consumes resources from one or several RSs, possibly
>>               requiring /access privileges from/ one or several ASs
>>               *
>>                    server that grants /access/ privileges to a
>>               particular end-user and that provides them to a client
>>               in the form of an access token
>>
>>               resources. Valid access tokens are only needed for
>>               protected resources.
>>                     server that provides operations on resources
>>               /where/ protected operations require that the client
>>               provides /one or more/ valid access tokens issued by
>>               /one or more ASs/
>>
>>
>>               presuming that GNAP will allow the presentation of more
>>               that one access token from different ASs
>>                    Definition: personal or organizational entity that
>>               may grant privileges on resources it has authority upon
>>               Note: the act of granting privileges may be manual
>>               Furthermore, a Resource Owner is not granting
>>               privileges (or access privileges) in the same way an AS
>>               is doing.
>>
>>               It is interesting to take a look at ISO
>>               20078-1:2019(en), 3.1.4 where Resource Owner (RO) is
>>               defined as:
>>
>>                     Note 1 to entry: The Resource Owner is
>>               responsible for granting, denying, and revoking Access
>>               to Resource(s).
>>               /natural person /or organizational entity that may
>>               grant or deny operations on resources it has authority upon
>>               Note: the act of /granting or denying/ an operation may
>>               be manual (i.e. through an interaction) or automatic
>>               (i.e. through predefined rules).
>>               __
>>
>>
>>               _
>>                   Note 2: an access token may act as a capability
>>               (i.e. bearer token) or require an additional
>>               authentication by binding to a key (i.e. bound token)
>>
>>
>>               "access token". The second sentence of this Note 1
>>               which is supposed to be about access token is confusing.
>>               The privileges may be changed at any point in time
>>               using a management function. Access tokens can be
>>               short-lived and thus don't need to be revoked.
>>               Therefore, I propose to remove the second part of this
>>               Note 1 and to replace "the" by "a" at the beginning of
>>               the first sentence.
>>               Note 2 is stating:
>>               bearer token) or require an additional authentication
>>               by binding to a key (i.e. bound token)
>>
>>
>>               From the discussion on the list, I believe that we
>>               don't consider bearer tokens. Note 2 should be removed.
>>
>>
>>               *Access token *
>>               Note: an access token can be issued to an end-user
>>               *Grant *
>>                    Definition: (verb): to permit, as a privilege
>>               given to an end-user to exercise some rights and/or
>>               assert attributes during a specific duration
>>                    (verb): to permit an end-user to exercise some
>>               rights and/or /to/ assert /some /attributes /at a
>>               specific time and /during a specific duration
>>               *Resource *
>>                     Definition: protected API served by a RS and
>>               accessed by a client, if and only if a valid access
>>               token is provided
>>
>>
>>               This definition is incorrect. This definition would be
>>               fine for a Protected Resource. Change it into
>>               "Protected Resource":
>>
>>
>>               *Protected Resource *
>>                    protected API served by a RS and /that can be
>>               /accessed by a client, if and only if a valid access
>>               token is provided
>>
>>
>>               *Resource **

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 21 Dec 2020 12:45:24 +0100

Hi Denis,

Isn't defining "end-user (or subject) information" by something that starts
with information a bit circular?

If we use "claim = statement about a subject", we avoid that issue and
still focus on the part of the information that needs to transit between
the AS and the client. What's important is not so much that it is a subset
of the full information, but that it is delivered under some authority,
here the AS.

The remaining question is whether that statement can also be about other
subjects than the end-user alone. That's how I understood Justin's comment,
and unless we're 100% sure we'll never need anything else than end-user
information, I'd suggest we keep that open for the time being.

Fabien

On Mon, Dec 21, 2020 at 12:13 PM Denis <[email-masked]> wrote:

> From my point of view, there are two kinds of information that can be sent
> back by an AS to a Client:
>
> It is used to authenticate the end-user when he/she is making a phone call
> to the bank. If such information has been collected, the marital name
> (c) the purposes of the processing (e.g. may be included as a claim into
> an access token).
>
> end-user information: information returned to a Client by an AS about an
> end-user
>
>> client. This is a fundamental difference between rights associated with an
>> access token and data being sent back directly to the client in a response
>> message from the AS. The access token is handled by the “resources” request
>> Also for what it’s worth, the OpenID Connect “claims” language would
>> cover everything in that square. It’s primarily about the end user, but
>> doesn’t have to be as the OIDC spec itself stats that it provides methods
>> for "Claims about the End-User and the Authentication event”. In other
>> words, a “claim” is any statement made by an potentially authoritative
>> source, the AS.
>>
>>  — Justin
>>

---

From: Tom Jones <[email-masked]>
Date: Mon, 21 Dec 2020 09:06:14 -0800

I tried to warn you about user defined as a role. Perhaps you see why now.
if the user is a physician, the data is not about the user, it is about the
patient (the RO, but a RO that doesn't own the data). But it is the
physician that wants to see the data. Focusing on taxonomy before protocol
is not helping to make progress.
Peace ..tom

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 21 Dec 2020 18:18:34 +0100

Well, we need a starting point, and a basic taxonomy is helpful as we can
have a common vocabulary throughout the protocol.
Of course the protocol is the main objective, and we might need to revise
the taxonomy based on what is really specified later on.

I'll prepare a PR so that we can have that initial terminology section and
move forward.

Fabien