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

[Ralph Bragg]

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/a8526d33/attachment-0001.html>