- From: Justin Richer <jricher@mit.edu>
- Date: Wed, 27 May 2020 15:21:24 -0400
- To: Orie Steele <orie@transmute.industries>
- Cc: Nikos Fotiou <fotiou@aueb.gr>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-Id: <75E0EF5D-4736-4336-A78F-1712916C6885@mit.edu>
Not speaking for the DPoP draft editors, but having implemented it on several platforms and discussed it at length, I can add a bit of light: The idea with DPoP is to have a simple proof-of-possession mechanism for OAuth that’s usable for SPA’s, where MTLS doesn’t fly. So it’s less concerned with deep protection of the HTTP request than it is with making sure only a valid presenter of a token can create a request to begin with. It’s a step above bearer tokens. My personal take is that we’ll see both DPoP and an HTTP-signatures based PoP mechanism, the latter being more general purpose and able to be used across a wider variety of application types, key types, and deployment situations. DPoP can remain a focused point-solution that works pretty well today while we work out the kinks to a larger, more general system that can be deployed along side of it. The goal in OAuth 2 was always to have multiple types of bound access tokens, but all we ever got to back in the day were bearer tokens. The MTLS spec took one shaky step toward fixing that, and DPoP is taking another one, and we’ll see more going forward. Additionally, all of this experience is feeding in to the TxAuth work at the IETF, which is going to be working on a next-generation delegation protocol. My input to that group and writings on it can be found at https://oauth.xyz/ <https://oauth.xyz/> if anyone wants to check it out. — Justin > On May 27, 2020, at 3:11 PM, Orie Steele <orie@transmute.industries> wrote: > > https://tools.ietf.org/html/draft-fett-oauth-dpop-04#section-9.4 <https://tools.ietf.org/html/draft-fett-oauth-dpop-04#section-9.4> > > DPoP does not ensure the integrity of the payload or headers of > requests. The signature of DPoP proofs only contains the HTTP URI > and method, but not, for example, the message body or other request > headers. > > This is an intentional design decision to keep DPoP simple to use, > but as described, makes DPoP potentially susceptible to replay > attacks where an attacker is able to modify message contents and > headers. In many setups, the message integrity and confidentiality > provided by TLS is sufficient to provide a good level of protection. > > thats drastically different than https://tools.ietf.org/html/draft-cavage-http-signatures-10#section-4.1 <https://tools.ietf.org/html/draft-cavage-http-signatures-10#section-4.1> > > I'm interested to hear why DPoP chose not to sign http request headers in a way that prevents tampering... > > Assuming TLS and JOSE (without JCS) seems like the worst of trusted central authority and no canonical representation for data... > > But that's just a personal opinion after reading the spec for 5 minutes... I see that this is mostly just to hack around a specific OAuth use case, is that an accurate assessment? > > Still wondering why given the option to sign the request headers and body digest, one would choose not too. > > > OS > > > On Wed, May 27, 2020 at 1:55 PM Nikos Fotiou <fotiou@aueb.gr <mailto:fotiou@aueb.gr>> wrote: > Related to that, there is this ongoing ietf draft “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)” (https://tools.ietf.org/html/draft-fett-oauth-dpop-04 <https://tools.ietf.org/html/draft-fett-oauth-dpop-04>) which is about demonstrating possession of a jwk. The interesting about the solution presented there, is that it does not require any roundtrip. > > > > Best, > > Nikos > > > > > > From: Oliver Terbu <oliver.terbu@consensys.net <mailto:oliver.terbu@consensys.net>> > Sent: Wednesday, May 27, 2020 6:12 PM > To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> > Cc: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>; public-credentials@w3.org <mailto:public-credentials@w3.org> > Subject: Re: M2M DID Auth > > > > You could also use JWT/JWS for M2M DID Auth. The DID will be put in the `iss` and `sub` field. A `nonce` must also be added. The JWT/JWS will be signed with one of the keys in the DID's authentication section. Additionally, you could set the `kid` property accordingly to contain the DID URI pointing to the public key in the DID Doc. The verifier will need to resolve the DID to a DID Doc and find the public key in the DID Doc that corresponds to `kid`, verify the signature and verify the `nonce`, done. > > > > The JWT/JWS itself could be sent in the Authorization header of the HTTP request. > > > > Oliver > > > > On Wed, May 27, 2020 at 5:03 PM Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote: > > Manu - which version of the "Signing HTTP messages" spec are you working with? > > In a discussion at ETSI this week, it came to my attention that many people in the banking sector (at least in the EU) are using active implementations based on the draft-cavage-10 version instead of the current cavage-12 or httpbis-00. And it's my understanding that that recent update (httpbis-00) is *not* compatible with the cavage-10. Is that correct? Can you comment about why the committee moved away from compatibility given known implementations? > > Trying to get everyone aligned - if possible. > > Thanks, > Leonard > > On 5/27/20, 10:51 AM, "Manu Sporny" <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote: > > On 5/27/20 6:21 AM, Dominic Wörner wrote: > > I'm interested in the use case of M2M (Server 2 Server) Authentication. > > The machines know each others DIDs. I don't want to reinvent the wheel > > and I'd like to reuse standard software as much as possible. > > Digital Bazaar has been using DIDs + HTTP Signatures to do M2M DID Auth > for a number of years now: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-httpbis-message-signatures%2F&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&sdata=A5ewP05MgZaXkC5QIcjDFL2SmcBToMBlAba8qLaycYU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-httpbis-message-signatures%2F&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&sdata=A5ewP05MgZaXkC5QIcjDFL2SmcBToMBlAba8qLaycYU%3D&reserved=0> > > Fundamentally, all you need to do is use the "Signing HTTP Messages" > spec to digitally sign a set of headers that you send to a server. The > signature field ends up looking something like this in the HTTP Header: > > digest: mh=uEiDZpOV3dMk5HrfX1fyxkKMMlNCwWW4xc8DN9lPuXTzKIQ > authorization: Signature > keyId="did:v1:z6MkjpLLk1R5BLPcvdd3s5EUDhsfJEagJtKXsMHkoWdkRKBT#z6MkjpLLk1R5BLPcvdd3s5EUDhsfJEagJtKXsMHkoWdkRKBT",headers="(key-id) > (created) (expires) (request-target) host content-type > digest",signature="ZQeG4EJ3Ea7gYkhIeHGuGPA8UrDitPlk6zK7qGwSuXq/nki589HsVJ97o/4+PyEN3m8qCcyAp0ivtil45wDXAQ==",created="1590590592826",expires="1590591192826" > > In the example above (pulled from our digital wallet implementation when > speaking w/ an Encrypted Data Vault)... the digest field is digitally > signed using a did:v1 key. > > Fundamentally, all you need is a DID and the "Signing HTTP Messages" > spec to do M2M DID Auth. We also have M2M Authorization Capability > invocation working in the same way. All of this is well beyond the > experimental/proof of concept phase, with the newest code bases headed > toward production (so we feel pretty good about where the solution is at > right now). > > -- manu > > -- > Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&sdata=Sz53sYwt%2FrCz54PODoVfu8dQJ0kCRFOExjiTJgAd0ho%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&sdata=Sz53sYwt%2FrCz54PODoVfu8dQJ0kCRFOExjiTJgAd0ho%3D&reserved=0> > Founder/CEO - Digital Bazaar, Inc. > blog: Veres One Decentralized Identifier Blockchain Launches > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754337438&sdata=0gXZSYF%2BkR2ktLHTQvhOZfYPC08nxoRUfX7Jqe040%2F8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754337438&sdata=0gXZSYF%2BkR2ktLHTQvhOZfYPC08nxoRUfX7Jqe040%2F8%3D&reserved=0> > > > > -- > ORIE STEELE > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries/>
Received on Wednesday, 27 May 2020 19:21:44 UTC