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