Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 2 Jan 2020 21:53:37 +0000

Brian and others with similar use cases (Filip?):

The current text does not prohibit your approach, provided you’ve done the due diligence required by BCP 14 to go against a SHOULD NOT. Could you provide more detail on the scenarios where you have opted to use these implicit-based solutions? Is it impractical or infeasible to use an authorization code-based approach in these scenarios? If this is a particularly niche use case, then it may not be worth including in the BCP (that’s basically what SHOULD NOT is for). But if it’s more broadly applicable, then it may be worth tweaking the “unless…” clause of that paragraph.

–
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]>
Date: Saturday, December 28, 2019 at 9:47 AM
To: Brian Campbell <[email-masked]>, Torsten Lodderstedt <torsten=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

I agree with Brian's suggested text changes.
-- Mike
________________________________
From: Brian Campbell <[email-masked]>
Sent: Saturday, December 28, 2019 5:33:24 AM
To: Torsten Lodderstedt <torsten=[email-masked]>
Cc: Mike Jones <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

The requirement for replay/injection prevention at resource servers is still there in section 3.2. This change only drops it as a specific qualification on that SHOULD NOT for flows that send access tokens in the authorization response. And instead focuses that qualification on the additional risks that come with sending access tokens in the authorization response. To me, this feels more consistent.

Looking again at section 3, I'd suggest also moving the fourth paragraph of section 3.1.2 into section 3.2 so that the description of sender-constrained is in the subsection that is about sender-constraining.

On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent.

Am 28..12.2019 um 00:02 schrieb Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>:
I'm not suggesting that it should be a recommended flow. But recommending against it, as the text does now, seems overreaching and unnecessary. I know *consensus* was previously found on the text in -13 but best I can recall that discussion was mostly around Nat advocating to allow room for some future self-issued IDP type case and the conversation kind of got hung up on that.

Here's some proposed text, which I think still largely captures the intent of the BCP while not explicitly recommending against legitimate cases like the one I brought here or Nat's or something like JARM.

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or other response types issuing
   access tokens in the authorization response, unless access token injection
   in the authorization response is prevented and the aforementioned token leakage
   vectors are mitigated.

The draft already recommends sender-constrained access tokens elsewhere in the document. It doesn't need to be repeated as a qualifying condition around this SHOULD NOT.

I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other than some suggested tweaks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=3fCGjTOAD43xXLzFaw3d6VC1kY43QvBfzNwdNfDckE0%3D&reserved=0>, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations.

On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
As Brian said, we have discussed this several times and this text found consensus.

Using post reduces the attack surface but does not allow to bind the access token to the legitimate client. We are recommending sender constrained access tokens in the BCP. So recommending a flow that does not support sender constrained access tokens is a contradiction.

What do other WG members think?

Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>:
I agree with Brian. Please update the text to describe this already safe usage.
-- Mike
________________________________
From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode

We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3...1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%3D&reserved=0>, which has:

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.

I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments.

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.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342106891&sdata=qO6%2BY%2FMoef0lyx4HwNLV8ID5DguAe3XjCQyxtvoFrPo%3D&reserved=0>

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.

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: Torsten Lodderstedt <[email-masked]>
Date: Fri, 3 Jan 2020 11:33:26 +0100

Hi Brian, 

I’m on the fence regarding your proposal. 

What I like is it moves the focus onto leakage prevention and prevention of injection in the authorization response, which are the direct threats to the front channel flow. Especially token leakage prevention somehow got lost in the process. 

Beside this, your proposal does not change the meaning of the spec since sender constrained access tokens are still recommended through 3.2. 

I’m not sure it is worth the change now taking into account how much energy it has cost to come up with a consensus for this piece of text. I would encourage more WG members to share their thoughts. 

best regards,
Torsten. 

> On 2. Jan 2020, at 22:53, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>>> Am 28..12.2019 um 00:02 schrieb Brian Campbell <bcampbell=[email-masked]>:
>>> 
>>> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other thansome suggested tweaks, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations. 
>>>  
>>>  
>>> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>>>>> Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=[email-masked]>:
>>>>> 
>>>>> From: OAuth <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
>>>>> To: oauth <[email-masked]>
>>>>> That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:
>>>>>  
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>

---

From: Daniel Fett <[email-masked]>
Date: Mon, 6 Jan 2020 15:47:21 +0100

> What I like is it moves the focus onto leakage prevention and prevention of injection in the authorization response, which are the direct threats to the front channel flow. Especially token leakage…
Indeed, we should check again if leakage prevention is sufficiently
emphasized in the BCP.
> I’m not sure it is worth the change now taking into account how much energy it has cost to come up with a consensus for this piece of text. I would encourage more WG members to share their thoughts…

I'm with Annabelle on this: These kinds of exceptions are exactly what
the SHOULD NOT is for.

