Re: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00

[Denis <[e-mail]>]

Hi Fabien,

I have been quite long before responding to your email. The response 
took me occupied for a long while too.

> Hi Denis,
>
> I've been thinking more about your feedback. Marked with [FI] in your 
> initial comments.
>
> We probably need to address your feedback early on, and make sure the 
> WG is fine with those.
> Overall I believe we can achieve much of what you'd want regarding 
> privacy, without impacting too much the architecture.

[Denis] I hope so (and cross my fingers).


> Fabien
>
> On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Denis,
>
>     The "many options" is only a temporary state, the goal was to
>     expose the decisions that need to be made to the mailing list. We
>     can quickly reduce to a manageable level by having focused
>     discussions.
>
>     As for the remainder of your comments, the only item we considered
>     so far was one of principle: that privacy is an important goal of
>     the work. The rest of the focus was on taking the best out of XYZ
>     and XAuth. So incorporating the discussions that occurred just
>     before the focus group wasn't a goal. You can already see that
>     with regards to terminology, where insightful discussions occurred
>     but the paint was really very fresh.
>
>     I find what you explain really interesting. It will need to be
>     analyzed in detail. The caveat is that we have less background
>     experience of what it means in practice (compared to the current
>     document vs OAuth2).
>     I guess it will require a bit of experimentation, to avoid corner
>     cases.
>
>     More specific comments/questions coming later :-)
>
>     Fabien
>
>
>     Le mer. 21 oct. 2020 à 17:58, Denis <[e-mail]
>     <mailto:[e-mail]>> a écrit :
>
>         Hi,
>
>         I haven't read all the document in details, but I have browsed
>         through it: this took me about 3 hours.
>         As it is, I don't consider that the current text (more than
>         100 pages !) is a "good starting point".
>
>         The less that I can say is that the document is far from being
>         crystal clear, is too complex and includes so many options
>         (without indicating which parameters are required and which
>         ones are optional) that it will be impossible to claim that
>         an implementation complies with it.
>
>         In addition, it is unfortunate that many of the discussions we
>         have had on the mailing list have not been incorporated by the
>         design team.
>
>         Here are some comments:
>
>         1.An overview is missing since the various features are only
>         being discovered while reading the document.
>
>         2.A key question that might interest a reader is the
>         following: what are the common points and the main differences
>         with OAuth ?
>
>         3.The whole document is "AS centric" while it should also be
>         "RS centric". These two concepts have been explained on the
>         mailing list.
>
> [FI] indeed it is centered around the AS. What's your proposition if 
> we were to change the text?
> Notice that most business scenarios today require an AS centric 
> approach. We've seen from previous discussion that it doesn't preclude 
> from enabling more privacy.

[Denis] As you write "business scenarios today require an AS centric 
approach" as long as a single company supporting one AS and several RSs 
is involved.
On the Internet, some servers are already proposing the intermediation 
of a several identity providers. This should be generalized.

You raised a good question: What's your proposition if we were to change 
the text?

Page 9. The current text is:

    *  (1) The RC attempts to call the RS (Section 10.4) to determine 
what access is needed.  The RS informs the RC that access can be granted 
through the AS.
        Note that for most situations, the RC already knows which AS to 
talk to and which kinds of access it needs.
    *  (2) The RC requests access at the AS (Section 2).
    *  (3) The AS processes the request and determines what is needed to 
fulfill the request.  The AS sends its response to the RC (Section 3).

Section 10.4 is the last section just before the acknowledgement section 
and refers to a "GNAP endpoint" while this term is not used before.
I guess that this reference is incorrect.

While I don't intend to cover all possible scenarios, I would detail the 
first steps differently:

    *  (1)    If the RC has never called the RS before, the RC calls the 
RS to determine which ASs are trusted by that RS
                and which claim types are requested for the operation he 
wishes to perform. If the RC knows the language preference(s)
                of the end-user they are indicated in this call.

    *  (2)    The RS responds by indicating one or more ASs and for each 
AS which claim types are requested.
                 The RS also indicates, in a "display" field, for each 
attribute type the reason(s) for requesting it.
                 This information is intended to be displayed to the 
end-user by the RC, if the end-user is interested to know it.

    *  (3)    The end-user may choose to see the "display" field from 
the previous message in his favourite language and then chooses which 
AS(s) to call
                 and gives his consent to call these ASs (or a subset of 
them) together for the set of a claim types requested (or a subset of 
theses claim types).
                 The RC memorises the *user consent* and the choices 
made by the user for that RS and for the requested operation.

                 Note: the end-user MUST be able to know which kind of 
