Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[David Waite]

My understanding:

The proof-of-possession needs to have a limited destination to prevent replay 
against other resources. Similar to resource indicators and to distributed 
OAuth, the client is expected to use a resource URL view of the world rather 
than an access-token-specific audience or scoped view of the world. (And 
method, because thats cheap to do.)

HTTP request signing has a high degree of complexity, and has had several 
iterations each with their own strengths and weaknesses (which I know you are 
intimately familiar with!)

There is nothing currently to prevent other specification(s) adding extra 
key/values corresponding to a header set and hash, query hash, body hash, and 
so on. If that holds true in the final specification, then an environment could 
require those keys to be present, and then leverage DPoP for both 
proof-of-possession and non-repudiation. 

-DW

> On Apr 9, 2019, at 8:36 PM, Justin Richer  wrote:
> 
> Then why include the request at all? Simpler to just sign a nonce and send 
> those, then.
> 
> — Justin
> 
>> On Apr 9, 2019, at 7:05 PM, Brian Campbell > > wrote:
>> 
>> The thought/intent is that it's really about proof-of-possession rather than 
>> protecting the request. So the signature is over a minimal set of 
>> information.
>> 
>> On Mon, Apr 8, 2019 at 5:41 PM Justin Richer > > wrote:
>> Corollary to this, are there thoughts of header protection under this 
>> method, and the associated issue of header modification?
>> 
>> — Justin
>> 
>>> On Apr 8, 2019, at 7:23 PM, Phil Hunt >> > wrote:
>>> 
>>> Question. One of the issues that Justin Richer’s signing draft tried to 
>>> address was url modification by tls terminators/load balencers/proxies/api 
>>> gateways etc. 
>>> 
>>> How do you see this issue in dpop? Is it a problem? 
>>> 
>>> Phil
>>> 
>>> On Apr 3, 2019, at 9:01 AM, George Fletcher 
>>> >> > wrote:
>>> 
 Perfect! Thank you! A couple comments on version 01...
 
POST /token HTTP/1.1
Host: server.example.com 
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
 
grant_type=authorization_code
=SplxlOBeZQQYbYS6WxSbIA
_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
(remainder of JWK omitted for brevity)
 
 I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
 header...
 
 Also, there is no discussion of the DPoP-Binding header outside of the 
 token request, but I suspect that is the desired way to communicate the 
 DPoP-Proof to the RS.
 
 Possibly an example in the session for presenting the token to the RS 
 would help.
 
 Thanks,
 George
 
 On 4/3/19 11:39 AM, Daniel Fett wrote:
> This is fixed in -01:
> 
> https://tools.ietf.org/html/draft-fett-oauth-dpop-01 
> 
> 
> -Daniel
> 
> Am 03.04.19 um 17:28 schrieb George Fletcher:
>> A quick question regarding...
>> 
>>o  "http_uri": The HTTP URI used for the request, without query and
>>   fragment parts (REQUIRED).
>> 
>> Is 'without' supposed to be 'with' ? The example shows the http_uri 
>> *with* the query parameters :)
>> 
>> On 3/28/19 6:17 AM, Daniel Fett wrote:
>>> Hi all,
>>> 
>>> I published the first version of the DPoP draft at 
>>> https://tools.ietf.org/html/draft-fett-oauth-dpop-00 
>>> 
>>> Abstract
>>> 
>>>This document defines a sender-constraint mechanism for OAuth 2.0
>>>access tokens and refresh tokens utilizing an application-level
>>>proof-of-possession mechanism based on public/private key pairs.
>>> 
>>> Thanks for the feedback I received so far from John, Mike, Torsten, and 
>>> others during today's session or before!
>>> 
>>> If you find any errors I would welcome if you open an issue in the 
>>> GitHub repository at https://github.com/webhamster/draft-dpop 
>>> 

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Justin Richer]

Then why include the request at all? Simpler to just sign a nonce and send 
those, then.

— Justin

On Apr 9, 2019, at 7:05 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

The thought/intent is that it's really about proof-of-possession rather than 
protecting the request. So the signature is over a minimal set of information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Corollary to this, are there thoughts of header protection under this method, 
and the associated issue of header modification?