-Daniel

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Jan 2020 15:37:14 -0700

The scenario I described in the beginning of this thread
(response_type=token+id_token and response_mode=form_post) started out a
bit more humbly as a way to facilitate a simple and efficient cross-domain
sign-on with id_token response type and form_post response mode. Somewhat
analogous to SAML SSO using the POST binding. All the transactional data
flows through the browser in the front channel so no additional calls from
the client/RP to the AS/OP are needed. And no short-lived-transactional
data has to be shared amongst AS nodes (or between geographic locations).
There are some nice aspects to front channel flows.

Then along came the desire to have the ability to periodically refresh the
user attributes associated with the session created off of SSO at the
client/RP so as to have fresh data on which to base access control
decisions. That was done by adding an access token into the mix, hence the
response_type=token+id_token with response_mode=form_post, and the RP using
it to periodically call the user info endpoint. Of course this isn't the
same as an ID-token-only-front-channel SSO but it still retains some of the
same benefits being a mostly front channel flow.

I don't know how niche these cases are or even how often they are actually
put into use in actual deployments. But the token+id_token and form_post
flow was fresh in my mind for unrelated reasons when I was re-reviewing the
security BCP draft, which made me think again about the SHOULD NOT wording
in Section 3.1.2. And that led me to this thread and my proposed text that
would let the SHOULD for using sender-constrained access tokens stand on
its own and adjust the qualification on the SHOULD NOT for implicit style
access tokens to focus on the issues that are particular to those flows.
This doesn't actually change the underlying meaning of the draft because
sender-constrained access tokens are still a SHOULD. But I think it would
make the draft more cohesive in terms of where and why certain
recommendations are made.

On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> The current text does not prohibit your approach, provided you’ve done the
> due diligence required by BCP 14 to go against a SHOULD NOT. Could you
> provide more detail on the scenarios where you have opted to use these
> implicit-based solutions? Is it impractical or infeasible to use an
> authorization code-based approach in these scenarios? If this is a
> particularly niche use case, then it may not be worth including in the BCP
> (that’s basically what SHOULD NOT is for). But if it’s more broadly
> applicable, then it may be worth tweaking the “unless…” clause of that
> paragraph.
>
>
>
> –
>
> *From: *OAuth <[email-masked]> on behalf of Mike Jones
> <Michael.Jones=[email-masked]>
> *Date: *Saturday, December 28, 2019 at 9:47 AM
> *To: *Brian Campbell <[email-masked]>, Torsten Lodderstedt
> <torsten=[email-masked]>
> *Cc: *oauth <[email-masked]>
> *Subject: *Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
> response types + form_post response mode
>
>
>
> ------------------------------
>
> *From:* Brian Campbell <[email-masked]>
> *Sent:* Saturday, December 28, 2019 5:33:24 AM
> *To:* Torsten Lodderstedt <torsten=[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
> response types + form_post response mode
>
>
>
> The requirement for replay/injection prevention at resource servers is
> still there in section 3.2. This change only drops it as a specific
> qualification on that SHOULD NOT for flows that send access tokens in the
> authorization response. And instead focuses that qualification on the
> additional risks that come with sending access tokens in the authorization
> response. To me, this feels more consistent.
>
>
>
> Looking again at section 3, I'd suggest also moving the fourth paragraph
> of section 3.1.2 into section 3.2 so that the description of
> sender-constrained is in the subsection that is about sender-constraining.
>
>
>
> Your proposal sounds reasonable on first sight. But thinking again, it
> would mean to keep token injection prevention in authorization responses a
> requirement while dropping the requirement for replay/injection prevention
> at resource servers. To me this feels inconsistent.
>
>
>
> I'm not suggesting that it should be a recommended flow. But recommending
> against it, as the text does now, seems overreaching and unnecessary. I
> know *consensus* was previously found on the text in -13 but best I can
> recall that discussion was mostly around Nat advocating to allow room for
> some future self-issued IDP type case and the conversation kind of got hung
> up on that.
>
>
>
> Here's some proposed text, which I think still largely captures the intent
> of the BCP while not explicitly recommending against legitimate cases like
> the one I brought here or Nat's or something like JARM.
>
>
>
> The draft already recommends sender-constrained access tokens elsewhere in
> the document. It doesn't need to be repeated as a qualifying condition
> around this SHOULD NOT.
>
>
>
> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully
> is evident from several attempts at bringing/doing related work here) but I
> do worry that the recommendation in the draft is sufficiently unachievable
> to the vast majority that it might undermine the credibility of the
> document. But I get the aspirational aspect of it and, other than some
> suggested tweaks
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=3fCGjTOAD43xXLzFaw3d6VC1kY43QvBfzNwdNfDckE0%3D&reserved=0>,
> am resigned to see it stay in the document. But let's let that
> recommendation stand on its own in the document and not also tie it to
> other considerations.
>
>
>
>
>
> Using post reduces the attack surface but does not allow to bind the
> access token to the legitimate client. We are recommending sender
> constrained access tokens in the BCP. So recommending a flow that does not
> support sender constrained access tokens is a contradiction.
>
>
>
> ------------------------------
>
> *From:* OAuth <[email-masked]> on behalf of Brian Campbell
> <bcampbell=[email-masked]>
> *Sent:* Friday, December 27, 2019 11:03:30 AM
> *To:* oauth <[email-masked]>
> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response
> types + form_post response mode
>
>
>
> We have a-sometimes used scenario where a client makes an
> authorization/authentication request with a "token id_token" response type
> and "form_post" response mode (nonce is also sent and exact redirect URI
> matching is done at the AS). The access token is never exposed in any URLs
> and access token injection is prevented by the at_hash claim in the id
> token.
>
>
>
> That seems to me like a legitimate and reasonable usage scenario. However,
> it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the
> Security BCP-to-be
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3...1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%3D&reserved=0>,
> which has:
>
>
>
> I know this particular text has been discussed over and over again so I
> hate to revisit it. But based on the aforementioned scenario I think maybe
> it still doesn't quite hit the mark. Access token injection is prevented.
> The token leakage scenarios mentioned in that section are all avoided. And
> while I know sender-constrained is recommended elsewhere in the draft, it's
> not really a realistic option for the majority of deployments.
>
>
> *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.*
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342106891&sdata=qO6%2BY%2FMoef0lyx4HwNLV8ID5DguAe3XjCQyxtvoFrPo%3D&reserved=0>
>
>
> *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.*
>
>
> *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.*
>

