Re: [GNAP] Signature Methods

[Fabien Imbault <[e-mail]>]

Dear all,

I've created the 2 PRs to remove DPoP (
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/271) and PoP (
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/272).

I personally would also favor removing JWS detached and attached. My
rationale for that :
- not everyone likes JOSE, so not having a strong dependency opens to a
wider community
- we can still support those cases as extensions, if it makes the
transition from oauth easier

On top of that, Dave's arguments for simplification make very good sense.
The main downside of having only HTTP signatures is that it is fairly new,
so the adoption requires the ecosystem to catch up (not sure what's the
issue with its aesthetics, could you explain further?). But in general,
it's quite nice I think.

Fabien

On Mon, Jun 21, 2021 at 11:03 PM Dave Tonge <[e-mail]> wrote:

> 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/.
> 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.
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>