end-user identifier claim is requested by an AS, in particular whether 
it is globally unique,
                            unique to the AS only, unique to the RS only 
or ephemeral (valid for that RS during a session with the AS). This has 
implications with respect to privacy.

    *  (4)    The RC authenticates to the AS(s).

    *  (5)    The RC requests one or more access tokens to each selected 
AS that should contain the selected set of claim types.
                 The target RS may be either a URL in clear text or may 
be a set of bits that is not meaningful to the AS and that will not be 
generated twice by the same RC.
                 The later case allows to hide the identity of the RS to 
the AS, but still allows the RC to target the access token to the 
appropriate RS URL. The later case
                 prevents the AS to act as Big Brother.

    *  (6)    Each AS sends back one or more access tokens to the RC.

     * (7)    The RC verifies that the claim types inserted within each 
access token correspond to the claim types that have been requested.
                 If not, the access token may be discarded. Note: In 
order to be able to perform that verification, access tokens are not 
opaque to the RC.
                 If such a verification cannot be done, the RC may 
discard the access token.

    *  (8)    The RC sends the access token(s) to the RS together with 
the operation its wishes to perform.

    *  (9)    The RS determines if the access token(s) is (are) adequate 
for the operation by examining the access token(s).

    *  (10)  If the access token(s) is (are) accepted, the RS provides a 
response to the RC for the requested operation.

The process may be optimized with the following step:

     * (0)   The RC performs a look up in the table of previous 
operations performed by the user and :

                     - if it finds the same operation for the same user 
for that RS associated with still valid access tokens, it goes to step (8).
                     - if it finds the same operation for the same user 
for that RS associated with a no more valid access token, it fetches an 
updated access token and goes to step (7).
                     - otherwise, it goes to step (1).

One important explanation: RFC 6973 (Privacy Considerations for Internet 
Protocols) mentions:

    7.2.  User Participation

        a.  User control.  What controls or consent mechanisms does the
    protocol define or require before personal data or identifiers are
    shared or exposed via the protocol ?

           (...)

    7.2.  User Participation

    d.  Preference expression.  Does the protocol provide ways for
    initiators to express individuals’ preferences to recipients or
    intermediaries with regard to the collection, use,
                                                     or disclosure of
    their personal data?

Steps (2) and step (3) are the responses to these two questions.

>         4.The document only speaks about "_the_ AS", as if only one AS
>         would exist which is obviously not the case.
>             The first access made to a RS shall be able to identify
>         which ASs are trusted by the RS. In addition, for each trusted
>         AS, the RS should be able
>             to indicate which access rights are needed to perform
>         every operation possible at that stage. For any subsequent
>         stage, the RS may also indicate
>             which attributes or access rights are needed to perform
>         each subsequent operation.
>
> [FI] There's also two related questions : a) do we allow multiple-AS 
> scenarios? b) do we allow other AS deployment options, and if so, how? 
> (like a personal AS on your phone).

[Denis] My answer is option a). The previous response illustrates how to 
handle that case. I consider that an AS is a server (the "S" from "AS" 
tells it) and as such it cannot be on a phone.

>         5."API’s documentation" versus "API discovery". Whereas the
>         API’s documentation is static and not necessarily up to date
>         or the RC software
>             is not necessarily up to date, API discovery provides real
>         time information which is necessarily up to date.
>
>             There should be an API discovery mechanism for RSs.
>
> [FI] is that our job to do that? There are already existing discovery 
> mechanisms in the wild that people could use.

[Denis] The current document includes a section 9 called "Discovery" 
(page 92). This section describes discovery functions for an AS only.
In the same way, discovery functions for a RS could be described. In 
particular, whether an initial authentication to the RS is needed or not
and, if not, which operations can be requested, which ASs are trusted by 
that RS and which claim types are requested for these operations.

