Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[John Bradley]

I agree that without a tight binding between the RS and AS we need to
revisit RS meta-data.

It is a can of worms however.


On 4/17/2020 2:39 PM, Torsten Lodderstedt wrote:
> I think the same is already true for mTLS. Solving it in an
> interoperable way would require some metadata about RS and their
> requirements re mTLS/DPoP. Shall we revitalize the idea of RS metadata?
>
>> Am 17..04.2020 um 17:37 schrieb George Fletcher
>> :
>>
>>  This brings up interesting rollout questions. Protecting just the
>> refresh_token is easy and a useful security measure (especially if
>> access tokens are short lived). However, once you start issuing DPoP
>> bound access tokens to a client, it means ALL the endpoints that
>> client invokes MUST understand DPoP and know what to do with the
>> header. Depending on how many endpoints that is, spread across N
>> teams (or even companies) this can be problematic.
>>
>> As much as I agree with Justin in regards to the security issues, it
>> may not be possible to force all RPs to update at the same time. This
>> is of course potentially solvable if the client uses unique access
>> tokens per API endpoint AND the AS knows which endpoints support DPoP
>> and which don't. The problem here is that this creates a
>> tight-coupling between RP and AS (at least for the rollout period).
>>
>> On 4/17/20 11:25 AM, Filip Skokan wrote:
>>> I completely agree Justin, as mentioned - i wondered a year ago, I don't
>>> anymore. But i'd like it to be clear that sending a DPoP proof does not
>>> necessarily mean the AS MUST issue a DPoP access token. Depending on the
>>> AS/RS relationship and configuration a regular Bearer may be still be
>>> issued and only the public client's refresh token would be constrained.
>>>
>>> Best,
>>> *Filip*
>>>
>>>
>>> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>>>
 The idea of “Continuing to work without taking advantage of sender
 constraints” is, I would argue, a security hole. Systems are allowed to
 fail security checks but still offer functionality. This is exactly the
 pattern behind allowing an unsigned JWT because you checked the “alg"
 header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
 that, but maybe we could’ve also made this more explicit within JOSE.. By
 using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
 says to the RS “either you know to look for this or you don’t know what it
 is”.

 It’s one of the problems I have with how the OAuth MTLS spec was written.
 By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
 allows things to fall through in an insecure fashion. The same argument
 against it — ease of porting existing deployments — was raised there as
 well, and it won in the end. I hope we can do better this time.

  — Justin

 On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:

 I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new 
> one.
> Would it have really helped this situation, if it'd stuck with "bearer"? 
> Or
> would it just be less obvious?
>
 If we had stuck "bearer" than i wouldn't have raised this topic, since
 existing RS would most likely ignore the cnf claim and the resource server
 calls would continue to work, obviously without taking advantage of the
 available sender check.

 As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.
 I agree.

  The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?
 :facepalm: indeed, sorry.

 S pozdravem,
 *Filip Skokan*


 On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
 wrote:

> Hi Filip,
>
> My attempts at responses to your questions/comments are inline:
>
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>
>> I've wondered about the decision to use a new scheme before
>> 
>>  but
>> this time i'd like to challenge the immediate usability of the future 
>> spec
>> for one specific case - sender constraining public client Refresh Tokens.
>>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new 
> one.
> Would it have really helped this situation, if it'd stuck with "bearer"? 
> Or
> would it just be less obvious?
>
>
>> If at all, it is going to take time for RS 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Torsten Lodderstedt]

I think the same is already true for mTLS. Solving it in an interoperable way 
would require some metadata about RS and their requirements re mTLS/DPoP. Shall 
we revitalize the idea of RS metadata?

> Am 17.04.2020 um 17:37 schrieb George Fletcher 
> :
> 
>  This brings up interesting rollout questions. Protecting just the 
> refresh_token is easy and a useful security measure (especially if access 
> tokens are short lived). However, once you start issuing DPoP bound access 
> tokens to a client, it means ALL the endpoints that client invokes MUST 
> understand DPoP and know what to do with the header. Depending on how many 
> endpoints that is, spread across N teams (or even companies) this can be 
> problematic. 
> 
> As much as I agree with Justin in regards to the security issues, it may not 
> be possible to force all RPs to update at the same time. This is of course 
> potentially solvable if the client uses unique access tokens per API endpoint 
> AND the AS knows which endpoints support DPoP and which don't. The problem 
> here is that this creates a tight-coupling between RP and AS (at least for 
> the rollout period).
> 
> On 4/17/20 11:25 AM, Filip Skokan wrote:
>> I completely agree Justin, as mentioned - i wondered a year ago, I don't
>> anymore. But i'd like it to be clear that sending a DPoP proof does not
>> necessarily mean the AS MUST issue a DPoP access token. Depending on the
>> AS/RS relationship and configuration a regular Bearer may be still be
>> issued and only the public client's refresh token would be constrained.
>> 
>> Best,
>> *Filip*
>> 
>> 
>> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>> 
>>> The idea of “Continuing to work without taking advantage of sender
>>> constraints” is, I would argue, a security hole. Systems are allowed to
>>> fail security checks but still offer functionality. This is exactly the
>>> pattern behind allowing an unsigned JWT because you checked the “alg"
>>> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
>>> that, but maybe we could’ve also made this more explicit within JOSE. By
>>> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
>>> says to the RS “either you know to look for this or you don’t know what it
>>> is”.
>>> 
>>> It’s one of the problems I have with how the OAuth MTLS spec was written.
>>> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
>>> allows things to fall through in an insecure fashion. The same argument
>>> against it — ease of porting existing deployments — was raised there as
>>> well, and it won in the end. I hope we can do better this time.
>>> 
>>>  — Justin
>>> 
>>> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>>> 
>>> I'm still somewhat on the fence as to the pros and cons of using a new
 token type and authorization scheme. But the draft has gone with a new one.
 Would it have really helped this situation, if it'd stuck with "bearer"? Or
 would it just be less obvious?
 
>>> If we had stuck "bearer" than i wouldn't have raised this topic, since
>>> existing RS would most likely ignore the cnf claim and the resource server
>>> calls would continue to work, obviously without taking advantage of the
>>> available sender check.
>>> 
>>> As I wrote the preceding rambling paragraph I am starting to think that
 more should be said in the draft about working with RSs that don't support
 DPoP. Which isn't really what you were asking about. But maybe would cover
 some of the same ground.
>>> 
>>> I agree.
>>> 
>>>  The AS is the one that does the binding (which includes checking the
 proof) so I don't see how sending two proofs would really work or help the
 situation?
>>> 
>>> :facepalm: indeed, sorry.
>>> 
>>> S pozdravem,
>>> *Filip Skokan*
>>> 
>>> 
>>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
>>> wrote:
>>> 
 Hi Filip,
 
 My attempts at responses to your questions/comments are inline:
 
 On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
 
> I've wondered about the decision to use a new scheme before
> 
>  but
> this time i'd like to challenge the immediate usability of the future spec
> for one specific case - sender constraining public client Refresh Tokens.
> 
 I'm still somewhat on the fence as to the pros and cons of using a new
 token type and authorization scheme. But the draft has gone with a new one.
 Would it have really helped this situation, if it'd stuck with "bearer"? Or
 would it just be less obvious?
 
 
> If at all, it is going to take time for RS implementations to recognize
> the new `DPoP` authorization scheme, let alone process it properly. In the
> meantime, i'd still like to have the option to bind issued public client
> refresh tokens using DPoP without affecting the access tokens. In doing so
> i 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[George Fletcher]

This brings up interesting rollout questions. Protecting just the 
refresh_token is easy and a useful security measure (especially if 
access tokens are short lived). However, once you start issuing DPoP 
bound access tokens to a client, it means ALL the endpoints that client 
invokes MUST understand DPoP and know what to do with the header. 
Depending on how many endpoints that is, spread across N teams (or even 
companies) this can be problematic.


As much as I agree with Justin in regards to the security issues, it may 
not be possible to force all RPs to update at the same time. This is of 
course potentially solvable if the client uses unique access tokens per 
API endpoint AND the AS knows which endpoints support DPoP and which 
don't. The problem here is that this creates a tight-coupling between RP 
and AS (at least for the rollout period).


On 4/17/20 11:25 AM, Filip Skokan wrote:

I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:


The idea of “Continuing to work without taking advantage of sender
constraints” is, I would argue, a security hole. Systems are allowed to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the “alg"
header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
that, but maybe we could’ve also made this more explicit within JOSE. By
using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
says to the RS “either you know to look for this or you don’t know what it
is”.

It’s one of the problems I have with how the OAuth MTLS spec was written.
By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it — ease of porting existing deployments — was raised there as
well, and it won in the end. I hope we can do better this time.

  — Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:

I'm still somewhat on the fence as to the pros and cons of using a new

token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?


If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that

more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


I agree.

  The AS is the one that does the binding (which includes checking the

proof) so I don't see how sending two proofs would really work or help the
situation?


:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
wrote:


Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:


I've wondered about the decision to use a new scheme before
 but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.


I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



If at all, it is going to take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


- Do you see this as something an AS implementation is just free to
do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.



- Should this be somehow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would

say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=Bearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan]

I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:

> The idea of “Continuing to work without taking advantage of sender
> constraints” is, I would argue, a security hole. Systems are allowed to
> fail security checks but still offer functionality. This is exactly the
> pattern behind allowing an unsigned JWT because you checked the “alg"
> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
> that, but maybe we could’ve also made this more explicit within JOSE. By
> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
> says to the RS “either you know to look for this or you don’t know what it
> is”.
>
> It’s one of the problems I have with how the OAuth MTLS spec was written.
> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
> allows things to fall through in an insecure fashion. The same argument
> against it — ease of porting existing deployments — was raised there as
> well, and it won in the end. I hope we can do better this time.
>
>  — Justin
>
> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>
> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>
> If we had stuck "bearer" than i wouldn't have raised this topic, since
> existing RS would most likely ignore the cnf claim and the resource server
> calls would continue to work, obviously without taking advantage of the
> available sender check.
>
> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't support
>> DPoP. Which isn't really what you were asking about. But maybe would cover
>> some of the same ground.
>
>
> I agree.
>
>  The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help the
>> situation?
>
>
> :facepalm: indeed, sorry.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
> wrote:
>
>> Hi Filip,
>>
>> My attempts at responses to your questions/comments are inline:
>>
>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>
>>> I've wondered about the decision to use a new scheme before
>>>  
>>> but
>>> this time i'd like to challenge the immediate usability of the future spec
>>> for one specific case - sender constraining public client Refresh Tokens.
>>>
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>>
>>>
>>> If at all, it is going to take time for RS implementations to recognize
>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>> meantime, i'd still like to have the option to bind issued public client
>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>> i get an immediate win in sender constraining the refresh tokens but not
>>> introducing a breaking change for the RS.
>>>
>>>
>>>- Do you see this as something an AS implementation is just free to
>>>do since it's both the issuer and recipient of a refresh token?
>>>
>>> That's my first thought, yes.
>>
>>
>>>
>>>- Should this be somehow baked in the draft?
>>>
>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>> say though.
>>
>> In such a case the AS could bind the RT to the given dpop proof and
>> either not bind the AT while returning token_type=Bearer or bind the AT
>> while returning token_type value DPoP. In the latter case the AT would
>> almost certainly still work as a bearer token at the RS and the client that
>> knew the RS's needs could send it as such with an `Authorization: Bearer
>> `. Or if it didn't know the RS's needs, it could start with
>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>> Bearer` at which point it could send `Authorization: Bearer `.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't support
>> DPoP. Which isn't really what you were asking about. But maybe would cover
>> some of the same ground.
>>
>>
>>
>>>
>>>- Do you think client registration metadata could be used 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Justin Richer]

The idea of “Continuing to work without taking advantage of sender constraints” 
is, I would argue, a security hole. Systems are allowed to fail security checks 
but still offer functionality. This is exactly the pattern behind allowing an 
unsigned JWT because you checked the “alg" header and it was “none” and so 
you’re OK with that. Yes, you shouldn’t do that, but maybe we could’ve also 
made this more explicit within JOSE. By using the ‘DPoP’ auth scheme, we’re 
making a clear syntactic change that says to the RS “either you know to look 
for this or you don’t know what it is”. 

It’s one of the problems I have with how the OAuth MTLS spec was written. By 
re-using the “Bearer” scheme there, I believe we’ve made a mistake that allows 
things to fall through in an insecure fashion. The same argument against it — 
ease of porting existing deployments — was raised there as well, and it won in 
the end. I hope we can do better this time.

 — Justin

> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
> 
> I'm still somewhat on the fence as to the pros and cons of using a new token 
> type and authorization scheme. But the draft has gone with a new one. Would 
> it have really helped this situation, if it'd stuck with "bearer"? Or would 
> it just be less obvious?
> 
> If we had stuck "bearer" than i wouldn't have raised this topic, since 
> existing RS would most likely ignore the cnf claim and the resource server 
> calls would continue to work, obviously without taking advantage of the 
> available sender check.
> 
> As I wrote the preceding rambling paragraph I am starting to think that more 
> should be said in the draft about working with RSs that don't support DPoP. 
> Which isn't really what you were asking about. But maybe would cover some of 
> the same ground.
> 
> I agree.
> 
>  The AS is the one that does the binding (which includes checking the proof) 
> so I don't see how sending two proofs would really work or help the situation?
> 
> :facepalm: indeed, sorry. 
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell  > wrote:
> Hi Filip, 
> 
> My attempts at responses to your questions/comments are inline:
> 
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  > wrote:
> I've wondered about the decision to use a new scheme before 
>  
> but this time i'd like to challenge the immediate usability of the future 
> spec for one specific case - sender constraining public client Refresh Tokens.
> 
> I'm still somewhat on the fence as to the pros and cons of using a new token 
> type and authorization scheme. But the draft has gone with a new one. Would 
> it have really helped this situation, if it'd stuck with "bearer"? Or would 
> it just be less obvious? 
>  
> 
> If at all, it is going to take time for RS implementations to recognize the 
> new `DPoP` authorization scheme, let alone process it properly. In the 
> meantime, i'd still like to have the option to bind issued public client 
> refresh tokens using DPoP without affecting the access tokens. In doing so i 
> get an immediate win in sender constraining the refresh tokens but not 
> introducing a breaking change for the RS.
> 
> Do you see this as something an AS implementation is just free to do since 
> it's both the issuer and recipient of a refresh token?
> That's my first thought, yes. 
>  
> Should this be somehow baked in the draft?
> I'm not sure. Do you think it needs to be? I'm not sure what it would say 
> though. 
> 
> In such a case the AS could bind the RT to the given dpop proof and either 
> not bind the AT while returning token_type=Bearer or bind the AT while 
> returning token_type value DPoP. In the latter case the AT would almost 
> certainly still work as a bearer token at the RS and the client that knew the 
> RS's needs could send it as such with an `Authorization: Bearer `. Or if 
> it didn't know the RS's needs, it could start with `Authorization: DPoP ` 
> which would get a 401 with `WWW-Authenticate: Bearer` at which point it could 
> send `Authorization: Bearer `. 
> 
> As I wrote the preceding rambling paragraph I am starting to think that more 
> should be said in the draft about working with RSs that don't support DPoP. 
> Which isn't really what you were asking about. But maybe would cover some of 
> the same ground. 
>  
>  
> Do you think client registration metadata could be used to signal such intent?
> I think it certainly could. But it seems maybe too specific to warrant 
> metadata. 
>  
> Do you think the protocol should have signals in the messages themselves to 
> say what the client wants to apply DPoP to?
> My initial thought here is no. Take the case of a client working with an AS 
> that supports DPoP and one RS that does and one RS that doesn't. I can't 
> really even think what signaling might look like there or how it could be 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Brian Campbell]

Thanks Filip for the replies. I'll add this to the growing list of todos
for a coming revision of the draft.

On Thu, Apr 16, 2020 at 2:06 AM Filip Skokan  wrote:

> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>
> If we had stuck "bearer" than i wouldn't have raised this topic, since
> existing RS would most likely ignore the cnf claim and the resource server
> calls would continue to work, obviously without taking advantage of the
> available sender check.
>
> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't support
>> DPoP. Which isn't really what you were asking about. But maybe would cover
>> some of the same ground.
>
>
> I agree.
>
>  The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help the
>> situation?
>
>
> :facepalm: indeed, sorry.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
> wrote:
>
>> Hi Filip,
>>
>> My attempts at responses to your questions/comments are inline:
>>
>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>
>>> I've wondered about the decision to use a new scheme before
>>>  
>>> but
>>> this time i'd like to challenge the immediate usability of the future spec
>>> for one specific case - sender constraining public client Refresh Tokens.
>>>
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new one.
>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>> would it just be less obvious?
>>
>>
>>>
>>> If at all, it is going to take time for RS implementations to recognize
>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>> meantime, i'd still like to have the option to bind issued public client
>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>> i get an immediate win in sender constraining the refresh tokens but not
>>> introducing a breaking change for the RS.
>>>
>>>
>>>- Do you see this as something an AS implementation is just free to
>>>do since it's both the issuer and recipient of a refresh token?
>>>
>>> That's my first thought, yes.
>>
>>
>>>
>>>- Should this be somehow baked in the draft?
>>>
>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>> say though.
>>
>> In such a case the AS could bind the RT to the given dpop proof and
>> either not bind the AT while returning token_type=Bearer or bind the AT
>> while returning token_type value DPoP. In the latter case the AT would
>> almost certainly still work as a bearer token at the RS and the client that
>> knew the RS's needs could send it as such with an `Authorization: Bearer
>> `. Or if it didn't know the RS's needs, it could start with
>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>> Bearer` at which point it could send `Authorization: Bearer `.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't support
>> DPoP. Which isn't really what you were asking about. But maybe would cover
>> some of the same ground.
>>
>>
>>
>>>
>>>- Do you think client registration metadata could be used to signal
>>>such intent?
>>>
>>> I think it certainly could. But it seems maybe too specific to warrant
>> metadata.
>>
>>
>>>
>>>- Do you think the protocol should have signals in the messages
>>>themselves to say what the client wants to apply DPoP to?
>>>
>>> My initial thought here is no. Take the case of a client working with an
>> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
>> really even think what signaling might look like there or how it could be
>> made to be generally useful.
>>
>>
>>>
>>>- What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>Do we disqualify such cases or allow for sending two proofs, one for the 
>>> AS
>>>to bind refresh tokens to, one for the RS to bind access tokens to?
>>>
>>> The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help the
>> situation?
>>
>>
>> *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 

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan]

>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>

If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.


I agree.

 The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?


:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
wrote:

> Hi Filip,
>
> My attempts at responses to your questions/comments are inline:
>
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>
>> I've wondered about the decision to use a new scheme before
>>  
>> but
>> this time i'd like to challenge the immediate usability of the future spec
>> for one specific case - sender constraining public client Refresh Tokens.
>>
>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>
>
>>
>> If at all, it is going to take time for RS implementations to recognize
>> the new `DPoP` authorization scheme, let alone process it properly. In the
>> meantime, i'd still like to have the option to bind issued public client
>> refresh tokens using DPoP without affecting the access tokens. In doing so
>> i get an immediate win in sender constraining the refresh tokens but not
>> introducing a breaking change for the RS.
>>
>>
>>- Do you see this as something an AS implementation is just free to
>>do since it's both the issuer and recipient of a refresh token?
>>
>> That's my first thought, yes.
>
>
>>
>>- Should this be somehow baked in the draft?
>>
>> I'm not sure. Do you think it needs to be? I'm not sure what it would say
> though.
>
> In such a case the AS could bind the RT to the given dpop proof and either
> not bind the AT while returning token_type=Bearer or bind the AT while
> returning token_type value DPoP. In the latter case the AT would almost
> certainly still work as a bearer token at the RS and the client that knew
> the RS's needs could send it as such with an `Authorization: Bearer `.
> Or if it didn't know the RS's needs, it could start with `Authorization:
> DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
> point it could send `Authorization: Bearer `.
>
> As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.
>
>
>
>>
>>- Do you think client registration metadata could be used to signal
>>such intent?
>>
>> I think it certainly could. But it seems maybe too specific to warrant
> metadata.
>
>
>>
>>- Do you think the protocol should have signals in the messages
>>themselves to say what the client wants to apply DPoP to?
>>
>> My initial thought here is no. Take the case of a client working with an
> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
> really even think what signaling might look like there or how it could be
> made to be generally useful.
>
>
>>
>>- What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>Do we disqualify such cases or allow for sending two proofs, one for the 
>> AS
>>to bind refresh tokens to, one for the RS to bind access tokens to?
>>
>> The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?
>
>
> *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

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Brian Campbell]

Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:

> I've wondered about the decision to use a new scheme before
>  
> but
> this time i'd like to challenge the immediate usability of the future spec
> for one specific case - sender constraining public client Refresh Tokens.
>

I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?


>
> If at all, it is going to take time for RS implementations to recognize
> the new `DPoP` authorization scheme, let alone process it properly. In the
> meantime, i'd still like to have the option to bind issued public client
> refresh tokens using DPoP without affecting the access tokens. In doing so
> i get an immediate win in sender constraining the refresh tokens but not
> introducing a breaking change for the RS.
>
>
>- Do you see this as something an AS implementation is just free to do
>since it's both the issuer and recipient of a refresh token?
>
> That's my first thought, yes.


>
>- Should this be somehow baked in the draft?
>
> I'm not sure. Do you think it needs to be? I'm not sure what it would say
though.

In such a case the AS could bind the RT to the given dpop proof and either
not bind the AT while returning token_type=Bearer or bind the AT while
returning token_type value DPoP. In the latter case the AT would almost
certainly still work as a bearer token at the RS and the client that knew
the RS's needs could send it as such with an `Authorization: Bearer `.
Or if it didn't know the RS's needs, it could start with `Authorization:
DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
point it could send `Authorization: Bearer `.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.



>
>- Do you think client registration metadata could be used to signal
>such intent?
>
> I think it certainly could. But it seems maybe too specific to warrant
metadata.


>
>- Do you think the protocol should have signals in the messages
>themselves to say what the client wants to apply DPoP to?
>
> My initial thought here is no. Take the case of a client working with an
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.


>
>- What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
>we disqualify such cases or allow for sending two proofs, one for the AS to
>bind refresh tokens to, one for the RS to bind access tokens to?
>
> The AS is the one that does the binding (which includes checking the
proof) so I don't see how sending two proofs would really work or help the
situation?

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