[Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses

[Ralph Bragg]

Another quick one, in the bottom Section on Cryptography and Secrets In bass line there is mention of “symmetric credentials” being permitted. But I couldn’t see anywhere in the requirements for AS that they should be supported.

If there’s a need can it be stated? (I’ll raise a ticket). Additionally for advanced profile this clause, if it’s still required, should be assymetric only no?

Will raise a ticket on advanced for that decision as well.

________________________________
From: Torsten Lodderstedt <torsten at lodderstedt.net>
Sent: Saturday, June 6, 2020 10:09:22 AM
To: Ralph Bragg <ralph.bragg at raidiam.com>
Cc: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Subject: Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses

I also suggest we document what metadata values AS and client are supposed to use, e.g. there will be the metadata parameter require_pushed_authorization_requests to let the AS indicate it supports pushed authorization requests only (https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M/).

A FAPI2 compliant AS must set this value to true.

Am 06.06.2020 um 10:55 schrieb Ralph Bragg <ralph.bragg at raidiam.com>:



Hi Daniel,



In addition to Torstens comments, and if we’re looking for backwards combability, do we care or want to mandate that the id_token from the front channel is ONLY used for code binding. Sub is a mandatory property of the id_token and as such required, to prevent any leakage of any information useful to a potential attacker should the sub property explicitly be made pairwise or some other value deliberately not related to the resource owner / subject.



Kind Regards,

Ralph







From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Torsten Lodderstedt via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Reply to: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Date: Saturday, 6 June 2020 at 09:36
To: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Cc: Torsten Lodderstedt <torsten at lodderstedt.net>
Subject: Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses



Hi Daniel,



Am 05.06.2020 um 10:20 schrieb Daniel Fett via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:

Hi all,

I prepared a first (rough) draft of the FAPI 2 Advanced profile and would welcome your feedback: https://bitbucket.org/openid/fapi/src/c28fc020e7ab9377d96501f2b4daa9a9da8f2128/FAPI_2_0_Advanced_Profile.md?at=danielfett%2Ffapi2%2Fadvanced

thanks for preparing the draft!



Here are my comments:

- [@I-D.lodderstedt-oauth-par] should refer to the WG draft

- „ shall support at least one of the following methods to sign the authorization response:“

I think the AS must support at least one mode for interoperability reasons. I think this should be JARM and ID token may be supported (for the purpose of this profile) for backward compatibility reasons.

„OPEN QUESTION: how to handle userinfo response type selection? OIDC core says: depends on client registration“ I think that's fine. We use the same philosophy for all sorts of request and response signing. It’s determined by client registration parameters + general deployment metadata (what is generally supported/expected).

- „The FAPI 2.0 endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated with the submitted access token.“ - RSs also initiate actions (eg payments), that’s one important reason for requiring non-repudiation. I suggest to add something like „.... that perform sensitive actions and return protected information for the resource owner ...“



best regards,

Torsten.

One open question is whether we can give recommendations regarding resource request and response signing. We currently have https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md which lists "typical requirements" but does not give concrete advice.

eTSI is developding JAdES and there is some work ongoing in the IETF HTTP group as well.

What are other options that we should take a look at?

-Daniel

_______________________________________________
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200606/2761e296/attachment-0001.html>