>
>             Using an appropriate HTTP OPTIONS request, the RC should
>         be able to query the RS in order to know /at any point of time/:
>
>               * the operations that can be done (i.e. which methods
>                 are available on which data objects), and
>               * the access control characteristics associated with
>                 each of these operations (i.e. which ASs are being
>                 trusted by the RS
>                 and what should be the incorporated into access
>                 token(s) in terms of attributes types (and optionally
>                 attribute values)
>                 or in terms of capabilities (i.e. permissions granted).
>
>         6.The "user consent" phase has been ignored. It should be done
>         at the RS. Using information obtained from a RS, a RC should
>         be able
>             to select which AS it wants to contact and explicitly
>         agree to request the mentioned attributes to that AS.
>         Alternatively, when the user consent phase
>             is not done at the RS, it shall be done at the AS.
>
> [FI] To be discussed further. I believe an optional separate 
> Interaction Server solves this case, without disruption for standard 
> use cases (OAuth2 like) that are likely to remain.

[Denis] See the scenario with the 10 steps above. I believe that there 
is no need for an optional separate Interaction Server.

>
>         7.The content and the format of access tokens shall not be
>         considered to be opaque to the RC so that the RC can inspect it.
>             This is a matter of confidence to make sure for the RC
>         (and for the user) that no "extra" information has been
>         included by the AS into the access token.
>
> [FI] This might go a bit further than the GNAP's mandate (especially 
> if it becomes a mandatory requirement). But supposing we support 
> non-opaque tokens,
> does it preclude supporting opaque tokens? It's just a different trust 
> model, which makes sense if people agree with your premises (previous 
> items),
> but that are less relevant if people still consider the AS as the 
> central piece. Also one great thing with opaque tokens is that it 
> makes the system easier to upgrade
> (you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a 
RS-centric model. In particular, a RC should be able to verify which 
kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular 
whether it is globally unique, unique to the AS only, unique to the RS 
only or ephemeral (valid for
that RS during a session with the AS).

I suppose that the use of structured access tokens should be 
recommended. This means,in particular, that from the very beginning, we 
should incorporate a version number
inside each access token.


> One alternative way would be to allow RS call to AS for verification 
> (including revocation status) and include a checksum.

[Denis]  The RC, i.e. not the RS, should be able to perform such 
verification before presenting the access token to the RS. So this 
alternative way would not work.


>         8."Resource Owner (RO) : Authorizes the request from the RC to
>         the RS", full stop. The RO is associated with a RS, not with
>         an AS.
>             The RS can know in advance with attributes or access
>         rights are needed to grant a given operation.
>
> [FI] ideally makes sense I think, but need to check the practical 
> implications. Related to terminology #6.

[Denis] Fine.


>         9.The model should allow the use of both Access Control Lists
>         and of Capabilities Lists.
>
>               * Access control lists contain identifiers of users
>                 and/or identifiers of users groups or identity claims
>                 in relationship with an operation.
>               * Capabilities lists contains operations granted on
>                 services within a RC.
>
>              As a consequence, access tokens may contain identifiers
>         of users and/or identity claims and/or identifiers of users
>         groups and/or capabilities.
>             Whereas identifiers of users and/or identifiers of users
>         groups and/or identity claims may be managed by an AS
>         independently from RSs,
>             this is not the case for capabilities where a RO
>         associated with a RS needs to interact with the AS either in
>         advance or in real time
>             (which makes such mechanism much more complex).
>
>
> [FI] We had several discussions on this topic, and I still consider 
> the current approach to be the right path. I don't think your scenario 
> is really more complex,
> that's basically what people are doing when using a policy engine 
> (which can be as simple as casbin.org <http://casbin.org> for 
> instance) to generate access tokens.
> More fundamentally, ensuring least privilege using ACLs is known to be 
> a hard problem.

[Denis]. I am wondering what you mean when you write "I still consider 
the current approach to be the right path". I do prefer ACLs, but 
capabilities is another possibility.
I would have no problem if we say that capabilities are not supported by 
the model. :-)

10.In the case where access control lists are being used, there should 
be a possibility for a RC, for privacy reasons, to hide the identifier
>
>              of the RS to the AS (usually a URL) when requesting an
>         access token. A method able to support such feature has been
>         discussed extensively on the mailing list.
>
> [FI] depends on decision regarding previous item.

[Denis] I don't understand why it would be related to the previous item. 
An access token can be targeted to a given RS (or a given service)
irrespective whether it carries information usable for an ACL scheme or 
for a Capability scheme.

