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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Perfect! Thank you! A couple comments on version 01... >>>> >>>> POST /token HTTP/1.1 >>>> Host: server.example.com <http://server.example.com/> >>>> Content-Type: application/x-www-form-urlencoded;charset=UTF-8 >>>> DPoP-Binding: eyJhbGciOiJSU0ExXzUi ... >>>> >>>> grant_type=authorization_code >>>> &code=SplxlOBeZQQYbYS6WxSbIA >>>> &redirect_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 >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D01&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=TEa5Vgb3rAzxbIuavB1lN65fnkTxKoMp7F2rw1AjuEY&e=> >>>>> >>>>> -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 >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D00&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=eeMGKZq5R86dv0XgrBsIijzuI8OzQqnE-vmUEZ836hY&e=> >>>>>>> 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 >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_webhamster_draft-2Ddpop&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=RR3u82IhN7whr8LgXMWM2fWN7EKH6GO-Bs-HRxEwKHE&e=> >>>>>>> - Daniel >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e= >>>> >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
