Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Mike Jones]

Thanks for this thoughtful analysis, Aaron.  I believe you’re spot on that 
these attacks can occur “when the attacker has access to both the authorization 
code as well as the PKCE code verifier.”

   -- Mike

From: OAuth  On Behalf Of Aaron Parecki
Sent: Thursday, December 2, 2021 2:58 PM
To: Warren Parad 
Cc: Pieter Kasselman ; 
oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

Hi all, I've been giving this some more thought.

The problem occurs when the attacker has access to both the authorization code 
as well as the PKCE code verifier. The assumption being made with PKCE is that 
the first time the PKCE code verifier and authorization code are seen together 
is in the POST request to the token endpoint. That means if there is a way to 
observe this request, the attacker can complete the exchange and get an access 
token.

Pieter's writeup in the PDF describes one way that can happen, by exfiltrating 
log files. While I still agree with the sentiment in this thread that this is a 
relatively obscure condition, I also agree that it is actually something that 
can happen in the wild, especially since there are entire companies built 
around the idea of real-time log file analysis.

That said, there are other ways an attacker could get access to these two 
pieces of information. What are the different points in a request lifecycle 
that could be attacked? The beginning, the middle and the end. We've talked 
about attacking the end, which is the log file example. Attacking the middle 
involves being in the middle of the TLS connection, which we also know is 
possible with corporate network proxies and such. We haven't yet talked about 
the beginning of the request. What can observe the beginning of a request? 
Here's a concrete example:

Assume the OAuth client is a single-page app in a browser. The user is using an 
ad blocker installed as a browser extension. The ad blocker can be configured 
to observe and block network requests before they are made. If the extension is 
configured to attack a particular OAuth server, the JS client would make the 
token request containing the authorization code and PKCE code verifier, then 
the extension would be able to observe that request, block it, and ship the two 
values to the attacker's server where they can be redeemed and associated with 
the attacker's own DPoP key. Even perfectly single-use authorization codes 
don't help here either, because the original request was completely blocked.

(Sidenote: To get ahead of any counterarguments here, yes, Chrome is eventually 
migrating to their new "manifest v3" which deprecates the webRequest API that 
allows this observation in favor of a different API that lets the browser block 
requests without making the actual request data available to the extension, 
which I am assuming they are doing in no small part because of the possibility 
of what I just described. It sounds like Mozilla is going to follow suit, but I 
haven't found concrete confirmation of that. That said, it will be a while 
before these changes are rolled out and support for the (dangerous) webRequest 
API is fully dropped, so this is likely going to continue to be a potential 
attack vector for a few years at least.)

Because of the ease of deployment of a malicious browser extension, I do 
believe this is an important attack vector to consider and is worth solving. I 
am going to save any judgment on the particular dpop_jwk parameter proposal for 
a different thread, but I wanted to at least get on the same page about the 
fact that this is something worth solving first.

Aaron


On Thu, Dec 2, 2021 at 10:38 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
The only mention of sophistication is this logical fallacy:
 If this leading security company had been penetrated, it almost certainly took 
an incredibly sophisticated attack.

But it leaves out exactly what that was. And it doesn't give any insight into 
how this attack at MS would have been prevented despite the supply chain 
vulnerability based on the second point that Aaron made. If they are able to 
get the auth code, why aren't they able to get the DPoP signature? And then 
send both of these?

Further in this case, it doesn't even matter if the attacker gets the access 
token if that access token is bound to the client, because it's worthless 
without the DPoP key. That's a much more secure solution than issuing non-bound 
Bearer tokens as a response to the bound authorization code. And if Bearer 
tokens are being used instead of bound tokens, then those could still end up in 
the logs, and be exfiltrated.

In OAuth, the client already needs to authenticate with the AS, the spec is 
SHOULD, and options the client_secret already. Adding in the DPoP signature 
into the request is duplicating auth. If we don't like the client auth 
mechanisms to the AS, we should directly provide 

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Aaron Parecki]

Hi all, I've been giving this some more thought.

The problem occurs when the attacker has access to both the authorization
code as well as the PKCE code verifier. The assumption being made with PKCE
is that the first time the PKCE code verifier and authorization code are
seen together is in the POST request to the token endpoint. That means if
there is a way to observe this request, the attacker can complete the
exchange and get an access token.

Pieter's writeup in the PDF describes one way that can happen, by
exfiltrating log files. While I still agree with the sentiment in this
thread that this is a relatively obscure condition, I also agree that it is
actually something that can happen in the wild, especially since there are
entire companies built around the idea of real-time log file analysis.

