Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Maybe we'd need to clarify the use cases indeed.

A big part of what you're saying is : it can be done differently. Which is
true, just not with the same expressiveness.

Beyond what we're covering here, I see at least one important service that
would directly benefit from tokens, around introspection/management api
(e.g. is the token still valid?). Here there's no information lookup about
a grant, we could just query a bloom filter if we get the authorization to
do so. I agree it's not yet included but it's perfectly feasible.

Statelessness can be good for scalability in general, at least if it
doesn't come at the expense of something important (which I don't think is
the case here).

For end developers, it's often much easier to use a URL and pass a token,
and not to have to decode the parameters (only HTTP specialists are used to
that). That's basically what made JWT successful.

As for key presentation, it's the very same mechanism used in the various
calls (cf section 2.3 and section 8). But of course when you initialize,
you have never reached the server and so there is no state, which I don't
think would be difficult to understand by client devs, especially as the
calls are already distinct.

Le lun. 14 déc. 2020 à 22:25, Dave Tonge <[e-mail]> a écrit :

> On the call I voiced my opinion that opionality should be reduced in the
> spec where possible. At the time I was in favour of access tokens being
> required. However, after reading the thread and looking again at the spec
> I'm no longer convinced.
>
> The only advantage I can see of the access token, is that it provides a
> way for the AS to be stateless, but I'm not sure how common or desirable
> that use-case is? As soon as the AS has to look some information up about a
> grant in order to continue, then there is no benefit in the access token.
> The identity of the grant can be in the url, and the authenticity of the
> client is provided by the signature.
>
> I know this is beyond the scope of this pull request, but for the majority
> of use-cases, my personal opinion is that a consistent identifier for each
> grant and a mandated REST like URL structure would be far more useful.
>
> The GNAP spec is being designed in an extensible manner that will allow a
> huge amount of use cases. Maybe in the future there will be new endpoints
> dreamed up at the AS that require tokens. But the current ones described
> in  the spec don't (create grant, continue grant, modify grant, get grant,
> cancel grant, rotate token & revoke token).
>
> I also think there is some confusion that "binding" is being used for:
>  - client authentication
>  - sender constraining access tokens
>  - http request signing
>
> If the signing mechanism is ok to authenticate the client in the first
> request, why is it not sufficient to authenticate the client on the
> continuation request?
>
> I think we need a stronger use-case for access tokens at the AS to
> warrant even its optional inclusion in the spec.
>
> On Mon, 14 Dec 2020 at 21:25, Dick Hardt <[e-mail]> wrote:
>
>> I don't understand what security risks are unique with the GNAP URI
>> relative to other API URIs that have a unique identifier in them.
>>
>> Developers can get "creative" and put "inappropriate" values in any API
>> URI they design.
>>
>> What are the security implications of using a large random value as the
>> <unique grant id>?
>>
>>
>> ᐧ
>>
>> On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki <[e-mail]> wrote:
>>
>>> Thanks for the clear description. However saying "has no security
>>> concerns" is a bold claim. Can you clarify how you will ensure that there
>>> are no security concerns with this method?
>>>
>>> My main worry with this is people will start to get "creative" with the
>>> values of the things in this URL. We've seen this over and over, everything
>>> from using plaintext data in JWT access tokens in OAuth (now the access
>>> token contents are visible to clients), to putting data in the OAuth
>>> "state" parameter (easy to exploit unless it's signed/encrypted), and I'm
>>> sure someone somewhere is putting things in the authorization code that
>>> they shouldn't.
>>>
>>> Aaron
>>>
>>>
>>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> I am proposing a URI that is straight forward, and has no
>>>> security concerns.
>>>>
>>>> For example, the URI could be:
>>>>
>>>> <as uri>/grant/<unique grant id>
>>>>
>>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f
>>>>
>>>> The routing code in the AS then is:
>>>>
>>>> router.post(      '/', grant.create);
>>>> router.get(        '/grant/:grant', grant.read);
>>>> router.post(      '/grant/:grant', grant.update);
>>>> router.delete(   '/grant/:grant', grant.delete);
>>>> router.options( '/grant/:grant', grant.options);
>>>>
>>>>
>>>> Where there is a "grant" module to manage for working with grant
>>>> requests.
>>>>
>>>> /Dick
>>>>
>>>> ps: your previous email, and this one, are making the discussion
>>>> personal. Happy to discuss privately.
>>>>
>>>> ᐧ
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: [phone]
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at *https://register.fca.org.uk/
> <https://register.fca.org.uk/>*. Moneyhub Financial Technology is
> registered in England & Wales, company registration number  06909772 .
> Moneyhub Financial Technology Limited 2019 ©
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
>