Re: M2M DID Auth

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

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> 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) 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>
> *Sent:* Wednesday, May 27, 2020 6:12 PM
> *To:* Leonard Rosenthol <lrosenth@adobe.com>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; 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>
> 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> 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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&amp;sdata=A5ewP05MgZaXkC5QIcjDFL2SmcBToMBlAba8qLaycYU%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754327482&amp;sdata=Sz53sYwt%2FrCz54PODoVfu8dQJ0kCRFOExjiTJgAd0ho%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C5c4b1147bee042d4ae6908d8024d6715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637261878754337438&amp;sdata=0gXZSYF%2BkR2ktLHTQvhOZfYPC08nxoRUfX7Jqe040%2F8%3D&amp;reserved=0
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>