That said, there are other ways an attacker could get access to these two
pieces of information. What are the different points in a request lifecycle
that could be attacked? The beginning, the middle and the end. We've talked
about attacking the end, which is the log file example. Attacking the
middle involves being in the middle of the TLS connection, which we also
know is possible with corporate network proxies and such. We haven't yet
talked about the beginning of the request. What can observe the beginning
of a request? Here's a concrete example:

Assume the OAuth client is a single-page app in a browser. The user is
using an ad blocker installed as a browser extension. The ad blocker can be
configured to observe and block network requests before they are made. If
the extension is configured to attack a particular OAuth server, the JS
client would make the token request containing the authorization code and
PKCE code verifier, then the extension would be able to observe that
request, block it, and ship the two values to the attacker's server where
they can be redeemed and associated with the attacker's own DPoP key. Even
perfectly single-use authorization codes don't help here either, because
the original request was completely blocked.

(Sidenote: To get ahead of any counterarguments here, yes, Chrome is
eventually migrating to their new "manifest v3" which deprecates the
webRequest API that allows this observation in favor of a different API
that lets the browser block requests without making the actual request data
available to the extension, which I am assuming they are doing in no small
part because of the possibility of what I just described. It sounds like
Mozilla is going to follow suit, but I haven't found concrete confirmation
of that. That said, it will be a while before these changes are rolled out
and support for the (dangerous) webRequest API is fully dropped, so this is
likely going to continue to be a potential attack vector for a few years at
least.)

Because of the ease of deployment of a malicious browser extension, I do
believe this is an important attack vector to consider and is worth
solving. I am going to save any judgment on the particular dpop_jwk
parameter proposal for a different thread, but I wanted to at least get on
the same page about the fact that this is something worth solving first.

Aaron


On Thu, Dec 2, 2021 at 10:38 AM Warren Parad  wrote:

> The only mention of sophistication is this logical fallacy:
>>
>>  If this leading security company had been penetrated, it almost
>> certainly took an incredibly sophisticated attack.
>
>
> But it leaves out exactly what that was. And it doesn't give any insight
> into how this attack at MS would have been prevented despite the supply
> chain vulnerability based on the second point that Aaron made. If they are
> able to get the auth code, why aren't they able to get the DPoP signature?
> And then send both of these?
>
> Further in this case, it doesn't even matter if the attacker gets the
> access token if that access token is bound to the client, because it's
> worthless without the DPoP key. That's a much more secure solution than
> issuing non-bound Bearer tokens as a response to the bound authorization
> code. And if Bearer tokens are being used instead of bound tokens, then
> those could still end up in the logs, and be exfiltrated.
>
> In OAuth, the client already needs to authenticate with the AS, the spec
> is SHOULD, and options the client_secret already. Adding in the DPoP
> signature into the request is duplicating auth. If we don't like the client
> auth mechanisms to the AS, we should directly provide an auth RFC
> recommending better alternatives than sending a symmetric client_secret
> back to the AS.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman  40microsoft@dmarc.ietf.org> wrote:
>
>> Thanks for the comments and engagement Warren.
>>
>>
>>
>> The attacks we described and the ideas on mitigations are born out of
>> attack vectors we are observing in the wild. 

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Warren Parad]

The only mention of sophistication is this logical fallacy:
>
>  If this leading security company had been penetrated, it almost certainly
> took an incredibly sophisticated attack.


But it leaves out exactly what that was. And it doesn't give any insight
into how this attack at MS would have been prevented despite the supply
chain vulnerability based on the second point that Aaron made. If they are
able to get the auth code, why aren't they able to get the DPoP signature?
And then send both of these?

Further in this case, it doesn't even matter if the attacker gets the
access token if that access token is bound to the client, because it's
worthless without the DPoP key. That's a much more secure solution than
issuing non-bound Bearer tokens as a response to the bound authorization
code. And if Bearer tokens are being used instead of bound tokens, then
those could still end up in the logs, and be exfiltrated.

In OAuth, the client already needs to authenticate with the AS, the spec is
SHOULD, and options the client_secret already. Adding in the DPoP signature
into the request is duplicating auth. If we don't like the client auth
mechanisms to the AS, we should directly provide an auth RFC recommending
better alternatives than sending a symmetric client_secret back to the AS.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman  wrote:

