Re: [OAUTH-WG] WGLC Review of PAR
Thanks to all. I incorporated the text into the upcoming next revision of the draft. > On 3. Sep 2020, at 14:14, Dave Tonge wrote: > > Looks really good to me, thanks Brian. > > On Wed, 2 Sep 2020 at 21:42, Brian Campbell > wrote: > Thanks Torsten, Taka, and Justin, > > I took the revised text from Justin and tweaked it with some typo cleanup and > minor adjustments to make what is hopefully a final proposal below. I had a > similar feeling about the last paragraph not really fitting but don't have a > better location to suggest so am just leaving it. > > 2.4. Management of Client Redirect URIs > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > values in certain circumstances, or for the authorization server to apply its > own matching semantics to the redirect_uri value presented by the client at > the authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an authorization server exactly match the redirect_uri parameter > against the set of redirect URIs previously established for a particular > client. This is a means for early detection of client impersonation attempts > and prevents token leakage and open redirection. As a downside, this can make > client management more cumbersome since the redirect URI is typically the > most volatile part of a client policy. > > The exact matching requirement MAY be relaxed by the authorization server for > a confidential client using pushed authorization requests since the > authorization server authenticates the client before the authorization > process starts and thus ensures it is interacting with the legitimate client. > The authorization server MAY allow such clients to specify redirect_uri > values that were not previously registered with the authorization server. > This will give the client more flexibility (e.g. to mint distinct redirect > URI values per authorization server at runtime) and can simplify client > management. It is at the discretion of the authorization server to apply > restrictions on supplied redirect_uri values, e.g. the authorization server > MAY require a certain URI prefix or allow only a query parameter to vary at > runtime. > > The ability to set up transaction specific redirect URIs is also useful in > situations where client ids and corresponding credentials and policies are > managed by a trusted 3rd party, e.g. via client certificates containing > client permissions. Such an externally managed client could interact with an > authorization server trusting the respective 3rd party without the need for > an additional registration step. > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer wrote: > The real conflict here is with the BCP and 2.1, both of which adopt the > stricter matching semantics for redirect URIs than 6749 does on its own. This > section would be needed to clarify how they relate to each other. That said, > I think adding some of Taka’s observations to Torsten’s text wouldn’t hurt: > > 2.4. Management of redirect_uri > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > values in certain circumstances, or for the AS to apply its own matching > semantics to the redirect_uri value presented by the client at the > authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an AS to excactly match the redirect_uri parameter against the set of > redirect URIs previously established for a particular client. This is a means > to early detect attempts to impersonate a client and prevent token leakage > and open redirection. As a downside, it makes client management more complex > since the redirect URI is typically the most volatile part of a client policy. > > This requirement MAY be relaxed by the AS if a confidential client uses > pushed authorization requests since the AS authenticates the client before > the authorization process starts and that way ensures it interacts with the > legit client. The AS MAY allow such clients to specify redirect_uri values > not previously registered with the AS. This will give the client more > flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes > client management much easier. It is at the discretion of the AS to apply > restriction on redirect_uri values, e.g. the AS MAY require a certain URI > prefix or allow only a query parameter to vary at runtime. > > I also feel like this paragraph belongs in a different section outside of > here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not > the end of the world if it stays here though as it’s a decent view on the > “why". > > The aibility to set up transaction specific redirect URIs is also useful in > situations where client ids and correspoding credentials and policies are > managed by a trusted 3rd party, e.g. via
Re: [OAUTH-WG] WGLC Review of PAR
yes. > On 3. Sep 2020, at 13:33, Brian Campbell wrote: > > Do you mean just putting the "Note:" back in front of it? WFM. > > > > On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt > wrote: > Thanks Brian! > > I suggest to put a Note: in front of the last paragraph to indicate it is > additional infomercial. > > WDYT? > > > Am 03.09.2020 um 02:29 schrieb Justin Richer : > > > > Nice work, Brian. Looks good to me! > > > > From: Brian Campbell [bcampb...@pingidentity.com] > > Sent: Wednesday, September 2, 2020 3:41 PM > > To: Justin Richer > > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth > > Subject: Re: [OAUTH-WG] WGLC Review of PAR > > > > Thanks Torsten, Taka, and Justin, > > > > I took the revised text from Justin and tweaked it with some typo cleanup > > and minor adjustments to make what is hopefully a final proposal below. I > > had a similar feeling about the last paragraph not really fitting but don't > > have a better location to suggest so am just leaving it. > > > > 2.4. Management of Client Redirect URIs > > > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > > values in certain circumstances, or for the authorization server to apply > > its own matching semantics to the redirect_uri value presented by the > > client at the authorization endpoint, the OAuth Security BCP > > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > > require an authorization server exactly match the redirect_uri parameter > > against the set of redirect URIs previously established for a particular > > client. This is a means for early detection of client impersonation > > attempts and prevents token leakage and open redirection. As a downside, > > this can make client management more cumbersome since the redirect URI is > > typically the most volatile part of a client policy. > > > > The exact matching requirement MAY be relaxed by the authorization server > > for a confidential client using pushed authorization requests since the > > authorization server authenticates the client before the authorization > > process starts and thus ensures it is interacting with the legitimate > > client. The authorization server MAY allow such clients to specify > > redirect_uri values that were not previously registered with the > > authorization server. This will give the client more flexibility (e.g. to > > mint distinct redirect URI values per authorization server at runtime) and > > can simplify client management. It is at the discretion of the > > authorization server to apply restrictions on supplied redirect_uri values, > > e.g. the authorization server MAY require a certain URI prefix or allow > > only a query parameter to vary at runtime. > > > > The ability to set up transaction specific redirect URIs is also useful in > > situations where client ids and corresponding credentials and policies are > > managed by a trusted 3rd party, e.g. via client certificates containing > > client permissions. Such an externally managed client could interact with > > an authorization server trusting the respective 3rd party without the need > > for an additional registration step. > > > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer > > mailto:jric...@mit.edu>> wrote: > > The real conflict here is with the BCP and 2.1, both of which adopt the > > stricter matching semantics for redirect URIs than 6749 does on its own. > > This section would be needed to clarify how they relate to each other. That > > said, I think adding some of Taka’s observations to Torsten’s text wouldn’t > > hurt: > > > > 2.4. Management of redirect_uri > > > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > > values in certain circumstances, or for the AS to apply its own matching > > semantics to the redirect_uri value presented by the client at the > > authorization endpoint, the OAuth Security BCP > > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > > require an AS to excactly match the redirect_uri parameter against the set > > of redirect URIs previously established for a particular client. This is a > > means to early detect attempts to impersonate a client and prevent token > > leakage and open redirection. As a downside, it makes client management > > more complex since the redirect URI is typically the most volatile part of > > a client policy. > > > > This requirement MAY be relaxed by the AS if a confidential client uses > > pushed authorization requests since the AS authenticates the client before > > the authorization process starts and that way ensures it interacts with the > > legit client. The AS MAY allow such clients to specify redirect_uri values > > not previously registered with the AS. This will give the client more > > flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes > > client management
Re: [OAUTH-WG] WGLC Review of PAR
Looks really good to me, thanks Brian. On Wed, 2 Sep 2020 at 21:42, Brian Campbell wrote: > Thanks Torsten, Taka, and Justin, > > I took the revised text from Justin and tweaked it with some typo cleanup > and minor adjustments to make what is hopefully a final proposal below. I > had a similar feeling about the last paragraph not really fitting but don't > have a better location to suggest so am just leaving it. > > 2.4. Management of Client Redirect URIs > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > values in certain circumstances, or for the authorization server to apply > its own matching semantics to the redirect_uri value presented by the > client at the authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an authorization server exactly match the redirect_uri parameter > against the set of redirect URIs previously established for a particular > client. This is a means for early detection of client impersonation > attempts and prevents token leakage and open redirection. As a downside, > this can make client management more cumbersome since the redirect URI is > typically the most volatile part of a client policy. > > The exact matching requirement MAY be relaxed by the authorization server > for a confidential client using pushed authorization requests since the > authorization server authenticates the client before the authorization > process starts and thus ensures it is interacting with the legitimate > client. The authorization server MAY allow such clients to specify > redirect_uri values that were not previously registered with the > authorization server. This will give the client more flexibility (e.g. to > mint distinct redirect URI values per authorization server at runtime) and > can simplify client management. It is at the discretion of the > authorization server to apply restrictions on supplied redirect_uri values, > e.g. the authorization server MAY require a certain URI prefix or allow > only a query parameter to vary at runtime. > > The ability to set up transaction specific redirect URIs is also useful in > situations where client ids and corresponding credentials and policies are > managed by a trusted 3rd party, e.g. via client certificates containing > client permissions. Such an externally managed client could interact with > an authorization server trusting the respective 3rd party without the need > for an additional registration step. > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer wrote: > >> The real conflict here is with the BCP and 2.1, both of which adopt the >> stricter matching semantics for redirect URIs than 6749 does on its own. >> This section would be needed to clarify how they relate to each other. That >> said, I think adding some of Taka’s observations to Torsten’s text wouldn’t >> hurt: >> >> 2.4. Management of redirect_uri >> >> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri >> values in certain circumstances, or for the AS to apply its own matching >> semantics to the redirect_uri value presented by the client at the >> authorization endpoint, the OAuth Security BCP >> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] >> require an AS to excactly match the redirect_uri parameter against the set >> of redirect URIs previously established for a particular client. This is a >> means to early detect attempts to impersonate a client and prevent token >> leakage and open redirection. As a downside, it makes client management >> more complex since the redirect URI is typically the most volatile part of >> a client policy. >> >> This requirement MAY be relaxed by the AS if a confidential client uses >> pushed authorization requests since the AS authenticates the client before >> the authorization process starts and that way ensures it interacts with the >> legit client. The AS MAY allow such clients to specify redirect_uri values >> not previously registered with the AS. This will give the client more >> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes >> client management much easier. It is at the discretion of the AS to apply >> restriction on redirect_uri values, e.g. the AS MAY require a certain URI >> prefix or allow only a query parameter to vary at runtime. >> >> I also feel like this paragraph belongs in a different section outside of >> here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not >> the end of the world if it stays here though as it’s a decent view on the >> “why". >> >> >> The aibility to set up transaction specific redirect URIs is also useful >> in situations where client ids and correspoding credentials and policies >> are managed by a trusted 3rd party, e.g. via client certifiates containing >> client permissions. Such an externally managed client could interact with >> an AS trusting the respective 3rd party without the
Re: [OAUTH-WG] WGLC Review of PAR
Do you mean just putting the "Note:" back in front of it? WFM. On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt wrote: > Thanks Brian! > > I suggest to put a Note: in front of the last paragraph to indicate it is > additional infomercial. > > WDYT? > > > Am 03.09.2020 um 02:29 schrieb Justin Richer : > > > > Nice work, Brian. Looks good to me! > > > > From: Brian Campbell [bcampb...@pingidentity.com] > > Sent: Wednesday, September 2, 2020 3:41 PM > > To: Justin Richer > > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth > > Subject: Re: [OAUTH-WG] WGLC Review of PAR > > > > Thanks Torsten, Taka, and Justin, > > > > I took the revised text from Justin and tweaked it with some typo > cleanup and minor adjustments to make what is hopefully a final proposal > below. I had a similar feeling about the last paragraph not really fitting > but don't have a better location to suggest so am just leaving it. > > > > 2.4. Management of Client Redirect URIs > > > > While OAuth 2.0 [RFC6749] allows clients to use unregistered > redirect_uri values in certain circumstances, or for the authorization > server to apply its own matching semantics to the redirect_uri value > presented by the client at the authorization endpoint, the OAuth Security > BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 > [I-D.ietf-oauth-v2-1] require an authorization server exactly match the > redirect_uri parameter against the set of redirect URIs previously > established for a particular client. This is a means for early detection of > client impersonation attempts and prevents token leakage and open > redirection. As a downside, this can make client management more cumbersome > since the redirect URI is typically the most volatile part of a client > policy. > > > > The exact matching requirement MAY be relaxed by the authorization > server for a confidential client using pushed authorization requests since > the authorization server authenticates the client before the authorization > process starts and thus ensures it is interacting with the legitimate > client. The authorization server MAY allow such clients to specify > redirect_uri values that were not previously registered with the > authorization server. This will give the client more flexibility (e.g. to > mint distinct redirect URI values per authorization server at runtime) and > can simplify client management. It is at the discretion of the > authorization server to apply restrictions on supplied redirect_uri values, > e.g. the authorization server MAY require a certain URI prefix or allow > only a query parameter to vary at runtime. > > > > The ability to set up transaction specific redirect URIs is also useful > in situations where client ids and corresponding credentials and policies > are managed by a trusted 3rd party, e.g. via client certificates containing > client permissions. Such an externally managed client could interact with > an authorization server trusting the respective 3rd party without the need > for an additional registration step. > > > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer jric...@mit.edu>> wrote: > > The real conflict here is with the BCP and 2.1, both of which adopt the > stricter matching semantics for redirect URIs than 6749 does on its own. > This section would be needed to clarify how they relate to each other. That > said, I think adding some of Taka’s observations to Torsten’s text wouldn’t > hurt: > > > > 2.4. Management of redirect_uri > > > > While OAuth 2.0 [RFC6749] allows clients to use unregistered > redirect_uri values in certain circumstances, or for the AS to apply its > own matching semantics to the redirect_uri value presented by the client at > the authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an AS to excactly match the redirect_uri parameter against the set > of redirect URIs previously established for a particular client. This is a > means to early detect attempts to impersonate a client and prevent token > leakage and open redirection. As a downside, it makes client management > more complex since the redirect URI is typically the most volatile part of > a client policy. > > > > This requirement MAY be relaxed by the AS if a confidential client uses > pushed authorization requests since the AS authenticates the client before > the authorization process starts and that way ensures it interacts with the > legit client. The AS MAY allow such clients to specify redirect_uri values > not previously registered with the AS. This will give the client more > flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes > client management much easier. It is at the discretion of the AS to apply > restriction on redirect_uri values, e.g. the AS MAY require a certain URI > prefix or allow only a query parameter to vary at runtime. > > > > I also feel like this paragraph belongs in a
Re: [OAUTH-WG] WGLC Review of PAR
Thanks Brian! I suggest to put a Note: in front of the last paragraph to indicate it is additional infomercial. WDYT? > Am 03.09.2020 um 02:29 schrieb Justin Richer : > > Nice work, Brian. Looks good to me! > > From: Brian Campbell [bcampb...@pingidentity.com] > Sent: Wednesday, September 2, 2020 3:41 PM > To: Justin Richer > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth > Subject: Re: [OAUTH-WG] WGLC Review of PAR > > Thanks Torsten, Taka, and Justin, > > I took the revised text from Justin and tweaked it with some typo cleanup and > minor adjustments to make what is hopefully a final proposal below. I had a > similar feeling about the last paragraph not really fitting but don't have a > better location to suggest so am just leaving it. > > 2.4. Management of Client Redirect URIs > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > values in certain circumstances, or for the authorization server to apply its > own matching semantics to the redirect_uri value presented by the client at > the authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an authorization server exactly match the redirect_uri parameter > against the set of redirect URIs previously established for a particular > client. This is a means for early detection of client impersonation attempts > and prevents token leakage and open redirection. As a downside, this can make > client management more cumbersome since the redirect URI is typically the > most volatile part of a client policy. > > The exact matching requirement MAY be relaxed by the authorization server for > a confidential client using pushed authorization requests since the > authorization server authenticates the client before the authorization > process starts and thus ensures it is interacting with the legitimate client. > The authorization server MAY allow such clients to specify redirect_uri > values that were not previously registered with the authorization server. > This will give the client more flexibility (e.g. to mint distinct redirect > URI values per authorization server at runtime) and can simplify client > management. It is at the discretion of the authorization server to apply > restrictions on supplied redirect_uri values, e.g. the authorization server > MAY require a certain URI prefix or allow only a query parameter to vary at > runtime. > > The ability to set up transaction specific redirect URIs is also useful in > situations where client ids and corresponding credentials and policies are > managed by a trusted 3rd party, e.g. via client certificates containing > client permissions. Such an externally managed client could interact with an > authorization server trusting the respective 3rd party without the need for > an additional registration step. > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer > mailto:jric...@mit.edu>> wrote: > The real conflict here is with the BCP and 2.1, both of which adopt the > stricter matching semantics for redirect URIs than 6749 does on its own. This > section would be needed to clarify how they relate to each other. That said, > I think adding some of Taka’s observations to Torsten’s text wouldn’t hurt: > > 2.4. Management of redirect_uri > > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri > values in certain circumstances, or for the AS to apply its own matching > semantics to the redirect_uri value presented by the client at the > authorization endpoint, the OAuth Security BCP > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] > require an AS to excactly match the redirect_uri parameter against the set of > redirect URIs previously established for a particular client. This is a means > to early detect attempts to impersonate a client and prevent token leakage > and open redirection. As a downside, it makes client management more complex > since the redirect URI is typically the most volatile part of a client policy. > > This requirement MAY be relaxed by the AS if a confidential client uses > pushed authorization requests since the AS authenticates the client before > the authorization process starts and that way ensures it interacts with the > legit client. The AS MAY allow such clients to specify redirect_uri values > not previously registered with the AS. This will give the client more > flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes > client management much easier. It is at the discretion of the AS to apply > restriction on redirect_uri values, e.g. the AS MAY require a certain URI > prefix or allow only a query parameter to vary at runtime. > > I also feel like this paragraph belongs in a different section outside of > here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not > the end of the world if
