[GNAP] Open question: Why is a RO optional ?

[Denis <[e-mail]>]

Hi Fabien,

In this email, I only respond to the open question:  Why is a RO optional ?
Therefore I changed the name of the thread.

I expect a RO to communicate from time to time with a RS to define 
access control rules for the various operations that are possible on the 
objects managed by the RS.
Once these rules have been defined, that are taken automatically into 
consideration by the RS until then are changed. This guarantees a high 
throughput.

I don't expect a physical person acting on its own behalf or 
representing an organization to be present 24 hours a day to authorize 
individual operations on a resource.

However, I see two cases where a RO might be involved (leaving apart the 
case where the end-user and the RO is the same individual).
While most operations are handled automatically following access control 
rules that have been defined either by a RO or by management operations,
some specific operations may need a physical person (i.e. a RO) to 
approve them.

a) the RS is able to call a RO. For a few specific operations that 
requires a human approval, a RO may be involved, but only during working 
hours.

b) the AS is able to call a RO. While this case would be technically 
possible, I don't like it for reasons explained hereafter:

  *     the AS must establish prior relationships with all these ROs and
  *     the AS will be able to know which operations are performed by
    each end-user on which object.
        In that case, the AS will be able to act as Big Brother.

Denis

> Hi Denis,
>
> Thanks for your detailed feedback. My comments are embedded into your 
> message. Again those comments are my own, and we'll need to converge 
> to some consensus beyond what I say here. My main Natalya Krasavina 
> <https://www.sex.com/pin/57709709-natalya-krasavina-nata-lee/>. Could 
> you explain?
>
> Fabien
>
> On Fri, Dec 11, 2020 at 12:08 PM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     This is a global response to the definitions proposal.
>
>
>           Terminology
>
>
>           I propose to adopt the way ISO defines how to write the
>           definitions.
>
>
>           It is a */single sentence/* that may be substituted to the
>           wording being defined in the context of a sentence that uses
>           that definition.
>           Since this single sentence can be substituted to the
>           wording, there is not point at the end of that sentence. The
>           sentence does not
>           have a "a" or "the" in front of it.
>
>
> [FI] In the first version, I was mostly trying to not get too far away 
> from the current text. But yes that's a good idea, it gives a more 
> formal rule, which has been proven to work.
>
>
>
>     If more information is useful to understand the wording, it is
>     placed in one or more notes afterwards.
>
>     Note: The ISO rules for drafting definitions are in the ISO/IEC
>     Directives, Part 2 (edition 2018):
>
>         16.5.6    Definitions
>
>         The definition shall be written in such a form that it can
>         replace the term in its context. It shall not start with an
>         article (“the”, “a”) nor end with a full stop.
>         A definition shall not take the form of, or contain, a
>         requirement.
>
>         Only one definition per terminological entry is allowed. If a
>         term is used to define more than one concept, a separate
>         terminological entry shall be created
>         for each concept and the domain shall be included in angle
>         brackets before the definition.
>
>         Circular definitions, which repeat the term being defined, are
>         not allowed.
>
>     Comments are inserted between the lines.
>
>>     Hello everyone,
>>
>>     As an editor : a quick reminder that terminology issues will be
>>     discussed in the coming weeks, and we're expecting your inputs
>>     right now (according to the process previously sent on the
>>     mailing list).
>>     https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29
>>     <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29>
>>     https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology
>>     <https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology>
>>
>>
>>     The rest of this message is a proposal written in my own name,
>>     and doesn't involve discussions with the editors/chairs who might
>>     have different opinions.
>>
>>
>>           *Authorization Server (AS)*
>>
>>     Manages the granting of privileges to a third-party client
>>     instance. If the RO consents to at least a part of what is
>>     requested, the AS issues an access token to the client.
>>
>>     /My questions: /
>>
>>     /- was else do we issue? (e.g. id claims, payment info, etc.) We
>>     could have more than access tokens, but “directed information” is
>>     not clear. I removed that for now./
>>
>>     /- there might potentially be several AS, currently we don’t
>>     reflect that anywhere. If would leave that as an open item,
>>     depending on what we end up doing in the spec/
>>
>     I am not in favour of this definition: A RO as defined later:
>     "authorizes the request to access a protected resource from the RS
>     to the client".
>     This does not mean in any way that a RO has necessarily a direct
>     relationship with one or more ASs. [FI] indeed we could remove
>     that limitation, to have a more general definition
>
>
>           Using the ISO style for definitions, I propose:
>
>         Authorization Server (AS): server that grants rights and/or
>         attributes to a particular end-user and that provides them to
>         a client in the form of an access token
>
>     Since this definition is using the words "rights" and
>     "attributes", these two terms need to be defined as well.
>
>         right: ability for an end-user to perform a given operation on
>         an object under the control of a RS
>
>         attribute: property related to an end-user
>
>
> [FI] I like your proposal in general. There might be some discussions 
> on the details. I don't think it makes sense to grant "attributes".
>
>     Some explanations: a "right" is able to support a capability
>     scheme. An "attribute" is able to support an ACL scheme.
>
>     These two schemes are able to support "discretionary access
>     control" where the end-user has a "need-to-know".
>
>     However, some attributes are also able to support what  was called
>     in the past "mandatory access control"; for example,
>
>     if the end-user is cleared to "top-secret / marketing strategy".
>
>
>>           *Interact Server (IS)*- this is a new proposed term
>>
>>     Manages the front-end interaction with the RO, in order to gather
>>     its consent. Depending on the deployment model and the privacy
>>     requirements,
>>     the IS may be a component of the AS, or may be distinct and
>>     managed by another party.
>>
>>     Example : an IS usually involves a web interface accessed by RO
>>     through a web browser.
>>
>>     Note : an IS is not always required, especially if the access is
>>     granted through automated policies.
>>
>     Using the ISO style for definitions, I propose:
>
>
>               Interact_ion_ Server (IS)
>
>               component from the AS or server interfacing with an AS
>               that manages the interactions with a RO, in order to
>               gather its authorization
>
>
>               Note : since the RO is an optional component, the IS is
>               also an optional component.
>
>
> [FI] indeed IS is optional. note for myself when looking at RO : why 
> is RO optional ?
>
>>
>>           *Client*
>>
>>
>>           Requests privileges from the AS, and uses access tokens at
>>           the RS. This specification differentiates between a
>>           specific instance (the client instance, identified by its
>>           unique 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.
>>           The AS determines which policies apply to a given client
>>           instance, including what it can request and on whose behalf.
>>
>
>           Some comments: The above text is stating: "(the client
>           instance, identified by its unique public key)".
>           A client instance may use a public key, but that key is not
>           necessarily unique, in particular when there are multiple ASs.
>
> [FI] yes, although when possible I would still consider a better 
> practice to expose a key to a specific AS and not to the entire set of 
> available ASs.
>
>>     Example : a client can be a mobile application or a web
>>     application (the client software) that requires authorizations
>>     from the RO to retrieve content from various protected APIs. The
>>     client instance may for instance refer to a specific version of
>>     that client software.
>>
>>     /See on-going discussion :
>>     https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132
>>     <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132>
>>     (client instance). /
>>
>
>           Using the ISO style for definitions, I propose:
>
>
>               Client: application used by an end-user to interact with
>               an AS or a RS
>
>         Note: a client can be a mobile application or a web
>         application [FI] for me those are just examples, because there
>         could me more (ex IoT device)
>
> [FI] you remove the entire discussion on client instance / client 
> software, is that on purpose because you think it's not useful/right, 
> or is it because of something else? (maybe add your comment of the 
> related issue)
>
>>
>>           *Resource Server (RS)*
>>
>>     Accepts valid access tokens from the client issued by the AS and
>>     serves protected resources on behalf of the RO. There could be
>>     multiple RSs protected by the AS that the client may call.
>>
>>     Example : a RS is often composed of protected APIs that can be
>>     consumed by authorized client software.
>>
>     One comment: a RO is not necessarily involved. [FI] a bit hard to
>     imagine, there's some kind of owner. Could you be more explicit?
>
>
>           Using the ISO style for definitions, I propose:
>
>         Resource Server (RS): server that accepts valid access tokens
>         from clients issued by one or more ASs which are used to grant
>         or deny some requested operations
>
>         Note: a RS is often composed of protected APIs that can be
>         consumed by clients.
>
>
>>           *Resource Owner (RO)*
>>
>>     Authorizes the request to access a protected resource from the RS
>>     to the client. The RO may decide to remove its consent at any time.
>>
>>     Note : the RO may be a physical person or may represent an
>>     organization.
>>
>
>     Two comments: In order to avoid confusion with the end-user
>     consent, the word " authorization" is being used instead of
>     "consent". [FI] ok
>
>     It should be said that the RO is an optional component.[FI] why?
>     Using the ISO style for definitions, I propose:
>
>         Resource Owner (RO): physical person acting on its own or
>         representing an organization that authorizes to clients
>         operations on protected resources from a RS
>
>         Note: The RO is an optional component that may interact either
>         with one RS or with one or more ASs ,e.g. using an IS.
>
>>
>>           *End-user* – this was previously Requesting Party RQ
>>
>>     A physical person that operates and interacts with the client
>>     software.
>>
>>     Note : the end-user may or may not be the same entity as the RO.
>>
>     The Note is slightly incorrect. the /physical person/may or may
>     not be the same entity as the RO. [FI] I didn't understand your
>     comment
>
>
>           Using the ISO style for definitions, I propose:
>
>
>               End-user :  physical person that operates and interacts
>               with the client software
>
>         Note : that physical person may or may not be the same entity
>         as the RO.
>
>
>>           *Access Token*
>>
>>     A set of privileges delegated to the client instance for a
>>     specific end-user. An access token is created by the AS, consumed
>>     and verified by the RS, and issued to and carried by the client's
>>     end-user on behalf of the RO. The contents and format of the
>>     access token are opaque to the client.
>>
>>     Example : JWT is a commonly used format.
>>
>>     Note 1 : an access token generally has a limited duration, after
>>     which it may be refreshed at a regular interval.
>>
>>     Note 2 : an access token may be revoked at any time by the RO.
>>
>>     Note 3 : an access token may act as a capability or require an
>>     additional authentication by binding to a key
>>
>     A fundamental point: the third sentence from the definition
>     states: "The contents and format of the access token are opaque to
>     the client".
>
> [FI] I'll check your other thread dedicated to that issue
>
>     See my other email sent today about "RS-Token Introspection or
>     RC-Token Introspection" where I conclude:
>
>           For end-users caring about their privacy (or for systems
>     willing to protect the user's privacy), access tokens should not
>     be considered
>           to be opaque to RCs nor to RSs and ASs should not support
>     Token Introspection, whether it is RS-Token Introspection or
>     RC-Token Introspection.
>
>     The example and the other Notes above should be removed. If needed
>     they should be placed in the main body of the document.
>
>     Using the ISO style for definitions, I propose:
>
>         Access Token: digitally signed data issued by an Authorization
>         Server (AS) and consumed by a Resource Server (RS)
>                                  that contains rights and/or
>         attributes granted to a particular end-user
>
>
>>           *Grant*
>>
>>     The process by which the client requests and is given delegated
>>     access to the RS by the AS through the authority of the RO.
>>
>
>           Using the ISO style for definitions, I propose:
>
>         Grant: permission given to end-user to use a subset of his
>         rights and/or his attributes at a specific time and for a
>         specific duration
>
>
>>           *Key*
>>
>>     A public cryptographic binding a request to the holder of a
>>     private key. Access tokens and client instances can be associated
>>     with specific keys at a point in time.
>>
>>     Note : a key can be rotated or revoked by its holder. The
>>     protocol supports the update of the key information.
>>
>     "key" is a general term that is well understood and that does not
>     need to be defined. [FI] I really wouldn't bet on that. We can
>     reuse an existing definition but it is a central piece so we need
>     to be explicit
>
>     The "definitions" section is not intended to explain what can be
>     done with the term that is being defined. [FI] ok we can work on that
>     Until the word "key" is qualified using one or more other terms,
>     this definition should be removed.
>
>
>>           *Resource*
>>
>>     A protected API served by the RS and accessed by the client if
>>     and only if access has been granted. Access to this resource is
>>     delegated by the RO as part of the grant process.
>>
>     The second sentence of the definition is not in accordance with
>     the ISO style or definitions and furthermore this second sentence
>     should be removed since a RO is an optional element.
>
>
>           Using the ISO style for definitions, I propose:
>
>
>               Resource: protected API served by a RS and accessed by a
>               client, if and only if access is granted by an access token
>
>>
>>           *Subject Information*
>>
>>     Information about a subject (usually a RO) that is returned
>>     directly to the client from the AS.
>>
>>     Note : this information needs to be unique.
>>
>     This definition exhibits several problems:
>
>         (1) The term "subject" is not defined.
>
>         (2) The information that is returned is for an end-user, i.e.
>         not for "(usually a RO)".
>
>         (3) The Note states : "this information needs to be unique".
>         Does it mean unique for the AS ? globally unique ?
>
>     This definition should be revisited. [FI] I agree (I myself had
>     many questions here)
>
>     Denis
>
>>
>>     /My questions : /
>>
>>     /- probably we’d need to define subject/
>>
>>     /Subject :
>>     https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry
>>     <https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry>/
>>
>>     /- might be useful to clarify the relationship to what identity
>>     providers do /
>>
>>
>>
>>     Cheers
>>     Fabien
>>
>>
>>
>>
>
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>     <https://www.ietf.org/mailman/listinfo/txauth>
>