> Thanks for the comments and engagement Warren.
>
>
>
> The attacks we described and the ideas on mitigations are born out of
> attack vectors we are observing in the wild. They are not negligible. We
> are seeing a new class of very sophisticated attackers, and if you’re
> interested, this article provides good context on capability and
> sophistication of the attackers Brad Smith: Inside Microsoft during the
> SolarWinds hack (fastcompany.com)
> .
> We are sharing this with the hope that the industry will benefit from our
> experiences and incorporate it into standards and products. Attacks that
> seemed impossibly complex are not only possible, but have become probable.
>
>
>
> The proposed changes for DPoP are not meant to replace the need for
> one-time use tokens (single use tokens are preferable and we should
> continue to expect them), but instead address the limitations around
> implementing one-time use, especially at scale. The 60s window you mention
> below is sufficiently long to be exploited by these sophisticated attackers.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Warren Parad
> *Sent:* Wednesday 1 December 2021 15:29
> *To:* Pieter Kasselman 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request
> Parameter
>
>
>
> (e.g. one-time use in a certain timeframe etc).
>
>
>
> Sure but couldn't we just reduce the lifetime? Even if the token isn't one
> time use, surely the reuse time is trivially short which would prevent
> against exfiltration of the necessary security tokens to issue the attack?
>
>
>
> I feel like the simpler solution will always win, which in this case is
> one-time use tokens, then the problem is moot, right? So this only comes
> into play if you want to allow token reuse in a time window. The previously
> suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So
> we are saying that the attack surface is still too large, for the .01% of
> implementations that have multi-use tokens, and the .01% of implementations
> that use the maximum 60s reuse, and then the subset of those that aren't
> correctly scrubing their logs, and then the subset of those that have a
> vulnerability which allows for exfiltration of both those logged tokens and
> the logged PKCE verifier?
>
>
>
> Why are we making this more complicated for a majority of cases, which:
>
>- Only have single use tokens
>- Or Only have a very short lifetime
>- Or Are already correctly sanitizing their logs
>- Or Have defense in depth for their deployments.
>
> If the implementation is so insecure that none of those are happening,
> wouldn't the implementation for this functionality also be suspect for an
> opportunity for attack?
>
>
>
> I feel like we are justifying here that multi-use tokens are wrong, but
> still want a solution to use them. Once we've proven that an deployment is
> not okay with using multi-use tokens, then the conclusion should be "don't
> have multi-use tokens", not: "let's still have multi-use tokens, but come
> up with a complex way to prevent their multi-use from accidentally being
> abused".
>
>
>
> Or am I missing something that would actually make this a
> non-negligible attack vector?
>
>
>
> - Warren
>
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> 

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Pieter Kasselman]

Thanks for the comments and engagement Warren.

The attacks we described and the ideas on mitigations are born out of attack 
vectors we are observing in the wild. They are not negligible. We are seeing a 
new class of very sophisticated attackers, and if you're interested, this 
article provides good context on capability and sophistication of the attackers 
Brad Smith: Inside Microsoft during the SolarWinds hack 
(fastcompany.com).
 We are sharing this with the hope that the industry will benefit from our 
experiences and incorporate it into standards and products. Attacks that seemed 
impossibly complex are not only possible, but have become probable.

The proposed changes for DPoP are not meant to replace the need for one-time 
use tokens (single use tokens are preferable and we should continue to expect 
them), but instead address the limitations around implementing one-time use, 
especially at scale. The 60s window you mention below is sufficiently long to 
be exploited by these sophisticated attackers.

Cheers

Pieter

From: OAuth  On Behalf Of Warren Parad
Sent: Wednesday 1 December 2021 15:29
To: Pieter Kasselman 
Cc: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

(e.g. one-time use in a certain timeframe etc).

Sure but couldn't we just reduce the lifetime? Even if the token isn't one time 
use, surely the reuse time is trivially short which would prevent against 
exfiltration of the necessary security tokens to issue the attack?

I feel like the simpler solution will always win, which in this case is 
one-time use tokens, then the problem is moot, right? So this only comes into 
play if you want to allow token reuse in a time window. The previously 
suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So we 
are saying that the attack surface is still too large, for the .01% of 
implementations that have multi-use tokens, and the .01% of implementations 
that use the maximum 60s reuse, and then the subset of those that aren't 
correctly scrubing their logs, and then the subset of those that have a 
vulnerability which allows for exfiltration of both those logged tokens and the 
logged PKCE verifier?

Why are we making this more complicated for a majority of cases, which:

  *   Only have single use tokens
  *   Or Only have a very short lifetime
  *   Or Are already correctly sanitizing their logs
  *   Or Have defense in depth for their deployments.
If the implementation is so insecure that none of those are happening, wouldn't 
the implementation for this functionality also be suspect for an opportunity 
for attack?