— Justin

On Apr 8, 2019, at 7:23 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

Question. One of the issues that Justin Richer’s signing draft tried to address 
was url modification by tls terminators/load balencers/proxies/api gateways etc.

How do you see this issue in dpop? Is it a problem?

Phil

On Apr 3, 2019, at 9:01 AM, George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org>> 
wrote:

Perfect! Thank you! A couple comments on version 01...


   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   =SplxlOBeZQQYbYS6WxSbIA
   _uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)

I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...

Also, there is no discussion of the DPoP-Binding header outside of the token 
request, but I suspect that is the desired way to communicate the DPoP-Proof to 
the RS.

Possibly an example in the session for presenting the token to the RS would 
help.

Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:
This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
A quick question regarding...


   o  "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the 
query parameters :)

On 3/28/19 6:17 AM, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.



Thanks for the feedback I received so far from John, Mike, Torsten, and others 
during today's session or before!

If you find any errors I would welcome if you open an issue in the GitHub 
repository at 
https://github.com/webhamster/draft-dpop

- Daniel



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




___
OAuth mailing list
OAuth@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk=
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
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 

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Brian Campbell]

The thought/intent is that it's really about proof-of-possession rather
than protecting the request. So the signature is over a minimal set of
information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer  wrote:

> Corollary to this, are there thoughts of header protection under this
> method, and the associated issue of header modification?
>
> — Justin
>
> On Apr 8, 2019, at 7:23 PM, Phil Hunt  wrote:
>
> Question. One of the issues that Justin Richer’s signing draft tried to
> address was url modification by tls terminators/load balencers/proxies/api
> gateways etc.
>
> How do you see this issue in dpop? Is it a problem?
>
> Phil
>
> On Apr 3, 2019, at 9:01 AM, George Fletcher <
> gffletch=40aol@dmarc.ietf.org> wrote:
>
> Perfect! Thank you! A couple comments on version 01...
>
>POST /token HTTP/1.1
>Host: server.example.com
>Content-Type: application/x-www-form-urlencoded;charset=UTF-8
>DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>
>grant_type=authorization_code
>=SplxlOBeZQQYbYS6WxSbIA
>_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>(remainder of JWK omitted for brevity)
>
>
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding
> header...
>
> Also, there is no discussion of the DPoP-Binding header outside of the
> token request, but I suspect that is the desired way to communicate the
> DPoP-Proof to the RS.
>
> Possibly an example in the session for presenting the token to the RS
> would help.
>
> Thanks,
> George
>
> On 4/3/19 11:39 AM, Daniel Fett wrote:
>
> This is fixed in -01:
>
> https://tools.ietf.org/html/draft-fett-oauth-dpop-01
> 
>
> -Daniel
>
> Am 03.04.19 um 17:28 schrieb George Fletcher:
>
> A quick question regarding...
>
>o  "http_uri": The HTTP URI used for the request, without query and
>   fragment parts (REQUIRED).
>
>
> Is 'without' supposed to be 'with' ? The example shows the http_uri *with*
> the query parameters :)
>
> On 3/28/19 6:17 AM, Daniel Fett wrote:
>
> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> 
>
> Abstract
>
>This document defines a sender-constraint mechanism for OAuth 2.0
>access tokens and refresh tokens utilizing an application-level
>proof-of-possession mechanism based on public/private key pairs.
>
>
> Thanks for the feedback I received so far from John, Mike, Torsten, and
> others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
> 
>
> - Daniel
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk=
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Justin Richer]

Corollary to this, are there thoughts of header protection under this method, 
and the associated issue of header modification?

— Justin

On Apr 8, 2019, at 7:23 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

Question. One of the issues that Justin Richer’s signing draft tried to address 
was url modification by tls terminators/load balencers/proxies/api gateways etc.

How do you see this issue in dpop? Is it a problem?

Phil

On Apr 3, 2019, at 9:01 AM, George Fletcher 
mailto:gffletch=40aol@dmarc.ietf.org>> 
wrote:

Perfect! Thank you! A couple comments on version 01...


   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   =SplxlOBeZQQYbYS6WxSbIA
   _uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)