>
>         11.The text states: "Authorization Server (AS)Manages the
>         requested delegations for the RO". This is only one of two
>         possibilities.
>              The interaction between a RO and an AS should be
>         considered as an option. If a RO needs to interact, for
>         privacy reasons, it should preferably
>               interact with the RS only.
>
> [FI] The problem with working at the RS level is that it makes the 
> integration harder (we don't exactly know what people will implement).
> As a consequence, I would be in favor of an optional separation of 
> that issue in an Interact Server, which could be distinct from the AS 
> to alleviate privacy concerns.

[Denis] My point was/is about the quoted sentence: "Authorization Server 
(AS)  Manages the requested delegations for the RO" which is incorrect 
in the general case.
Furthermore, interactions with a RO create delays in the protocol, so I 
am favouring situations where a RO does not need to interact at all, in 
order to obtain a better throughput.
Anyway, I am not in favour of introducing a new entity like "an Interact 
Server".

>
>         12.The text states: "ResourceA protected API served by the RS
>         and accessed by the RC. Access to this resource is delegated
>         by the RO as part of the grant process".
>               The second part of the sentence should be deleted since
>         a RO is not necessarily involved in the grant process.
>
> [FI] Yes, more generally we should check that we can deal with user = 
> RO (usually considered as the default case) and user != RO (not often 
> carefully designed).
> I think the text already goes into much more details than OAuth2 for 
> this (cf sequences 1.4).

[Denis] My preference is to use the term "end-user" for the entity 
interacting locally with the RC.

>
>         13.The text states: "Resource Client (RC, aka
>         "client")Requests tokens from the AS and uses tokens at the RS.
>               An instance of the RC software is identified by its key,
>         which can be known to the AS prior to the first request".
>
>               This is confusing. The key does not necessarily identify
>         an instance of the RC software.
>               An instance of the RC software uses a binding key which
>         (for privacy reasons) should be dynamic but which may
>         alternatively be static.
>
> [FI] The client instance solves those issues. Might need to update the 
> way it is described in the text.

[Denis] Let us have a look at the text in a subsequent version.


>         14.For privacy reasons, calls from an RS to an AS, such as
>         token introspection, should be avoided.
>
> [FI] Token introspection (as well as other aspects related to token 
> management) should be reviewed in depth, currently we don't solve many 
> of the problems we see in the OAuth world.
> I don't believe calls from an RS to an AS should be avoided though, on 
> the contrary there might be an alternative to your proposal where the 
> RS could use a public AS endpoint for the revocation list.

[Denis]  In the single sentence above, I am not proposing a scenario 
"where the RS could use a public AS endpoint for the revocation list". 
My belief is that revocation should not be handled at all,
by using "short" validity periods for access tokens. By "short", I mean 
a duration of about 12 hours.

>
>         15.Section 2 deals with the parameters when making calls from
>         a RC to an AS. This section would need to be revisited.
>               Hereafter are only some (of many) concerns about the
>         current text. The most important is to identify which
>         parameters shall be used
>               and may be used when making a call to get an access token.
>
>              The text states: "resourcesDescribes the rights that the
>         RC is requesting for one or more access tokens to be used at
>         RS’s.
>              Section 2.1". Then after: "Each object contains a "type"
>         property that determines the type of API that the RC is calling.
>               (...)The value of this field is under the control of the AS.
>
> [FI] please provide your input to the terminology work.

  [Denis] Would you be able to post to the list where we are now, or a 
link where we can have an overview of the current proposed definitions ?


>              The value of this field should not be under the control
>         of the AS but of the RS.
>
> [FI] ultimately, the field needs to correspond to what the RS 
> provides, even if the AS is the one that generates the access token.
> Your proposal is interesting but that would put more effort on the RS 
> side, with impacts on deployability.
>
>
>              The text states: "actionsThe types of actions the RC will
>         take at the RS". This is needed when capabilities are being
>         used but not needed
>              for the other cases. Revealing actions to an AS is
>         against the user's privacy.
>
> [FI] technically this could be any alias defined by the RS. Remember 
> we discussed RS hiding strategies (ex: concealed identifier) which 
> solve that issue.

  [Denis] A key difference between an ACL scheme and a capability scheme 
is the following:

  *   for an ACL scheme, the AS does not need to have any prior
    relationship with the RS (which is an advantage from a privacy point
    of view).
  *   for a capability scheme, the capabilities needs to be defined by
    the RO of each RS, either prior to the time of the access token request
      or at latest at the time of the access token request (which
    creates a delay).


>              The text states: "locationsThe location of the RS as an
>         array of strings. These strings are typically URIs identifying
>         the location of the RS."
>
>
>              It is typically URLs (not URIs) but it may also be
>         /service names/ so that an access token can be delegated by a
>         first RS to a second RS
>              belonging to the same service without the need for the
>         first RS to request another access token.
>
> [FI] delegation from a RS to another is a topic in itself, yet to be 
> explored. I remember you sent various inputs on that, we might need to 
> review them in detail.

[Denis] Using services names instead of URLs is not necessarily related 
to "delegation from a RS to another". If a RC can get such an access 
token, it may decide
to send it to any RS belonging to that service at any point of time. So 
this is relevant for the simple case without considering "delegation 
from a RS to another RS".

Denis


>
>         Denis
>
>         -- 
>         TXAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/txauth
>         <https://www.ietf.org/mailman/listinfo/txauth>
>