I feel like we are justifying here that multi-use tokens are wrong, but still 
want a solution to use them. Once we've proven that an deployment is not okay 
with using multi-use tokens, then the conclusion should be "don't have 
multi-use tokens", not: "let's still have multi-use tokens, but come up with a 
complex way to prevent their multi-use from accidentally being abused".

Or am I missing something that would actually make this a non-negligible attack 
vector?

- Warren


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Hi Aaron, Neil

Thanks for the questions.

We agree that ideally authorization codes and PKCE proofs would never end up in 
log files and one-time use would be perfectly implemented.

However, in practice these artefacts do find their way into log files in 
various places and one-time use may not always be practical (e.g. one-time use 
in a certain timeframe etc).

The addition of these mitigations is not meant to replace the need for one-time 
use or good logging hygiene. Instead they provide pragmatic defence in depth 
against real attacks rather than assuming perfect implementations. We are 
deploying these mitigations and are sharing them for inclusion in DPoP to 
enable others to do the same.

Regarding the question about interrupting/intercepting the HTTPS connection, 
the attacker don't need to intercept the HTTPS connection or modify the content 
in the TLS tunnel, rather they just need to prevent the authorization code from 
being presented to the Authorization Server. It may even happen 

Re: [OAUTH-WG] JWK Thumbprint URI Specification

[David Chadwick]

  
  
On 29/11/2021 20:58, Mike Jones wrote:


  
  
  
  
Hi DW,
 
Having the OAuth WG to add a new
  registration to a registry that it controls is fairly easy. 
  Our success in motivating and accomplishing registering a new
  URI scheme may vary.
 
You can read about how the JWK Thumbprint
  RFC handles choice of hash functions in the Selection of Hash
  Function section https://datatracker.ietf.org/doc/html/rfc7638#section-3.4. 
  I would propose that we do the same.  I can plan on adding
  text to that effect in the next published draft.
  

Having read section 3.4 this seems to be a rather clunky method
  of sharing public keys. First a hashing algorithm has to be agreed
  out of band, then a somewhat painful data canonicalisation has to
  be performed. Both of these steps can lead to grief.
I would therefore propose a much simpler and less error prone
  method for sharing the public key as a URI, namely, the key holder
  takes the JSON specification of the public key as specified in RFC
  7517 then base64 encodes it. The recipient simply base 64 decodes
  the structure and ends up with the JWK. No canonicalisation is
  needed because the recipient gets the JSON object the sender
  encoded.
This can be made into a URI in a similar fashion to thumprint
  e.g.

  urn:ietf:params:oauth:jwk:




Kind regards
David



  

 
  
  Thanks,
  
  -- Mike
 

  
From: David Waite 
  
  Sent: Wednesday, November 24, 2021 2:42 PM
  To: Mike Jones 
  Cc: David Chadwick ;
  oauth@ietf.org
  Subject: Re: [OAUTH-WG] JWK Thumbprint URI
  Specification
  

 

  
I would investigate whether there are
  advantages of having this be a URN vs a URI in a new base
  scheme (e.g. jkt:bTz_1…). I haven’t seen much URN
  namespacing of dynamic values (e.g. values not being
  maintained by the entity responsible for the namespace or
  sub-spaces), and a new scheme is a terser form. 
  
  
 
  
  
Also, do you foresee any reason to
  support other hashing algorithms, since thumbprints
  themselves do not dictate a hashing algorithm? An optional
  hashing seems simple enough to add, except I don’t know of
  a hash algorithm registry to reference
  
  
 
  
  
-DW
  
  
 
  
  

  Sent from my iPhone


  


  
On Nov
  24, 2021, at 4:18 PM, Mike Jones 
  wrote:
  


  
 
The JWK Thumbprint is typically
  used as a key identifier. Yes, the key needs to be
  known by other means if you’re going to use it.  Some
  protocols work that way, which is what this spec is
  intended to enable.  For instance, the Self-Issued
  OpenID Provider (SIOP) v1 and v2 protocols send the
  public key separately in a “sub_jwk” claim.  In other
  use cases, it may already be known to the receiving
  party – for instance, from a prior discovery step.
 
It would be fine to separately also
  define a URI representation communicating an entire
  JWK, but that would be for different use cases, and
  not the goal of this (intentionally narrowly scoped)
  specification.
 
  
  Cheers,
  
  -- Mike
 

  