-- 
_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: Daniel Fett <[email-masked]>
Date: Thu, 23 Jan 2020 13:25:51 +0100

After thinking about this a bit more, I think Brian's proposal makes
sense. Reading closely, it actually makes the advice stronger.
Sender-constrained tokens are a SHOULD somewhere else, so that still
applies. I will adopt the wording into the BCP (unless I hear protests).

-Daniel

Am 09.01.20 um 23:37 schrieb Brian Campbell:
> (response_type=token+id_token and response_mode=form_post) started out
> a bit more humbly as a way to facilitate a simple and efficient
> cross-domain sign-on with id_token response type and form_post
> response mode. Somewhat analogous to SAML SSO using the POST binding.
> All the transactional data flows through the browser in the front
> channel so no additional calls from the client/RP to the AS/OP are
> needed. And no short-lived-transactional data has to be shared amongst
> AS nodes (or between geographic locations).  There are some nice
> aspects to front channel flows.
>
> Then along came the desire to have the ability to periodically refresh
> the user attributes associated with the session created off of SSO at
> the client/RP so as to have fresh data on which to base access control
> decisions. That was done by adding an access token into the mix, hence
> the response_type=token+id_token with response_mode=form_post, and the
> RP using it to periodically call the user info endpoint. Of course
> this isn't the same as an ID-token-only-front-channel SSO but it still
> retains some of the same benefits being a mostly front channel flow.
>
> I don't know how niche these cases are or even how often they are
> actually put into use in actual deployments. But the token+id_token
> and form_post flow was fresh in my mind for unrelated reasons when I
> was re-reviewing the security BCP draft, which made me think again
> about the SHOULD NOT wording in Section 3.1.2. And that led me to this
> thread and my proposed text that would let the SHOULD for using
> sender-constrained access tokens stand on its own and adjust the
> qualification on the SHOULD NOT for implicit style access tokens to
> focus on the issues that are particular to those flows. This doesn't
> actually change the underlying meaning of the draft because
> sender-constrained access tokens are still a SHOULD. But I think it
> would make the draft more cohesive in terms of where and why certain
> On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle
> <[email-masked] <mailto:richanna@amazon..com>> wrote:
>
>     The current text does not prohibit your approach, provided you’ve
>     done the due diligence required by BCP 14 to go against a SHOULD
>     NOT. Could you provide more detail on the scenarios where you have
>     opted to use these implicit-based solutions? Is it impractical or
>     infeasible to use an authorization code-based approach in these
>     scenarios? If this is a particularly niche use case, then it may
>     not be worth including in the BCP (that’s basically what SHOULD
>     NOT is for). But if it’s more broadly applicable, then it may be
>     worth tweaking the “unless…” clause of that paragraph.
>
>      
>
>     – 
>
>     *From: *OAuth <[email-masked]
>     <mailto:[email-masked]>> on behalf of Mike Jones
>     <Michael.Jones=[email-masked]
>     <mailto:[email-masked]>>
>     *To: *Brian Campbell <[email-masked]
>     <mailto:[email-masked]>>, Torsten Lodderstedt
>     <torsten=[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *oauth <[email-masked] <mailto:[email-masked]>>
>     ------------------------------------------------------------------------
>
>     *From:*Brian Campbell <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Torsten Lodderstedt
>     <torsten=[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Mike Jones <[email-masked]
>     <mailto:[email-masked]>>; oauth <[email-masked]
>     <mailto:[email-masked]>>
>     The requirement for replay/injection prevention at resource
>     servers is still there in section 3.2. This change only drops it
>     as a specific qualification on that SHOULD NOT for flows that send
>     access tokens in the authorization response. And instead focuses
>     that qualification on the additional risks that come with sending
>     access tokens in the authorization response. To me, this feels
>     more consistent. 
>
>      
>
>     Looking again at section 3, I'd suggest also moving the fourth
>     paragraph of section 3.1.2 into section 3.2 so that the
>     description of sender-constrained is in the subsection that is
>     about sender-constraining. 
>
>      
>
>     On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt
>     <torsten=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Your proposal sounds reasonable on first sight. But thinking
>         again, it would mean to keep token injection prevention in
>         authorization responses a requirement while dropping the
>         requirement for replay/injection prevention at resource
>         servers. To me this feels inconsistent.
>
>
>
>             Am 28..12.2019 um 00:02 schrieb Brian Campbell
>             <bcampbell=[email-masked]
>             <mailto:[email-masked]>>:
>
>             I'm not suggesting that it should be a recommended flow.
>             But recommending against it, as the text does now, seems
>             overreaching and unnecessary. I know *consensus* was
>             previously found on the text in -13 but best I can recall
>             that discussion was mostly around Nat advocating to allow
>             room for some future self-issued IDP type case and the
>             conversation kind of got hung up on that.
>
>              
>
>             Here's some proposed text, which I think still largely
>             captures the intent of the BCP while not explicitly
>             recommending against legitimate cases like the one I
>             brought here or Nat's or something like JARM.
>
>              
>
>             The draft already recommends sender-constrained access
>             tokens elsewhere in the document. It doesn't need to be
>             repeated as a qualifying condition around this SHOULD NOT.
>
>              
>
>             I am a proponent of PoP/HoK/sender-constrained access
>             tokens (as hopefully is evident from several attempts at
>             bringing/doing related work here) but I do worry that the
>             recommendation in the draft is sufficiently unachievable
>             to the vast majority that it might undermine the
>             credibility of the document. But I get the aspirational
>             aspect of it and, other than some suggested tweaks
>             am resigned to see it stay in the document. But let's let
>             that recommendation stand on its own in the document and
>             not also tie it to other considerations. 
>
>              
>
>              
>
>             On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt
>             <torsten=[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 Using post reduces the attack surface but does not
>                 allow to bind the access token to the legitimate
>                 client. We are recommending sender constrained access
>                 tokens in the BCP. So recommending a flow that does
>                 not support sender constrained access tokens is a
>                 contradiction.
>
>                  
>
>                     Am 27.12.2019 um 21:28 schrieb Mike Jones
>                     <Michael.Jones=[email-masked]
>                     <mailto:[email-masked]>>:
>
>                     ------------------------------------------------------------------------
>
>                     *From:*OAuth <[email-masked]
>                     <mailto:[email-masked]>> on behalf of
>                     Brian Campbell
>                     <bcampbell=[email-masked]
>                     <mailto:[email-masked]>>
>                     *To:* oauth <[email-masked] <mailto:[email-masked]>>
>                     *Subject:* [EXTERNAL] [OAUTH-WG]
>                     -security-topics-13 and OIDC response types +
>                     form_post response mode
>
>                      
>
>                     We have a-sometimes used scenario where a client
>                     makes an authorization/authentication request with
>                     a "token id_token" response type and "form_post"
>                     response mode (nonce is also sent and exact
>                     redirect URI matching is done at the AS). The
>                     access token is never exposed in any URLs and
>                     access token injection is prevented by the at_hash
>                     claim in the id token.
>
>                      
>
>                     That seems to me like a legitimate and reasonable
>                     usage scenario. However, it would fall on the
>                     wrong side of the SHOULD NOT in Section 3.1.2 of
>                     the Security BCP-to-be
>                     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3....1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%3D&reserved=0>,
>                     which has:
>
>                      
>
>                     I know this particular text has been discussed
>                     over and over again so I hate to revisit it. But
>                     based on the aforementioned scenario I think maybe
>                     it still doesn't quite hit the mark. Access token
>                     injection is prevented. The token leakage
>                     scenarios mentioned in that section are all
>                     avoided. And while I know sender-constrained is
>                     recommended elsewhere in the draft, it's not
>                     really a realistic option for the majority of
>                     deployments.
>
>
>                     */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./*
>
>                     [email-masked] <mailto:[email-masked]>
>             */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./*
>
>
>     */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./*
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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./
>