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

Torsten Lodderstedt torsten at lodderstedt.net
Sat Jun 6 08:35:42 UTC 2020


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/4598cef9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2275 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200606/4598cef9/attachment-0001.p7s>


More information about the Openid-specs-fapi mailing list