Subject: [OAUTH-WG] draft-hardt-oauth-mutual-01

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jan 2018 06:39:50 -0800

I have made changes based on feedback on the call this morning. Updated
version at:

https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/

/Dick

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jan 2018 15:46:41 +0100

Hi Dick,

maybe you can re-submit the document with a new filename that matches
the updated title.

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Tue, 16 Jan 2018 10:27:52 -0700

A few thoughts on the new draft and/or reiterating comments from the call
earlier.

"[DH: should this be a URI?]" - yes, the grant type should be a URI
because, for better or worse, that's how OAuth allows for new grants
https://tools.ietf.org/html/rfc6749#section-4.5 (the device flow and JWT
authorization grant are examples that can be followed
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.4
https://tools.ietf.org/html/rfc7523#section-2.1).

I don't believe client_id should be required in 2.2. Sending/requiring
client_id or not at the token endpoint depends on the form of client
authentication that's taking place. That's how it works with the grants in
RFC6749 and other extension grants. This draft should be consistent with
all that.

I do think some discussion or description of what the response will/should
look like is needed. Things are kinda reversed in this flow with party A
'pushing' the authorization code it generated up to party B's authorization
server. It's not clear (to me anyway) how party B's AS should respond and
if/how it would be consistent with a typical token endpoint response. Maybe
echo back the access token that was just sent in? But I dunno.

The example needs some attention (grant type value is old, the basic authn
header probably isn't legal, maybe more).

On Tue, Jan 16, 2018 at 7:46 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jan 2018 11:25:29 -0800

Brian

*grant type*
Thanks for the grant type pointers.

*client_id*
The reciprocal flow by its nature is part of a code_grant flow, and I
expect that party A and party B can be reversed. Given that, it is unclear
why client_id would not be required. Would you elaborate?

*response*
Agree a response should be defined. 200 if ok, 400 if invalid. Any reason
for doing more?

/Dick

On Tue, Jan 16, 2018 at 9:27 AM, Brian Campbell <[email-masked]>
wrote:

> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jan 2018 11:39:41 -0800

02 version uploaded, and now at

Hannes: Keeping the same filename while it is an ID as it breaks the
automated process for updating. Will s/mutual/reciprocal/ if adopted and
file name is changed to reflect adoption.

On Tue, Jan 16, 2018 at 11:25 AM, Dick Hardt <[email-masked]> wrote:

> On Tue, Jan 16, 2018 at 9:27 AM, Brian Campbell <
> [email-masked]> wrote:
>
>> I do think some discussion or description of what the response
>> will/should look like is needed. Things are kinda reversed in this flow
>> with party A 'pushing' the authorization code it generated up to party B's
>> authorization server. It's not clear (to me anyway) how party B's AS should
>> respond and if/how it would be consistent with a typical token endpoint
>> response. Maybe echo back the access token that was just sent in? But I
>> dunno.
>>
>> The example needs some attention (grant type value is old, the basic
>> authn header probably isn't legal, maybe more).
>>
>>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 16 Jan 2018 14:11:05 -0700

*On client_id:*
With the authorization_code code grant (sec https://tools.ietf.org/html/
rfc6749#section-4.1.3), the client_id is "REQUIRED, if the client is not
authenticating with the authorization server as described in Section
3.2.1."  And Section 3.2.1 (see https://tools.ietf.org/html/
rfc6749#section-3.2.1) kinda describes why it is required for
unauthenticated clients:

   "A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.  In the
   "authorization_code" "grant_type" request to the token endpoint, an
   unauthenticated client MUST send its "client_id" to prevent itself
   from inadvertently accepting a code intended for a client with a
   different "client_id".  This protects the client from substitution of
   the authentication code.  (It provides no additional security for the
   protected resource.)"

So it's there to let the AS detect code substitution and protect public
clients from it. I don't think that the same situation applies to the code
that's created and pushed with this reciprocal flow.

*On the response:*
The extension grants section (see https://tools.ietf.org/html/
rfc6749#section-4.5) of OAuth says,

   "If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1
<https://tools.ietf.org/html/rfc6749#section-5.1>.  If the request
failed client
   authentication or is invalid, the authorization server returns an
   error response as described in Section 5.2
<https://tools.ietf.org/html/rfc6749#section-5.2>."

So I'd sorta expect the reciprocal code grant to try and comply with those
responses. Mostly for consistency and, while it doesn't exactly fit, for
what is already there like error codes.  Or give more detail about why it's
doing something different and how different looks (like the response body).
But maybe that's overly pedantic and just 200/400 are enough. I dunno.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jan 2018 13:25:13 -0800

Comments inline ...

On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <[email-masked]>
wrote:

>
> *On client_id:*
> With the authorization_code code grant (sec https://tools.ietf.org/html/rf
> c6749#section-4.1.3), the client_id is "REQUIRED, if the client is not
> 3.2.1."  And Section 3.2.1 (see https://tools.ietf.org/html/rf
> c6749#section-3.2.1) kinda describes why it is required for
> unauthenticated clients:
>

The client_id is linked to the access token for reciprocal, and to the
client secret. The client_id let's the AS know which secret it should be
comparing, and to verify the access token really does belong to the
client_id.

Is there a reason you would NOT want to pass the client_id?

>
>
>
> *On the response:*
> The extension grants section (see https://tools.ietf.org/html/rf
> c6749#section-4.5) of OAuth says,
>
>    token as described in Section 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>.  If the request failed client
>    error response as described in Section 5.2 <https://tools.ietf.org/html/rfc6749#section-5.2>."
>

But it is not an access token request, and I think having it look like an
access token request will be confusing to developers. It is the opposite of
an access token request. This really is a back channel version of the
Authorization Response https://tools.ietf.org/html/rfc6749#section-4.1.2,
which of course has no response codes.

 /Dick

---

From: Brian Campbell <[email-masked]>
Date: Tue, 16 Jan 2018 14:50:14 -0700

Inline also...

On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt <[email-masked]> wrote:

> Comments inline ...
>
> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
>> With the authorization_code code grant (sec
>> https://tools.ietf.org/html/rfc6749#section-4.1.3), the client_id is
>> "REQUIRED, if the client is not authenticating with the authorization
>> server as described in Section 3.2.1."  And Section 3.2.1 (see
>> https://tools.ietf.org/html/rfc6749#section-3.2.1) kinda describes why
>> it is required for unauthenticated clients:
>>
I was aiming for consistency with of the other token endpoint calls that
don't require the parameter when the client id can be found out from
whatever method the client is authenticating with. That's all. But I guess
it really doesn't hurt either so requiring it is fine too. Sorry for
dragging that all into a rabbit hole.

>> So I'd sorta expect the reciprocal code grant to try and comply with
>> those responses. Mostly for consistency and, while it doesn't exactly fit,
>> for what is already there like error codes.  Or give more detail about why
>> it's doing something different and how different looks (like the response
>> body). But maybe that's overly pedantic and just 200/400 are enough. I
>> dunno.
>>
>

Perhaps a little more explanation along those lines would be useful. I
agree with the sentiment. I was just trying to stay within the lines of the
OAuth extension framework. But, yeah, this flow is different.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jan 2018 18:05:08 -0800

and inline again ... :)

> dragging that all into a rabbit hole.

It was a good question, and worth exploring. I think there are clear
advantages from a security point of view.

> OAuth extension framework. But, yeah, this flow is different.

good suggestion to call out how reciprocal is different from other flows.
Will note that for the next draft. Thanks!