Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback

[Fabien Imbault <[e-mail]>]

Thanks Dick, it clarifies a few points. In the core of your email, I focus
on 2 items : sub_ids and hash.

Beyond that we will also need a further description of the
possibilities/tradeoffs in section 8, to clarify for everyone (not included
here, but will be useful).

There are quite a few places where practical implementations could help us
decide, beyond theorical arguments.

Fabien

Le mar. 20 oct. 2020 à 19:45, Dick Hardt <[e-mail]> a écrit :

> Responses inline with sections without comments deleted ...
>
> On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Hi
>>
>> Some comments marked with FI.
>>
>> Fabien
>>
>> Le mar. 20 oct. 2020 à 05:27, Dick Hardt <[e-mail]> a écrit :
>>
>>> *Previous Feedback*
>>> The following items were discussed in the design team, but did not make
>>> it into the draft for WG discussion. A concern I have with many of the
>>> editor notes (which I point out) is that they are heavily biased by
>>> Justin's vision and misrepresent the options.
>>>
>>
>> FI : I'm sure we can get past hard feelings and focus on the core of the
>> concerns. The editor's notes do their best to point where discussion should
>> happen. If some of them need further clarification, we can certainly do
>> that.
>>
>
> While I am disappointed that the design team did not decide on the best
> features or XYZ and XAuth, and instead started with the XYZ doc, I was not
> trying to express any hard feelings!
>
> Reading the draft, Justin clearly has a bias to using HTTP Signing rather
> than a self contained JOSE token.
> His comments (as noted below) on 8.2 misrepresent, and do not call out the
> advantage over all the other mechanisms of being self contained.
>
> Except for at the bottom, these are points for discussion that I brought
> up in the design team that did not make it into the draft for discussion.
>
>
>>> *2.3.1 *Do we need to support symmetric keys? Most OAuth clients
>>> support a secret, not a key.
>>>
>>
>> FI : it's difficult to assume people with use public key cryptography for
>> everything. Seems to me the text is clear enough on what this implies.
>>
>
> We are requiring HTTPS -- so the client has support for asymmetric crypto.
> My point is that the editor notes should bring up this question, which I
> asked in the design team.
>

>
>>
>>> *2.4.1* identifying the user
>>> this identifier would be useful if it had properties that other opaque
>>> identifiers did not have: being globally unique. A reason developers have
>>> used the email in ID Tokens was that it was a globally unique string in
>>> contrast to the tuple of "iss" and "sub" in the ID Token which was much
>>> more complicated to add and work with in a DB. Otherwise, we are creating
>>> yet another user identifier.
>>>
>>
>> FI : OK but how would you make this a global identifier? Seems close to
>> what DIF Keri is looking for (although I find the way they're doing it is
>> overly/unnecessarily complex).
>>
>
> Lots of options. No requirement to specify how the identifier is ensured
> to be unique as it should be opaque to the client. It could be a URI that
> starts with the AS URI, or a UUID.
>
> My point is that a note on this option should be in the draft.
>

FI : so the minimal requirement on which we agree is to have an opaque
identifier. So typically this would be unique for the AS and transmitted
through a user_handle (already in the spec). The client could make its own
local mapping if it already knows something about the user.

To know more about the user, it is possible to :
- use a verifiable identity layer such as OIDC or equivalent
- (TBD) use sub_ids, based on the information already locally available at
the AS (with the limitations mentioned previously) ; or maybe we could use
an alternative/complementary design. For instance a more explicit json on
what is transmitted, or carry a correlation ID given by the client, or etc.



>
>
>> Would that replace sub_ids?
>>
>
> yes
>
>
>>
>>> *3.* The URI can be stable, and the access token is potentially
>>> superfluous. As the client is authenticating with the same key in all
>>> subsequent requests, rotation of the URI or access token may be
>>> superfluous. Having an access token for the AS seems that is used while
>>> authenticating vs the typical access token for an RS seems very confusing
>>> to a developer.
>>>
>>
>> FI : why would that be confusing?
>>
>
> Because developers don't use access tokens when accessing an OAuth AS or
> an OIDC OP?
>

>
>>
>>> Additionally, putting the access token for calls to the AS in the HTTP
>>> Authorization header precludes using the HTTP Authorization header for
>>> client authentication in 8.
>>>
>>
>> FI : that's one of the choices we need to make. But that doesn't mean
>> what is proposed is worse, it's just a different design with different
>> tradeoffs. This requires a complete discussion on section 8 (which already
>> occurred in the small group, but Justin will be able to comment).
>>
>
> Agreed. I had asked for this to be called out as a discussion point in the
> editor notes. It was not.
>
>
>>
>>> *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in
>>> the API between the client and the AS rather than an interaction that
>>> involves the user. Also, this functionality provides no protection to
>>> session fixation. The interaction reference has no value.
>>>
>>> *4.4.3 *While it is good to see an editor's note that a unique
>>> callback URL could be used, the statement "but it would not prevent an
>>> attacker from injecting an unrelated interaction reference into this
>>> channel." is misleading. This would only happen if the client did not
>>> ensure it is the same user, as that would be linked to the correct URL.
>>> Similarly, the interaction reference does not provide protection if the
>>> client does not ensure it is the same user.
>>> Using a unique callback URL would be much simpler, and appears to
>>> provide the same protection as the interaction reference and the hashing.
>>>
>>
>> FI : having to rely on the client only to ensure it is the same user is
>> precisely what you want to avoid. Hence the hashing.
>>
>
> The hashing does not protect against session fixation if the client does
> not ensure it has the same user before and after the redirect.
>
> For example, if the user has a decoupled interaction such as scanning a QR
> code on their PC with their phone, the client cannot ensure it is the same
> user coming back. An attacker can trick a user into clicking on the
> decoupled URL that the attacker obtained from the AS. The hashing does not
> protect against this.
>

FI : good point. We certainly need to handle that case correctly. We should
note that to make sure we don't forget.
That said, this comes as an additional requirement for some decoupled
interaction modes, not as a replacement of the entire scheme.

>
> /Dick
> ᐧ
>