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

[Fabien Imbault <[e-mail]>]

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.

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.

>
>> 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).

>
>> 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.

>
>>     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.

>
>> 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).

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

>
>> 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.

>
>> 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.

>
>> 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.

>
>> 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.

>
>> 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).

>
>> 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.

>
>> 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.

>
>> 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.

>
>>      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.

>
>>      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
>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>