From: OAuth 
  On Behalf Of David Chadwick
  Sent: Wednesday, November 24, 2021 12:36 PM
  To: oauth@ietf.org
  Subject: Re: [OAUTH-WG] JWK Thumbprint URI
  Specification
  

 

  On 24/11/2021 20:07, Mike Jones
 

[OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-iss-auth-resp-04: (with COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-iss-auth-resp-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/



--
COMMENT:
--

Thank you for the work on this document, and for addressing my DISCUSS.

Many thanks to Julian Reschke for the ART ART review:
https://mailarchive.ietf.org/arch/msg/art/XfLbtK1eLb7s0Z6e_AqGgkoWny0/.

Francesca



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Francesca Palombini's Discuss on draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)

[Daniel Fett]

Hi Francesca, Warren, Brian,

we have modified the IANA Considerations section in the just uploaded
version -04 according to your feedback.

-Daniel

Am 30.11.21 um 19:42 schrieb Francesca Palombini:
>
> Hi Warren, Brian,
>
>  
>
> Thanks for your feedback, and for confirming that the semantics of the
> existing “iss” match those of the draft. In that case, I agree with
> you that the best resolution is to merge the two (so – update the
> existing registration so that it also points to this document, and
> indicates it can also appear in the authorization response).
>
>  
>
> I’ll remove my DISCUSS when the IANA update is done.
>
>  
>
> Thanks,
> Francesca
>
>  
>
> *From: *Brian Campbell 
> *Date: *Tuesday, 30 November 2021 at 19:32
> *To: *Francesca Palombini 
> *Cc: *The IESG , oauth@ietf.org ,
> draft-ietf-oauth-iss-auth-r...@ietf.org
> , oauth-cha...@ietf.org
> 
> *Subject: *Re: [OAUTH-WG] Francesca Palombini's Discuss on
> draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)
>
> I strongly believe the use of 'iss' as the parameter name here is
> correct and appropriate. This draft isn't using it for something
> different - the parameter carries an identifier for the sender of the
> message, which is consistent in the context of use with the existing
> registry entry. 
>
>  
>
> Codifying the parameter name is central to the value of this draft and
> there are existing implementations/deployments using it. Changing the
> name now would be a breaking change with significant ramifications on
> interoperability.
>
>  
>
> The organization of the registry is arguably less than ideal, yes. But
> that shouldn't force an unnecessary and costly change onto this simple
> draft that's addressing a real need. This draft should update the
> existing entry for 'iss' rather than replace it.
>
>  
>
> On Mon, Nov 29, 2021 at 2:21 PM Francesca Palombini via Datatracker
> mailto:nore...@ietf.org>> wrote:
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-oauth-iss-auth-resp-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
> 
> for more information about how to handle DISCUSS and COMMENT
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> 
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Julian Reschke for the ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/XfLbtK1eLb7s0Z6e_AqGgkoWny0/
> .
>
> I have one DISCUSS point that has to do with IANA considerations,
> and is
> hopefully easy to resolve.
>
> Francesca
>
> 1. -
>
> FP: I am sure the Designated Expert will bring this up, but "iss"
> is already
> defined as a OAuth Parameter, for authorization requests. I don't
> think it's a
> good idea to use the same parameter name, although in a different
> message of
> the exchange, for something different, as the registration defined
> in Section
> 5.2 seems to imply. I strongly recommend to change the name in
> this document.
> Or, if we can agree that the meaning is similar enough to the
> original "iss",
> merge the two IANA registrations (this would not be my preferred
> choice).
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> 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./*
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

[Daniel Fett]

Hi Murray,

thanks for your review and feedback.

We have just uploaded version -04 which includes a fix for the missing
quotation marks (which were not added by xml2rfc automatically for an
unknown reason).

-Daniel

Am 02.12.21 um 07:01 schrieb Murray Kucherawy via Datatracker:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-oauth-iss-auth-resp-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
>
>
>
> --
> COMMENT:
> --
>
> I support Francesca's DISCUSS.
>
> I also concur with Eric's observations about the shepherd writeup.  Those
> important details are missing.
>
> Please quote "iss" wherever you use it.  Every time I ran into it, my first
> thought was that it's a typo and I had to re-parse it a couple of times.
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Authorization Server Issuer Identification
Authors : Karsten Meyer zu Selhausen
  Daniel Fett
Filename: draft-ietf-oauth-iss-auth-resp-04.txt
Pages   : 12
Date: 2021-12-02

Abstract:
   This document specifies a new parameter "iss" that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization flow.  The
   "iss" parameter serves as an effective countermeasure to "mix-up
   attacks".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-iss-auth-resp-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth