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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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,
>
> 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]>
> 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]> 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.
>
[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
>                 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.
>
[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
> 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.
>
[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

>     * (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.
>
[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

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

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

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

>
> 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.
>
[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
>>>       and may be used when making a call to get an access token.
>>>
>>>      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.
>>>
>> [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 ?
>
[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.
> Your proposal is interesting but that would put more effort on the RS
> side, with impacts on deployability.
>
>>
>>>      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
>    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: "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.
>>>
>> [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]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>