Re: [GNAP] Consensus Call on Continuation Request

[Dave Tonge <[e-mail]>]

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