Re: [GNAP] Signature Methods

[Dave Tonge <[e-mail]>]

I'm definitely in favour of simplification.

Mutual TLS is an interesting one. I would prefer that it isn't included in
core as it mixes the transport and application layers and in my experience
is fairly brittle (not the spec, but how it is implemented in a lot of
places).

Purely in terms of aesthetics, I don't like the http signatures spec, but
if it is going to become mainstream then it makes sense to make it the
primary signing mechanism. As you mentioned the good thing about it is that
it can work for all HTTP requests, and can also be used for signing
responses.

I think some work will need to be done to get the http signature spec
supported by standard HTTP client libraries in popular languages. This will
make it a lot easier for implementers (i.e. I can call

```
myHttpClientLibary.post({
  body: {...},
  uri: "https://example.com/continue",
  sign: {
    key: {} // reference to key to use to sign,
    digest: "SHA-256"
    additionalHeaders: ["authorization", "content-type"]
  }
})
```

So my suggestion would be to only have the http signature spec in core.

GNAP is a new protocol - I see no need to add unnecessary optionality.

Dave



On Tue, 15 Jun 2021 at 19:50, Justin Richer <[e-mail]> wrote:

> In GNAP, most requests are signed in some way, or at least bound to a key
> being presented or referenced with the request. This is true for
> connections from the client instance to the AS and to the RS, as well as
> introspection requests from the RS to the AS. GNAP has always sought to be
> flexible with regard to cryptographic binding mechanisms, but there’s a
> question as to what should remain defined in the core document. Right now,
> core has six methods defined. The editors are proposing that we keep at
> least two and drop two, and the others could either both be kept, both be
> dropped, or one kept. The rationale for each proposal is discussed below:
>
> Proposed to keep:
>
> - HTTP Method Signatures: general purpose mechanism, being defined in HTTP
> WG. Can be bound to symmetric and asymmetric keys. Usable for native, web,
> and SPA clients. Suggested MTI for the AS (but not mandatory to use) for
> interoperability. Side note, possible use for AS to sign responses (but not
> explored here yet — that’s another topic).
>
> - Mutual TLS: based on OAuth MTLS, ties the keys at the TLS layer to the
> application protocol (GNAP).
>
>
> Proposed to drop:
>
> - OAuth PoP: expired draft, due to be replaced with new draft based on
> HTTP Message Signatures.
>
> - OAuth DPoP: only works for asymmetric keys, requires key be presented in
> the header (duplicating information from GNAP messages). It was never meant
> to be a general purpose signing mechanism, though the FAPI group in OIDF is
> considering it as an option in current proposed work.
>
>
> This leaves the two JWS based methods, detached and attached. Since
> attached JWS depends on the detached JWS method to handle body-less
> requests like GET, DELETE, OPTIONS, etc., if we remove the detached method
> then we have to remove both. The methods could be pulled to an extension,
> left in core, or removed entirely.
>
> The editors would appreciate feedback on this proposal, including specific
> feedback on the JWS methods from implementors who are targeting them.
>
>
>  — Justin
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
t: [phone]

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at *https://register.fca.org.uk/
<https://register.fca.org.uk/>*. Moneyhub Financial Technology is
registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 


Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.