I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...

Also, there is no discussion of the DPoP-Binding header outside of the token 
request, but I suspect that is the desired way to communicate the DPoP-Proof to 
the RS.

Possibly an example in the session for presenting the token to the RS would 
help.

Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:
This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
A quick question regarding...


   o  "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the 
query parameters :)

On 3/28/19 6:17 AM, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.



Thanks for the feedback I received so far from John, Mike, Torsten, and others 
during today's session or before!

If you find any errors I would welcome if you open an issue in the GitHub 
repository at 
https://github.com/webhamster/draft-dpop

- Daniel


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




___
OAuth mailing list
OAuth@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk=
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Phil Hunt]

Question. One of the issues that Justin Richer’s signing draft tried to address 
was url modification by tls terminators/load balencers/proxies/api gateways 
etc. 

How do you see this issue in dpop? Is it a problem? 

Phil

> On Apr 3, 2019, at 9:01 AM, George Fletcher 
>  wrote:
> 
> Perfect! Thank you! A couple comments on version 01...
> 
>POST /token HTTP/1.1
>Host: server.example.com
>Content-Type: application/x-www-form-urlencoded;charset=UTF-8
>DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
> 
>grant_type=authorization_code
>=SplxlOBeZQQYbYS6WxSbIA
>_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>(remainder of JWK omitted for brevity)
> 
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
> header...
> 
> Also, there is no discussion of the DPoP-Binding header outside of the token 
> request, but I suspect that is the desired way to communicate the DPoP-Proof 
> to the RS.
> 
> Possibly an example in the session for presenting the token to the RS would 
> help.
> 
> Thanks,
> George
> 
>> On 4/3/19 11:39 AM, Daniel Fett wrote:
>> This is fixed in -01:
>> 
>> https://tools.ietf.org/html/draft-fett-oauth-dpop-01
>> 
>> -Daniel
>> 
>>> Am 03.04.19 um 17:28 schrieb George Fletcher:
>>> A quick question regarding...
>>> 
>>>o  "http_uri": The HTTP URI used for the request, without query and
>>>   fragment parts (REQUIRED).
>>> 
>>> Is 'without' supposed to be 'with' ? The example shows the http_uri *with* 
>>> the query parameters :)
>>> 
 On 3/28/19 6:17 AM, Daniel Fett wrote:
 Hi all,
 
 I published the first version of the DPoP draft at 
 https://tools.ietf.org/html/draft-fett-oauth-dpop-00
 
 Abstract
 
This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.
 
 Thanks for the feedback I received so far from John, Mike, Torsten, and 
 others during today's session or before!
 
 If you find any errors I would welcome if you open an issue in the GitHub 
 repository at https://github.com/webhamster/draft-dpop
 
 - Daniel
 
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk=
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[George Fletcher]

Perfect! Thank you! A couple comments on version 01...

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   =SplxlOBeZQQYbYS6WxSbIA
   _uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)


I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...


Also, there is no discussion of the DPoP-Binding header outside of the 
token request, but I suspect that is the desired way to communicate the 
DPoP-Proof to the RS.


Possibly an example in the session for presenting the token to the RS 
would help.


Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:

A quick question regarding...

o  "http_uri": The HTTP URI used for the request, without query and
   fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, Daniel Fett wrote:


Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00


Abstract

This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, 
and others during today's session or before!


If you find any errors I would welcome if you open an issue in the 
GitHub repository at https://github.com/webhamster/draft-dpop


- Daniel


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






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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Daniel Fett]

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
> A quick question regarding...
>
>o  "http_uri": The HTTP URI used for the request, without query and
>   fragment parts (REQUIRED).
>
> Is 'without' supposed to be 'with' ? The example shows the http_uri
> *with* the query parameters :)
>
> On 3/28/19 6:17 AM, Daniel Fett wrote:
>>
>> Hi all,
>>
>> I published the first version of the DPoP draft at
>> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>>
>> Abstract
>>
>>This document defines a sender-constraint mechanism for OAuth 2.0
>>access tokens and refresh tokens utilizing an application-level
>>proof-of-possession mechanism based on public/private key pairs.
>>
>> Thanks for the feedback I received so far from John, Mike, Torsten,
>> and others during today's session or before!
>>
>> If you find any errors I would welcome if you open an issue in the
>> GitHub repository at https://github.com/webhamster/draft-dpop
>>
>> - Daniel   
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[George Fletcher]

A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).


Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, Daniel Fett wrote:


Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00


Abstract

This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, 
and others during today's session or before!


If you find any errors I would welcome if you open an issue in the 
GitHub repository at https://github.com/webhamster/draft-dpop


- Daniel


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


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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Ludwig Seitz]

On 02/04/2019 17:35, Brian Campbell wrote:
Except that the jwk header is more appropriate in the given context 
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key 
that corresponds to the key used to digitally sign the JWS.  Which is 
what it is.






A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the
pop-key in the token. Any reason for not using the "cnf" claim from
RFC 7800?

/Ludwig



My bad, figure 3 is not a token (although it looks like one) it's the 
token request (encapsulated in a JWS).


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Brian Campbell]

Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS.  Which is what
it is.



On Thu, Mar 28, 2019, 6:32 AM Mike Jones  wrote:

> Good observation, Ludwig.  We should do that.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Ludwig Seitz
> Sent: Thursday, March 28, 2019 12:05 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
>
> On 28/03/2019 11:17, Daniel Fett wrote:
> > Hi all,
> >
> > I published the first version of the DPoP draft at
> > https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> >
> > Abstract
> >
> > This document defines a sender-constraint mechanism for OAuth 2.0
> > access tokens and refresh tokens utilizing an application-level
> > proof-of-possession mechanism based on public/private key pairs.
> >
> >
> > Thanks for the feedback I received so far from John, Mike, Torsten,
> > and others during today's session or before!
> >
> > If you find any errors I would welcome if you open an issue in the
> > GitHub repository at https://github.com/webhamster/draft-dpop
> >
> > - Daniel
> >
> >
>
> A quick nit:
>
> in figure 3 you seem to be using the "jwk" claim to include the pop-key in
> the token. Any reason for not using the "cnf" claim from RFC 7800?
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> ___
> 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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[rich levinson]

Speaking for myself, as a long time user of OAuth 2.0, I am very enthusiastic
about the new proposal:
  "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer"
  https://tools.ietf.org/html/draft-fett-oauth-dpop-00

I believe it represents a real milestone for OAuth in that it appears to me
to be the first proposal that is capable of offering true end-to-end integrity
by using the OAuth 2.0 protocol at the application layer.

In addition to the basic proof of possession capability, it inherently contains
the mechanism for the client to completely protect any request that can be
decomposed into a set of key:value pairs, which can then be signed within a JWT.

The additional key:value pairs can be included in a Resource Access POST 
request,
as described in section 5, by placing them in a 2nd JWT using the same public 
key
and format as Figure 3, in a parameter with a name required by the Resource
Server Application, for example, "dpop_appl_request".

Since the parameter will be in the body of a POST request, there should be no 
size
limitation for the set of key:value pairs that can be provided.

Furthermore, the Access Token received in response to the token request shown
in Figure 3, should cover the "dpop_appl_request" parameter, in the same way
it covers the "dpop_proof" parameter described in section 5, because it covers
the usage of the public key, and any specific content that is protected by that 
public key.

The Access Token implicitly contains the user consent, the authorization of the 
IdP,
plus the public key of the client making the request, and therefore the 
"dpop_appl_request"
can potentially be usable to preserve the signature and possibly be used in 
some cases
for non-repudiation, a capability that is not possible using the transport 
layer protocols,
which remove all the protocol protection before delivering the request to the 
Resource Server Appl.

In summary, the dpop at the appl layer proposal, imo, represents a significant 
advance in
OAuth 2.0 technology that potentially addresses many of the security 
requirements
that OAuth 2.0 does not currently provide.

  Thanks,
  Rich Levinson



 Re: [OAUTH-WG] draft-fett-oauth-dpop-00

Filip Skokan Fri, 29 March 2019 16:39 UTCShow header 
<https://mailarchive.ietf.org/arch/browse/oauth/#>

And here's a real simple client-side implementation using

- Webcrypto API
- IndexedDB API
- fetch

https://boiling-escarpment-16732.herokuapp.com/

It's not really a SPA but uses the same browser APIs and no backend other
than a web server hosting the html.

Best,
*Filip Skokan*


On Thu, 28 Mar 2019 at 19:48, Filip Skokan   
<mailto:panva...@gmail.com>; wrote:


Hello Daniel, everyone,

I've hacked together an AS implementation to enable client-side
experimentation using this draft.

You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com  
<https://draft-fett-oauth-dpop-00.herokuapp.com/>  (it's
also the issuer identifier). There's a default client registered and
dynamic registration is also open, so hack away. It's using the draft
version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
"dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.

There are more notes on the index page itself.

Aaron kindly accepted to work on the SPA client-side demonstration, I'm
not a SPA guru mastermind like Aaron and it would take me ages to deliver
that particular piece. That being said I did test this with a regular web
app as well as a CLI client using both code+pkce and dynamic port binding
as well as device authorization grant client. Works.

Feeding back to the draft

   - i think we should mention the client to provide reasonable
   expiration value of the dpop JWTs (max minutes). Altho not critical since
   we require a jti, as an AS i don't wanna cache the used jti values forever
   :)
   - the AS should error when the dpop JWT contains private key material
   - altho implied by the use of "public" and "private" key i think it
   wouldn't hurt explicitly forbidding "oct" JWKs
   - i don't see a point in dpop_proof containing the JWK again unless
   the AS is supposed to do something new with it
   - it wouldn't hurt mentioning that, kinda following 6750, when
   dpop_proof is sent it's in a query for GET, in the request body for a POST.
   my provider for instance will ignore query parameters during a POST. With
   that said, what about RS endpoints using other methods? Maybe placing the
   proof in a header isn't a terrible idea afterall.


Kind Regards,
*Filip Skokan*


On Thu, 28 Mar 2019 at 11:19, Daniel Fett   
<mailto:danielf+oa...@yes.com>; wrote:


Hi all,

I published the first version of the DPoP draft at
https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Filip Skokan]

And here's a real simple client-side implementation using

- Webcrypto API
- IndexedDB API
- fetch

https://boiling-escarpment-16732.herokuapp.com/

It's not really a SPA but uses the same browser APIs and no backend other
than a web server hosting the html.

Best,
*Filip Skokan*


On Thu, 28 Mar 2019 at 19:48, Filip Skokan  wrote:

> Hello Daniel, everyone,
>
> I've hacked together an AS implementation to enable client-side
> experimentation using this draft.
>
> You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com 
> (it's
> also the issuer identifier). There's a default client registered and
> dynamic registration is also open, so hack away. It's using the draft
> version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
> "dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.
>
> There are more notes on the index page itself.
>
> Aaron kindly accepted to work on the SPA client-side demonstration, I'm
> not a SPA guru mastermind like Aaron and it would take me ages to deliver
> that particular piece. That being said I did test this with a regular web
> app as well as a CLI client using both code+pkce and dynamic port binding
> as well as device authorization grant client. Works.
>
> Feeding back to the draft
>
>- i think we should mention the client to provide reasonable
>expiration value of the dpop JWTs (max minutes). Altho not critical since
>we require a jti, as an AS i don't wanna cache the used jti values forever
>:)
>- the AS should error when the dpop JWT contains private key material
>- altho implied by the use of "public" and "private" key i think it
>wouldn't hurt explicitly forbidding "oct" JWKs
>- i don't see a point in dpop_proof containing the JWK again unless
>the AS is supposed to do something new with it
>- it wouldn't hurt mentioning that, kinda following 6750, when
>dpop_proof is sent it's in a query for GET, in the request body for a POST.
>my provider for instance will ignore query parameters during a POST. With
>that said, what about RS endpoints using other methods? Maybe placing the
>proof in a header isn't a terrible idea afterall.
>
>
> Kind Regards,
> *Filip Skokan*
>
>
> On Thu, 28 Mar 2019 at 11:19, Daniel Fett  wrote:
>
>> Hi all,
>>
>> I published the first version of the DPoP draft at
>> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>>
>> Abstract
>>
>>This document defines a sender-constraint mechanism for OAuth 2.0
>>access tokens and refresh tokens utilizing an application-level
>>proof-of-possession mechanism based on public/private key pairs.
>>
>>
>> Thanks for the feedback I received so far from John, Mike, Torsten, and
>> others during today's session or before!
>>
>> If you find any errors I would welcome if you open an issue in the GitHub
>> repository at https://github.com/webhamster/draft-dpop
>>
>> - Daniel
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Filip Skokan]

Hello Daniel, everyone,

I've hacked together an AS implementation to enable client-side
experimentation using this draft.

You can find this hosted at
https://draft-fett-oauth-dpop-00.herokuapp.com (it's
also the issuer identifier). There's a default client registered and
dynamic registration is also open, so hack away. It's using the draft
version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
"dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.

There are more notes on the index page itself.

Aaron kindly accepted to work on the SPA client-side demonstration, I'm not
a SPA guru mastermind like Aaron and it would take me ages to deliver that
particular piece. That being said I did test this with a regular web app as
well as a CLI client using both code+pkce and dynamic port binding as well
as device authorization grant client. Works.

Feeding back to the draft

   - i think we should mention the client to provide reasonable expiration
   value of the dpop JWTs (max minutes). Altho not critical since we require a
   jti, as an AS i don't wanna cache the used jti values forever :)
   - the AS should error when the dpop JWT contains private key material
   - altho implied by the use of "public" and "private" key i think it
   wouldn't hurt explicitly forbidding "oct" JWKs
   - i don't see a point in dpop_proof containing the JWK again unless the
   AS is supposed to do something new with it
   - it wouldn't hurt mentioning that, kinda following 6750, when
   dpop_proof is sent it's in a query for GET, in the request body for a POST.
   my provider for instance will ignore query parameters during a POST. With
   that said, what about RS endpoints using other methods? Maybe placing the
   proof in a header isn't a terrible idea afterall.


Kind Regards,
*Filip Skokan*


On Thu, 28 Mar 2019 at 11:19, Daniel Fett  wrote:

> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>
> Abstract
>
>This document defines a sender-constraint mechanism for OAuth 2.0
>access tokens and refresh tokens utilizing an application-level
>proof-of-possession mechanism based on public/private key pairs.
>
>
> Thanks for the feedback I received so far from John, Mike, Torsten, and
> others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
>
> - Daniel
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Mike Jones]

Good observation, Ludwig.  We should do that.

-- Mike

-Original Message-
From: OAuth  On Behalf Of Ludwig Seitz
Sent: Thursday, March 28, 2019 12:05 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00

On 28/03/2019 11:17, Daniel Fett wrote:
> Hi all,
> 
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> 
> Abstract
> 
> This document defines a sender-constraint mechanism for OAuth 2.0
> access tokens and refresh tokens utilizing an application-level
> proof-of-possession mechanism based on public/private key pairs.
> 
> 
> Thanks for the feedback I received so far from John, Mike, Torsten, 
> and others during today's session or before!
> 
> If you find any errors I would welcome if you open an issue in the 
> GitHub repository at https://github.com/webhamster/draft-dpop
> 
> - Daniel
> 
>

A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the pop-key in the 
token. Any reason for not using the "cnf" claim from RFC 7800?

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

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

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Ludwig Seitz]

On 28/03/2019 11:17, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00


Abstract

This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.


Thanks for the feedback I received so far from John, Mike, Torsten, and 
others during today's session or before!


If you find any errors I would welcome if you open an issue in the 
GitHub repository at https://github.com/webhamster/draft-dpop


- Daniel




A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the pop-key 
in the token. Any reason for not using the "cnf" claim from RFC 7800?


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-fett-oauth-dpop-00

[Daniel Fett]

Hi all,

I published the first version of the DPoP draft at
https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.


Thanks for the feedback I received so far from John, Mike, Torsten, and
others during today's session or before!

If you find any errors I would welcome if you open an issue in the
GitHub repository at https://github.com/webhamster/draft-dpop

- Daniel   

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