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

From: Denis <[email-masked]>
Date: Mon, 7 Dec 2020 17:11:35 +0100

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 
> <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> 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
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/txauth
>         <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 8 Dec 2020 12:14:51 +0100

Hi Denis,

Thanks for your interesting email. It would be interesting to get feedback
from others in the group, as it is a fairly different model (but which
makes sense).

My comments in red marked with [FI2]. My main concern is that a big part
can't be made mandatory as a default behavior, because it assumes too much
on the RS side. But I get the feeling that it could come as an optional
pre-negociation. I'll think about it more.

Best
Fabien

On Mon, Dec 7, 2020 at 5:11 PM Denis <[email-masked]> wrote:

> Hi Fabien,
>
> I have been quite long before responding to your email. The response took
> me occupied for a long while too.
>
> Hi Denis,
>
> We probably need to address your feedback early on, and make sure the WG
> is fine with those.
> On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault <[email-masked]>
> 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.
>>
>> Le mer. 21 oct. 2020 à 17:58, Denis <[email-masked]> 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
>>> 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.
>
> 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.
>
>    *  (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.
>    *  (1)    If the RC has never called the RS before, the RC calls the RS
> to determine which ASs are trusted by that RS
[FI2] I guess that is easy to do (even for an AS centric scenario), yet can
we assume the RS will be able to provide that functionality?
Looks like a kind of optional pre-flow ? (since a part of the flow stays
the same) : client -> AS -> token -> RS

   *  (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.
[FI2] same as before

>    *  (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
>                 The RC memorises the *user consent* and the choices made
> by the user for that RS and for the requested operation.
>
> 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
[FI2] this is similar to what is currently the display field managed by the
AS.
Here you propose a big change in spirit : the client is responsible for
managing user consent, but that seems a potentially viable option.

>    *  (4)    The RC authenticates to the AS(s).
[FI2] ok (the case of multiple ASs probably needs some fine tuning)

>    *  (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
[FI2] Aligned with what we worked on a few months ago, and that I planned
to propose as a new issue as part of the privacy effort

>    *  (6)    Each AS sends back one or more access tokens to the RC.
[FI2] ok

>                 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.
>
[FI2] Currently in the terminology, we assume an access token is opaque.
Because it makes interop and changes easier to implement (at the cost of
not knowing what they do, which is a potential trust issue).
Wouldn't be opposed to the idea of non-opaque tokens in principle, yet this
makes it mandatory to define formats, or at least allow a registry of
accepted formats (JWT etc.). Very often the existing formats are pretty
loose (the fields aren't well defined in many cases), so there would be
some significant work to make sure there's sufficient compatibility.
Wondering if that would fall into the charter's scope.

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

> for the operation by examining the access token(s).
[FI2] ok

> response to the RC for the requested operation.
[FI2] ok

>     * (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).
> 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?
>
[FI2] makes sense

> 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.
>>>
[FI2] here Francis and Tom seem to have different opinions. In practice
however, I don't see how to make it work well (meaning securely) on a phone
without a significant redesign at lower level interfaces than HTTP (as
discussed in another thread).
So your remark doesn't seem to be a problem at that stage.

> 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.
>>>
> [Denis] The current document includes a section 9 called "Discovery" (page
> 92). This section describes discovery functions for an AS only.
[FI2] Well, the spec concerns AS implementers a lot, so we can expect the
requirements to be implemented. But the RS side is way more complex, it
will be hard to ask every API vendor to change its implementation. In any
case, this means we can't assume much on the RS side, so at most it would
be optional if we were doing this.

>
>>>     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)
>>> 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
>> [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.
>
[FI2] there is if we don't want to impose the 10 steps above and still
provide some level of privacy (especially step 5).
As I explained, I don't think we can impose it in practice.

>
>>> 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,
> 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
> RS-centric model. In particular, a RC should be able to verify which kind
> of end-user identifier claim
> whether it is globally unique, unique to the AS only, unique to the RS only
> or ephemeral (valid for
[FI2] ok, see discussion on whether tokens should be opaque or not.

> 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
[FI2] then there could be a similar API for the client (cf discussion on
similarities between introspection/management APIs).

>
> 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.
>>>
> 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
> [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 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.
[FI2] likewise, I have no problem to say that ACLs are not supported ;-) In
practice also, if we generalize token binding, capabilities are less of an
issue.

> 10. In the case where access control lists are being used, there should
>      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.
>>>
[FI2]  What I meant is that depending on whether we use ACLs or not ("In
the case where access control lists are being used"), the item is important
or doesn't exist.

>
>>> 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
> 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.
>
> (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.
[FI2] the IS is possibly just a part of the AS that deals with front-end
requirements. And in case people would like to implement privacy
requirements without the 10 step process described above where the RS needs
to be compatible, separating the AS and the IS seems like a viable option.
I see no other way that doesn't add additional dependencies that we don't
control.

>
>>> 12. The text states: "Resource  A 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.
>>>
> I think the text already goes into much more details than OAuth2 for this
> (cf sequences 1.4).
>
[FI2] same for me

>
>
>>> 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.
>>>
[FI2] there's PR132 on that

>
> 14. For privacy reasons, calls from an RS to an AS, such as token
>>> introspection, should be avoided.
>>>
> 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.
>
> "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.
>
[FI2] well, that's one way of doing it, it would simplify some things. But
the problem (and a big one) is that if you have no revocation mechanism,
there's no way to implement sessions, and that's what many people are
actually trying to do.

>
>>> 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
>>>      The text states: "resources  Describes 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.
>>>
>  [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 ?
>
[FI2] yes of course.
See :
- the process related to terminology
https://mailarchive.ietf.org/arch/msg/txauth/XfeobMcrycw4TEAIOUkX0El1EWo/
- yesterday's email
https://mailarchive.ietf.org/arch/msg/txauth/fA0KjzAriINGIIzjLmR3OAHiOqs/
(my proposal, from our discussion above there are some differences, and
that will be interesting to discuss)

>
>      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.
>>>      The text states: "actions  The 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
>     or at latest at the time of the access token request (which creates a
>    delay).
>
>
>      The text states: "locations  The 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.
>>>
> [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
> this is relevant for the simple case without considering "delegation from a
> RS to another RS".
>
> Denis
>
>
>>> Denis
>>> --
>>> TXAuth mailing list
>>> [email-masked]

---

From: Denis <[email-masked]>
Date: Fri, 11 Dec 2020 12:04:12 +0100

Hi Fabien,

This is a response only to the point 7 from the "Quick review of 
draft-ietf-gnap-core-protocol-00".
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, 
you are proposing to support a Token Introspection query from the RC to 
the AS.
This does not solve the concerns of a RC that wants to make sure that 
the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an 
identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an 
identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is 
supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its 
response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily *omits *to 
present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does 
not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an 
identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a 
Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but 
the AS voluntarily *adds *a globally unique identifier.

_Conclusion_: In both cases, a globally unique identifier will be used 
by the RS without the RC or the end-user knowing it.
                       Opaque tokens are in contradiction with the 
end-user's privacy.

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.

Denis

>>             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),
>     [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
>     recommended. This means,in particular, that from the very
>     beginning, we should incorporate a version number
>>     One alternative way would be to allow RS call to AS for
>>     verification (including revocation status) and include a checksum.
>
> [FI2] then there could be a similar API for the client (cf discussion 
> on similarities between introspection/management APIs).
>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 11 Dec 2020 17:08:13 +0100

Hi Denis,

Please note that the token introspection is not a new idea, it's already
present in OAuth2 world (rfc 7662), and allows the RS to verify the access
token.

In the current version of GNAP, there is also section 6 that introduces
management endpoints, which could potentially be extended in a similar way
(currently this is not specified, the management endpoint is here for
rotation/revocation). Then the client could require more information on
what is included in the opaque token, but of course, this relies on the
assumption that the client trusts the AS. There is also the discussion on
the "resource" description in the response, that may provide a simpler
scheme (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141).

But if we assume the AS may be malevolent (which is more likely if the AS
becomes a less central point, at least for some implementations), then
indeed receiving opaque tokens wouldn't provide all the guarantees, as it
may lie on what is really in the token (too many claims for instance).
More specifically, while I recon there might be a risk which we'd rather
not have, I don't really think an opaque token is really an unmanageable
issue with privacy. Suppose someone adds a field in a JWT, most likely
you'll be able to detect that.

But suppose we go for non opaque tokens, then we'd need a way of describing
its format. Which might limit a bit the use cases if we're not careful.

I'd be interested to know what others think, since it is diverging quite a
bit from the OAuth2 world (not a bad thing in itself but still).

Fabien

On Fri, Dec 11, 2020 at 12:04 PM Denis <[email-masked]> wrote:

> In order to allow the RC to understand the content of an opaque token, you
> are proposing to support a Token Introspection query from the RC to the AS.
> This does not solve the concerns of a RC that wants to make sure that the
> access token does not contain claims that have not been requested.
>
> The AS delivers to the RC an access token that only contains an identifier
> unique to the RS. Since the access token
> is supposed to be opaque to the RS, the RS calls the AS to perform a Token
> Introspection operation. In its response,
> the AS presents an identifier that is indeed only unique to the RS but the
> AS voluntarily *adds *a globally unique identifier.
>
> *Conclusion*: In both cases, a globally unique identifier will be used by
> the RS without the RC or the end-user knowing it.
> 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.

---

From: Denis <[email-masked]>
Date: Fri, 11 Dec 2020 18:56:29 +0100

Hi Fabien,

> Hi Denis,
>
> Please note that the token introspection is not a new idea, it's 
> already present in OAuth2 world (rfc 7662), and allows the RS to 
> verify the access token.

I am pretty aware that token introspection is already present in the 
OAuth2 world (rfc 7662). :-)

In important point : RFC 7662 states "the contents of tokens are opaque 
to clients".
The text does _not_ state : "the contents of tokens are opaque to both 
clients and Resource Servers (RSs).

> In the current version of GNAP, there is also section 6 that 
> introduces management endpoints, which could potentially be extended 
> in a similar way (currently this is not specified, the management 
> endpoint is here for rotation/revocation). Then the client could 
> require more information on what is included in the opaque token, but 
> of course, this relies on the assumption that the client trusts the 
> AS. There is also the discussion on the "resource" description in the 
> response, that may provide a simpler scheme 
> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141 
> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141>).
> But if we assume the AS may be malevolent (which is more likely if the 
> AS becomes a less central point, at least for some implementations),
> then indeed receiving opaque tokens wouldn't provide all the 
> guarantees, as it may lie on what is really in the token (too many 
> claims for instance).

> More specifically, while I recon there might be a risk which we'd 
> rather not have, I don't really think an opaque token is really an 
> unmanageable issue with privacy.
> Suppose someone adds a field in a JWT, most likely you'll be able to 
> detect that.

RFC 7662 has been made available primarily for "lazy" RSs. :-)

Let us consider a case where the contents of access tokens are opaque to 
both RCs and RSs.

Let us suppose that opaque access tokens contains only a temporary 
handle to the set of claims related to the end-user, e.g. a 128 bits 
handle.

Neither the RC, nor the RS would be able to understand it and the RS 
would be forced to call back the AS.
Not only this call back will be bad in terms of the user's privacy 
because the AS will be able to know exactly when the access token has 
been used
by the end-user but it would be impossible to detect it to prevent some 
damage on the RS side.

We cannot assume that all future ASs in the world, while still providing 
the requested claims, will never deliver more attributes than the ones 
requested
by the RC and thus allow RSs (and possibly other servers) link their users.
>
> But suppose we go for non opaque tokens, then we'd need a way of 
> describing its format. Which might limit a bit the use cases if we're 
> not careful.

In OAuth 2.0, it has been possible to describe a token format (JSON Web 
Token (JWT) Profile for OAuth 2.0 Access Tokens).
I don't believe it would a "mission impossible" in this WG to describe a 
GNAP format for access tokens.

The IETF is supposed to standardize protocols at the bit level and this 
has made its success.

Denis

>
> I'd be interested to know what others think, since it is diverging 
> quite a bit from the OAuth2 world (not a bad thing in itself but still).
>
> Fabien
>
> On Fri, Dec 11, 2020 at 12:04 PM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Fabien,
>
>     In order to allow the RC to understand the content of an opaque
>     token, you are proposing to support a Token Introspection query
>     from the RC to the AS.
>     This does not solve the concerns of a RC that wants to make sure
>     that the access token does not contain claims that have not been
>     requested.
>
>     but in addition a globally unique identifier. Since the access
>     token is supposed to be opaque to the RC,
>     the RC calls the AS to perform a Token Introspection operation. In
>     its response, the AS presents an identifier
>     that is indeed only unique to the RS but the AS voluntarily *omits
>     *to present the globally unique identifier to the RC.
>
>     In the same way, if Token Introspection is supported by a RS, that
>     does not provide confidence to the end-user or to the RC.
>
>     is supposed to be opaque to the RS, the RS calls the AS to perform
>     a Token Introspection operation. In its response,
>     the AS presents an identifier that is indeed only unique to the RS
>     but the AS voluntarily *adds *a globally unique identifier.
>
>     _Conclusion_: In both cases, a globally unique identifier will be
>     used by the RS without the RC or the end-user knowing it.
>     For end-users caring about their privacy (or for systems willing
>     to protect the user's privacy), access tokens should not be
>     considered
>>>                 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.
>>>
>>>         (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
>>         [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
>>         particular whether it is globally unique, unique to the AS
>>         only, unique to the RS only or ephemeral (valid for
>>         [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.
>>
>>     [FI2] then there could be a similar API for the client (cf
>>     discussion on similarities between introspection/management APIs).
>>
>
>     -- 
>     TXAuth mailing list

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 11 Dec 2020 19:12:21 +0100

Hi Denis,

I agree that what you're saying makes sense.

I'm just asking more broadly what people think of it (and trying to balance
the risks and benefits of each approach).

Fabien

On Fri, Dec 11, 2020 at 6:56 PM Denis <[email-masked]> wrote:

> In important point : RFC 7662 states "the contents of tokens are opaque to
> clients".
> The text does *not* state : "the contents of tokens are opaque to both
> becomes a less central point, at least for some implementations),
> then indeed receiving opaque tokens wouldn't provide all the guarantees,
> as it may lie on what is really in the token (too many claims for
> instance).
>
>
> issue with privacy.
> Let us suppose that opaque access tokens contains only a temporary handle
> to the set of claims related to the end-user, e.g. a 128 bits handle.
>
> Neither the RC, nor the RS would be able to understand it and the RS would
> be forced to call back the AS.
> Not only this call back will be bad in terms of the user's privacy because
> the AS will be able to know exactly when the access token has been used
> describing its format. Which might limit a bit the use cases if we're not
> careful.
>
>> you are proposing to support a Token Introspection query from the RC to the
>> AS.
>> *Conclusion*: In both cases, a globally unique identifier will be used
>>>>>     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.
>>>>>
>>> central piece. Also one great thing with opaque tokens is that it makes the
>>> system easier to upgrade

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 13 Dec 2020 10:06:13 +0100

Hi Denis,

I created https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 to
follow up on that.

Fabien

On Fri, Dec 11, 2020 at 7:12 PM Fabien Imbault <[email-masked]>
wrote:

> I'm just asking more broadly what people think of it (and trying to
> balance the risks and benefits of each approach).
>
> Fabien
>
>> because the AS will be able to know exactly when the access token has been
>> used
>> I'd be interested to know what others think, since it is diverging quite
>> a bit from the OAuth2 world (not a bad thing in itself but still).
>>
>> Fabien
>>
>>>> if it becomes a mandatory requirement). But supposing we support non-opaque
>>>> tokens,