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

[Dick Hardt <[e-mail]>]

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.



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

/Dick
ᐧ