Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

It's not acting as a session id, as least not in the way you describe it.

A big difference is that you may encode (and encrypt) the content of the
access token, so it may for instance :
- indicate a start time and end time for the request
- specify a client instance and maybe a dynamic client posture
- and contain any other info the server may wish to embed
- plus this is bound to a key which might be rotated if needed

So it's really a token, with a content and format that is fully opaque to
the client. That answers to your question "why wouldn't it?". Because you
have a more powerful and generic mechanism using tokens.

But since you're referring to sessions, it gives you one hint on the
difference between the initial request and the continuations. Of course at
the initialization, there's no server state yet.


Le lun. 14 déc. 2020 à 23:21, Warren Parad <[e-mail]> a écrit :

> Based on the information shared, my preference would be to call the
> "access token", *session token*, I'll continue to do so in further
> communication. It's really how it's being used and now I can understand why
> conversation about cookies has come up. The "access token" is a session
> token, and session tokens have historically been transmitted via cookies,
> but in this case we are looking to transfer session token via the
> authorization header.
>
>
>>  And the AS can still look up the client’s instance information based on
>> that request, just like any RS with access to that information would be
>> able to
>
>
> If the AS can use the existing information in the request to look up the
> client to ensure it is the same party, the question for me is "Why wouldn't
> it?".
>
> What's the benefit of changing the auth mechanism between the first call
> and subsequent ones to identify the calling party?
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
>
>
> On Mon, Dec 14, 2020 at 10:26 PM Dave Tonge <[e-mail]>
> wrote:
>
>> 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.
>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>